O problema - estou recebendo um erro 404 - Arquivo não encontrado ao tentar acessar o aplicativo (incluindo a primeira vez)

Question

Eu descobri, então darei informações detalhadas para ajudar pessoas que já têm o mesmo problema e para pessoas que possam se deparar com isso no futuro, considerando quantas perguntas e problemas encontrei sobre isso sem respostas.

O problema era o local raiz do FPM nos parâmetros FastCGI do arquivo conf NGinX

Então eu estava no caminho certo e o problema estava ligado à diretiva raiz.

Depois de muito ler me deparei com esse post:

Como vincular corretamente os contêineres php-fpm e Nginx Docker?

E de repente ficou claro que eu tinha dois serviços diferentes lendo 2 caminhos diferentes, e um estava alimentando o caminho raiz do outro onde ele não existia.

Lembra que montei o volume www para ser compartilhado entre os 2 containers?

Para o contêiner NGinX emwww:/usr/share/nginx/html
Para o contêiner NextCloud FPM emwww:/var/html/www

A ideia por trás disso era que os dois contêineres compartilhassem o sistema de arquivos do aplicativo NextCloud.

O que eu não percebi é que nesta implantação, o objetivo do NGinX é servir os arquivos estáticos, como CSS, HTML, JPG, JS, etc., enquanto roteia chamadas PHP para o contêiner NextCloud FPM com os parâmetros FastCGI.

Quando a diretiva root no arquivo conf do NGinX é declarada, ela é definida como a variável $document_root.

root /usr/share/nginx/html;

Portanto, ao definir a raiz para o caminho no NGinX Container, /usr/share/nginx/htmlisso funciona para servir os arquivos estáticos sem problemas, mas então, quando uma chamada PHP é feita, ela é alimentada para o php-hanlder no NextCloud FPM Container, já que esse local não funciona. existir dentro do segundo contêiner, ele não poderá encontrar o arquivo PHP.

Para corrigir isso procurei o bloco com os parâmetros FastCGI e procurei a $document_rootvariável, encontrei e ficou assim:

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;
        }

Observe como a linha que diz fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;está formando o Script Path com a raiz já declarada, então ao processar nextcloud.example.comela tenta ler index.phpe esta é a chamada resultante para o container NextCloud FPM:

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

A chamada correta teria sido:

/var/www/html/index.php

Então criei uma nova variável chamada $fpm_roote configurei-a como /var/www/html/, depois mudei a linha que diz fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;parafastcgi_param SCRIPT_FILENAME $fpm_root$fastcgi_script_name;

Agora, sempre que receber uma chamada para conteúdo estático, ele resolverá o caminho do contêiner do NGinX e quando receber uma chamada para conteúdo PHP, o caminho do contêiner do NextCloud FPM.

Esta é a aparência de toda a seção agora:

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;
        }

Ele funciona agora e passa em todas as verificações internas de integridade e segurança do NextCloud assim que adicionei a linha:

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

Conclusão

E espero que isso ajude quem procura por esse problema, o problema é que eu tinha dois caminhos diferentes para os serviços que processam os dois tipos de conteúdo, estático e PHP, e apenas um deles estava configurado corretamente no arquivo conf do NGinX.

Você pode ter dois (ou mais) locais raiz diferentes para uma implantação FPM dockerizada, e isso provavelmente poderia funcionar para funcionar ou implantar conteúdo estático em dois ou mais aplicativos diferentes usando o mesmo contêiner FPM para lidar com chamadas PHP para NextCloud, WordPress, PHPPGAdmin, Laravel ou o que quer que você esteja trabalhando.

Answer 1

Eu descobri, então darei informações detalhadas para ajudar pessoas que já têm o mesmo problema e para pessoas que possam se deparar com isso no futuro, considerando quantas perguntas e problemas encontrei sobre isso sem respostas.

O problema era o local raiz do FPM nos parâmetros FastCGI do arquivo conf NGinX

Então eu estava no caminho certo e o problema estava ligado à diretiva raiz.

Depois de muito ler me deparei com esse post:

Como vincular corretamente os contêineres php-fpm e Nginx Docker?

E de repente ficou claro que eu tinha dois serviços diferentes lendo 2 caminhos diferentes, e um estava alimentando o caminho raiz do outro onde ele não existia.

Lembra que montei o volume www para ser compartilhado entre os 2 containers?

Para o contêiner NGinX emwww:/usr/share/nginx/html
Para o contêiner NextCloud FPM emwww:/var/html/www

A ideia por trás disso era que os dois contêineres compartilhassem o sistema de arquivos do aplicativo NextCloud.

O que eu não percebi é que nesta implantação, o objetivo do NGinX é servir os arquivos estáticos, como CSS, HTML, JPG, JS, etc., enquanto roteia chamadas PHP para o contêiner NextCloud FPM com os parâmetros FastCGI.

Quando a diretiva root no arquivo conf do NGinX é declarada, ela é definida como a variável $document_root.

root /usr/share/nginx/html;

Portanto, ao definir a raiz para o caminho no NGinX Container, /usr/share/nginx/htmlisso funciona para servir os arquivos estáticos sem problemas, mas então, quando uma chamada PHP é feita, ela é alimentada para o php-hanlder no NextCloud FPM Container, já que esse local não funciona. existir dentro do segundo contêiner, ele não poderá encontrar o arquivo PHP.

Para corrigir isso procurei o bloco com os parâmetros FastCGI e procurei a $document_rootvariável, encontrei e ficou assim:

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;
        }

Observe como a linha que diz fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;está formando o Script Path com a raiz já declarada, então ao processar nextcloud.example.comela tenta ler index.phpe esta é a chamada resultante para o container NextCloud FPM:

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

A chamada correta teria sido:

/var/www/html/index.php

Então criei uma nova variável chamada $fpm_roote configurei-a como /var/www/html/, depois mudei a linha que diz fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;parafastcgi_param SCRIPT_FILENAME $fpm_root$fastcgi_script_name;

Agora, sempre que receber uma chamada para conteúdo estático, ele resolverá o caminho do contêiner do NGinX e quando receber uma chamada para conteúdo PHP, o caminho do contêiner do NextCloud FPM.

Esta é a aparência de toda a seção agora:

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;
        }

Ele funciona agora e passa em todas as verificações internas de integridade e segurança do NextCloud assim que adicionei a linha:

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

Conclusão

E espero que isso ajude quem procura por esse problema, o problema é que eu tinha dois caminhos diferentes para os serviços que processam os dois tipos de conteúdo, estático e PHP, e apenas um deles estava configurado corretamente no arquivo conf do NGinX.

Você pode ter dois (ou mais) locais raiz diferentes para uma implantação FPM dockerizada, e isso provavelmente poderia funcionar para funcionar ou implantar conteúdo estático em dois ou mais aplicativos diferentes usando o mesmo contêiner FPM para lidar com chamadas PHP para NextCloud, WordPress, PHPPGAdmin, Laravel ou o que quer que você esteja trabalhando.

O problema - estou recebendo um erro 404 - Arquivo não encontrado ao tentar acessar o aplicativo (incluindo a primeira vez)

O problema - estou recebendo um erro 404 - Arquivo não encontrado ao tentar acessar o aplicativo (incluindo a primeira vez)

A configuração do Docker Server Host e dos contêineres

O que eu tentei até agora

Minha determinação de qual é o problema e onde estou preso

Responder1

O problema era o local raiz do FPM nos parâmetros FastCGI do arquivo conf NGinX

Depois de muito ler me deparei com esse post:

Lembra que montei o volume www para ser compartilhado entre os 2 containers?

Conclusão

informação relacionada