Проблема — при попытке доступа к приложению (включая первый раз) я получаю ошибку 404 — Файл не найден.

Question

Я разобрался, поэтому предоставлю подробную информацию, чтобы помочь людям, у которых уже есть такая же проблема, и тем, кто может столкнуться с ней в будущем, учитывая, сколько вопросов и проблем я нашел по этой теме без ответов.

Проблема заключалась в расположении корня FPM в параметрах FastCGI файла конфигурации NGinX.

Значит, я был на правильном пути, и проблема была связана с корневой директивой.

После долгого чтения я наткнулся на этот пост:

Как правильно связать контейнеры php-fpm и Nginx Docker?

И вдруг стало ясно, что у меня есть две разные службы, считывающие два разных пути, и одна из них использует корневой путь другой, которого на самом деле не существует.

Помните, я смонтировал том www для совместного использования двумя контейнерами?

Для контейнера NGinX наwww:/usr/share/nginx/html
Для контейнера NextCloud FPM наwww:/var/html/www

Идея заключалась в том, чтобы два контейнера совместно использовали файловую систему приложения NextCloud.

Чего я не осознавал, так это того, что в этом развертывании цель NGinX — обслуживать статические файлы, такие как CSS, HTML, JPG, JS и т. д., одновременно перенаправляя вызовы PHP в контейнер NextCloud FPM с параметрами FastCGI.

Когда в файле конфигурации NGinX объявляется корневая директива, она задается как переменная $document_root.

root /usr/share/nginx/html;

Таким образом, если задать в качестве корня путь к контейнеру NGinX, /usr/share/nginx/htmlэто позволит обслуживать статические файлы без проблем, но затем, когда выполняется вызов PHP, он передается обработчику php в контейнере NextCloud FPM, а поскольку этого местоположения нет во втором контейнере, он не может найти файл PHP.

Чтобы исправить это, я поискал блок с параметрами FastCGI и искал $document_rootпеременную, нашел ее, и теперь она выглядит так:

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

Обратите внимание, что строка, в которой указано, fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;формирует путь скрипта с уже объявленным корнем, поэтому при обработке nextcloud.example.comон пытается выполнить чтение index.php, и это результирующий вызов контейнера NextCloud FPM:

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

Правильным ответом было бы:

/var/www/html/index.php

Поэтому я создал новую переменную с именем $fpm_rootи установил ее в значение /var/www/html/, затем изменил строку, которая говорит, fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;наfastcgi_param SCRIPT_FILENAME $fpm_root$fastcgi_script_name;

Теперь при каждом вызове статического контента будет определен путь к контейнеру NGinX, а при вызове PHP-контента — путь к контейнеру NextCloud FPM.

Вот как теперь выглядит весь раздел:

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

Теперь он работает и проходит все внутренние проверки работоспособности и безопасности NextCloud после того, как я добавил строку:

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

Заключение

Надеюсь, это поможет тем, кто ищет решение этой проблемы. Проблема заключалась в том, что у меня было два разных пути для служб, обрабатывающих оба типа контента, статический и PHP, и только один из них был правильно настроен в файле конфигурации NGinX.

У вас может быть два (или более) разных корневых расположения для развертывания Docker FPM, и этого, вероятно, будет достаточно для работы или развертывания статического контента в двух или более различных приложениях, использующих один и тот же контейнер FPM для обработки вызовов PHP для NextCloud, WordPress, PHPPGAdmin, Laravel или чего-либо еще, над чем вы работаете.

Answer 1

Я разобрался, поэтому предоставлю подробную информацию, чтобы помочь людям, у которых уже есть такая же проблема, и тем, кто может столкнуться с ней в будущем, учитывая, сколько вопросов и проблем я нашел по этой теме без ответов.

Проблема заключалась в расположении корня FPM в параметрах FastCGI файла конфигурации NGinX.

Значит, я был на правильном пути, и проблема была связана с корневой директивой.

После долгого чтения я наткнулся на этот пост:

Как правильно связать контейнеры php-fpm и Nginx Docker?

И вдруг стало ясно, что у меня есть две разные службы, считывающие два разных пути, и одна из них использует корневой путь другой, которого на самом деле не существует.

Помните, я смонтировал том www для совместного использования двумя контейнерами?

Для контейнера NGinX наwww:/usr/share/nginx/html
Для контейнера NextCloud FPM наwww:/var/html/www

Идея заключалась в том, чтобы два контейнера совместно использовали файловую систему приложения NextCloud.

Чего я не осознавал, так это того, что в этом развертывании цель NGinX — обслуживать статические файлы, такие как CSS, HTML, JPG, JS и т. д., одновременно перенаправляя вызовы PHP в контейнер NextCloud FPM с параметрами FastCGI.

Когда в файле конфигурации NGinX объявляется корневая директива, она задается как переменная $document_root.

root /usr/share/nginx/html;

Таким образом, если задать в качестве корня путь к контейнеру NGinX, /usr/share/nginx/htmlэто позволит обслуживать статические файлы без проблем, но затем, когда выполняется вызов PHP, он передается обработчику php в контейнере NextCloud FPM, а поскольку этого местоположения нет во втором контейнере, он не может найти файл PHP.

Чтобы исправить это, я поискал блок с параметрами FastCGI и искал $document_rootпеременную, нашел ее, и теперь она выглядит так:

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

Обратите внимание, что строка, в которой указано, fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;формирует путь скрипта с уже объявленным корнем, поэтому при обработке nextcloud.example.comон пытается выполнить чтение index.php, и это результирующий вызов контейнера NextCloud FPM:

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

Правильным ответом было бы:

/var/www/html/index.php

Поэтому я создал новую переменную с именем $fpm_rootи установил ее в значение /var/www/html/, затем изменил строку, которая говорит, fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;наfastcgi_param SCRIPT_FILENAME $fpm_root$fastcgi_script_name;

Теперь при каждом вызове статического контента будет определен путь к контейнеру NGinX, а при вызове PHP-контента — путь к контейнеру NextCloud FPM.

Вот как теперь выглядит весь раздел:

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

Теперь он работает и проходит все внутренние проверки работоспособности и безопасности NextCloud после того, как я добавил строку:

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

Заключение

Надеюсь, это поможет тем, кто ищет решение этой проблемы. Проблема заключалась в том, что у меня было два разных пути для служб, обрабатывающих оба типа контента, статический и PHP, и только один из них был правильно настроен в файле конфигурации NGinX.

У вас может быть два (или более) разных корневых расположения для развертывания Docker FPM, и этого, вероятно, будет достаточно для работы или развертывания статического контента в двух или более различных приложениях, использующих один и тот же контейнер FPM для обработки вызовов PHP для NextCloud, WordPress, PHPPGAdmin, Laravel или чего-либо еще, над чем вы работаете.

Проблема — при попытке доступа к приложению (включая первый раз) я получаю ошибку 404 — Файл не найден.

Проблема — при попытке доступа к приложению (включая первый раз) я получаю ошибку 404 — Файл не найден.

Настройка хоста сервера Docker и контейнеров

Что я уже пробовал

Мое определение того, в чем проблема и где я застрял

решение1

Проблема заключалась в расположении корня FPM в параметрах FastCGI файла конфигурации NGinX.

После долгого чтения я наткнулся на этот пост:

Помните, я смонтировал том www для совместного использования двумя контейнерами?

Заключение

Связанный контент