El problema: recibo un error 404: Archivo no encontrado al intentar acceder a la aplicación (incluida la primera vez)

Question

Lo descubrí, así que brindaré información detallada para ayudar a las personas que ya tienen el mismo problema y para las personas que podrían encontrarse con esto en el futuro, considerando cuántas preguntas y problemas encontré sobre esto sin respuestas.

El problema era la ubicación raíz de FPM en los parámetros FastCGI del archivo de configuración NGinX

Así que estaba en el camino correcto y el problema estaba relacionado con la directiva raíz.

Después de mucho leer me topé con esta publicación:

¿Cómo vincular correctamente los contenedores php-fpm y Nginx Docker?

Y de repente quedó claro que tenía dos servicios diferentes que leían 2 rutas diferentes y uno alimentaba la ruta raíz del otro donde no existía.

¿Recuerda que había montado el volumen www para compartirlo entre los 2 contenedores?

Para el contenedor NGinX enwww:/usr/share/nginx/html
Para el contenedor FPM de NextCloud enwww:/var/html/www

La idea detrás de esto era que los dos contenedores compartieran el sistema de archivos de la aplicación NextCloud.

Lo que no me di cuenta es que en esta implementación, el propósito de NGinX es servir archivos estáticos, como CSS, HTML, JPG, JS, etc., mientras enruta llamadas PHP al contenedor FPM de NextCloud con los parámetros FastCGI.

Cuando se declara la directiva raíz en el archivo de configuración de NGinX, se establece como la variable $document_root.

root /usr/share/nginx/html;

Entonces, cuando se establece la raíz en la ruta en el contenedor NGinX, /usr/share/nginx/htmlesto funciona para servir los archivos estáticos sin problemas, pero luego, cuando se realiza una llamada PHP, se envía al php-hanlder en el contenedor FPM de NextCloud, ya que esa ubicación no existe dentro del segundo contenedor, no puede encontrar el archivo PHP.

Para solucionar este problema, busqué el bloque con los parámetros FastCGI y busqué la $document_rootvariable, la encontré y se ve así:

location ~ \.php(?:$|/) {
            # Required for legacy support
            rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;

            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            set $path_info $fastcgi_path_info;

            try_files $fastcgi_script_name =404;

            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $path_info;
            #fastcgi_param HTTPS on;

            fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
            fastcgi_param front_controller_active true;     # Enable pretty urls
            fastcgi_pass php-handler;

            fastcgi_intercept_errors on;
            fastcgi_request_buffering off;
        }

Note como la línea que dice fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;está formando la Ruta del Script con la raíz ya declarada, por lo que al procesar nextcloud.example.comintenta leer index.phpy esta es la llamada resultante al contenedor FPM de NextCloud:

/usr/share/nginx/html/index.php

La llamada correcta hubiera sido:

/var/www/html/index.php

Entonces creé una nueva variable llamada $fpm_rooty la configuré /var/www/html/, luego cambié la línea que fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;dicefastcgi_param SCRIPT_FILENAME $fpm_root$fastcgi_script_name;

Ahora, cada vez que reciba una llamada de contenido estático, resolverá la ruta del contenedor de NGinX y cuando reciba una llamada de contenido PHP, la ruta del contenedor de NextCloud FPM.

Así es como se ve toda la sección ahora:

location ~ \.php(?:$|/) {
            # Required for legacy support
            rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;

            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            set $path_info $fastcgi_path_info;
            set $fpm_root /var/www/html/;

            try_files $fastcgi_script_name =404;

            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $fpm_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $path_info;
            fastcgi_param HTTPS on;

            fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
            fastcgi_param front_controller_active true;     # Enable pretty urls
            fastcgi_pass php-handler;

            fastcgi_intercept_errors on;
            fastcgi_request_buffering off;
        }

Funciona ahora y pasa todas las comprobaciones internas de salud y seguridad de NextCloud una vez que agregué la línea:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Conclusión

Y espero que esto ayude a cualquiera que busque este problema, el problema era que tenía dos rutas diferentes para los servicios que procesaban ambos tipos de contenido, estático y PHP, y solo una de ellas estaba configurada correctamente en el archivo de configuración de NGinX.

Puede tener dos ubicaciones raíz diferentes (o más) para una implementación de FPM dockerizada, y esto probablemente podría servir para trabajar o implementar contenido estático en dos o más aplicaciones diferentes usando el mismo contenedor FPM para manejar llamadas PHP para NextCloud, WordPress, PHPPGAdmin, Laravel o cualquier cosa en la que estés trabajando.

Answer 1

Lo descubrí, así que brindaré información detallada para ayudar a las personas que ya tienen el mismo problema y para las personas que podrían encontrarse con esto en el futuro, considerando cuántas preguntas y problemas encontré sobre esto sin respuestas.

El problema era la ubicación raíz de FPM en los parámetros FastCGI del archivo de configuración NGinX

Así que estaba en el camino correcto y el problema estaba relacionado con la directiva raíz.

Después de mucho leer me topé con esta publicación:

¿Cómo vincular correctamente los contenedores php-fpm y Nginx Docker?

Y de repente quedó claro que tenía dos servicios diferentes que leían 2 rutas diferentes y uno alimentaba la ruta raíz del otro donde no existía.

¿Recuerda que había montado el volumen www para compartirlo entre los 2 contenedores?

Para el contenedor NGinX enwww:/usr/share/nginx/html
Para el contenedor FPM de NextCloud enwww:/var/html/www

La idea detrás de esto era que los dos contenedores compartieran el sistema de archivos de la aplicación NextCloud.

Lo que no me di cuenta es que en esta implementación, el propósito de NGinX es servir archivos estáticos, como CSS, HTML, JPG, JS, etc., mientras enruta llamadas PHP al contenedor FPM de NextCloud con los parámetros FastCGI.

Cuando se declara la directiva raíz en el archivo de configuración de NGinX, se establece como la variable $document_root.

root /usr/share/nginx/html;

Entonces, cuando se establece la raíz en la ruta en el contenedor NGinX, /usr/share/nginx/htmlesto funciona para servir los archivos estáticos sin problemas, pero luego, cuando se realiza una llamada PHP, se envía al php-hanlder en el contenedor FPM de NextCloud, ya que esa ubicación no existe dentro del segundo contenedor, no puede encontrar el archivo PHP.

Para solucionar este problema, busqué el bloque con los parámetros FastCGI y busqué la $document_rootvariable, la encontré y se ve así:

location ~ \.php(?:$|/) {
            # Required for legacy support
            rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;

            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            set $path_info $fastcgi_path_info;

            try_files $fastcgi_script_name =404;

            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $path_info;
            #fastcgi_param HTTPS on;

            fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
            fastcgi_param front_controller_active true;     # Enable pretty urls
            fastcgi_pass php-handler;

            fastcgi_intercept_errors on;
            fastcgi_request_buffering off;
        }

Note como la línea que dice fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;está formando la Ruta del Script con la raíz ya declarada, por lo que al procesar nextcloud.example.comintenta leer index.phpy esta es la llamada resultante al contenedor FPM de NextCloud:

/usr/share/nginx/html/index.php

La llamada correcta hubiera sido:

/var/www/html/index.php

Entonces creé una nueva variable llamada $fpm_rooty la configuré /var/www/html/, luego cambié la línea que fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;dicefastcgi_param SCRIPT_FILENAME $fpm_root$fastcgi_script_name;

Ahora, cada vez que reciba una llamada de contenido estático, resolverá la ruta del contenedor de NGinX y cuando reciba una llamada de contenido PHP, la ruta del contenedor de NextCloud FPM.

Así es como se ve toda la sección ahora:

location ~ \.php(?:$|/) {
            # Required for legacy support
            rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;

            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            set $path_info $fastcgi_path_info;
            set $fpm_root /var/www/html/;

            try_files $fastcgi_script_name =404;

            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $fpm_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $path_info;
            fastcgi_param HTTPS on;

            fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
            fastcgi_param front_controller_active true;     # Enable pretty urls
            fastcgi_pass php-handler;

            fastcgi_intercept_errors on;
            fastcgi_request_buffering off;
        }

Funciona ahora y pasa todas las comprobaciones internas de salud y seguridad de NextCloud una vez que agregué la línea:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Conclusión

Y espero que esto ayude a cualquiera que busque este problema, el problema era que tenía dos rutas diferentes para los servicios que procesaban ambos tipos de contenido, estático y PHP, y solo una de ellas estaba configurada correctamente en el archivo de configuración de NGinX.

Puede tener dos ubicaciones raíz diferentes (o más) para una implementación de FPM dockerizada, y esto probablemente podría servir para trabajar o implementar contenido estático en dos o más aplicaciones diferentes usando el mismo contenedor FPM para manejar llamadas PHP para NextCloud, WordPress, PHPPGAdmin, Laravel o cualquier cosa en la que estés trabajando.

El problema: recibo un error 404: Archivo no encontrado al intentar acceder a la aplicación (incluida la primera vez)

El problema: recibo un error 404: Archivo no encontrado al intentar acceder a la aplicación (incluida la primera vez)

La configuración del host del servidor Docker y los contenedores.

Lo que he probado hasta ahora

Mi determinación de cuál es el problema y dónde estoy estancado

Respuesta1

El problema era la ubicación raíz de FPM en los parámetros FastCGI del archivo de configuración NGinX

Después de mucho leer me topé con esta publicación:

¿Recuerda que había montado el volumen www para compartirlo entre los 2 contenedores?

Conclusión

información relacionada