Я настраиваю два сервиса с использованием PHP-FPM и NGINX, и каждый раз, когда один сервис обращается к другому, всегда появляется страница NGINX.

Вопрос или проблема

Я создал контейнер с PHP-FPM, который будет выступать в качестве бэкенда и админки для другого PHP-контейнера. Второй контейнер будет служить “фронтендом”, получая информацию из первого контейнера.

Оба контейнера похожи и имеют почти одинаковую конфигурацию NGINX. Разница заключается в том, что сервис, действующий как веб-фронтенд, будет иметь “поддомен с подстановочным знаком”, позволяя доступ к любому поддомену, который PHP будет обрабатывать на бэкенде.

Я могу получить доступ к обоим сервисам отдельно через браузер без проблем (например, http://imobil.localhost:8090 и http://ANY-SUBDOMAIN.web-imobil.localhost:8090). Проблема возникает, когда я пытаюсь получить доступ к сервису API из веб-сервиса — он всегда возвращает HTML-страницу NGINX:

Добро пожаловать в nginx!
Если вы видите эту страницу, веб-сервер nginx успешно установлен и работает. Требуется дальнейшая конфигурация.

Для онлайн-документации и поддержки пожалуйста обращайтесь на nginx.org.
Коммерческая поддержка доступна на nginx.com.

Спасибо за использование nginx.

Я не уверен, правильно ли я это делаю, но, основываясь на моих знаниях, когда я создаю PHP-контейнеры, запускается скрипт, который добавляет .conf файл в контейнер PHP и другой .conf файл в контейнер NGINX.

Я поделюсь файлами здесь, но все же не могу понять, что я делаю не так.

Файл контейнера PHP (админ / API)

server {

    client_max_body_size 0;
    proxy_read_timeout 300;
    proxy_connect_timeout 300;
    proxy_send_timeout 300;

    listen 80;

    server_name imobil.localhost;
    index index.php index.html;
    error_log  /var/log/error.log;
    access_log /var/log/access.log;
    root /var/www/html/imobil/public;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
        gzip_static on;
    }

    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass localhost:9000;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }
}

Файл контейнера NGINX (админ/api)

server {

    client_max_body_size 0;
    proxy_read_timeout 300;
    proxy_connect_timeout 300;
    proxy_send_timeout 300;

    listen 80;

    server_name imobil.localhost;
    index index.php index.html;
    error_log  /var/log/error.log;
    access_log /var/log/access.log;

    root /var/www/html/imobil/public;

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass ms-imobil:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }

    location / {
        try_files $uri $uri/ /index.php?$query_string;
        gzip_static on;
    }
}

Файл контейнера PHP (фронтенд с поддоменом с подстановочным знаком)

server {

    client_max_body_size 0;
    proxy_read_timeout 300;
    proxy_connect_timeout 300;
    proxy_send_timeout 300;

    listen 80;

    server_name web-imobil.localhost;
    index index.php index.html;
    error_log  /var/log/error.log;
    access_log /var/log/access.log;
    root /var/www/html/web-imobil/public;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
        gzip_static on;
    }

    # Поддомен с подстановочным знаком
    location ~ ^/([A-Za-z0-9-]+)\.web-imobil\.localhost {
        set $subdomain $1;
        rewrite ^/(.*)$ /$subdomain/$1 break;
    }

    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass localhost:9000;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }
}

Файл контейнера NGINX (фронтенд с поддоменом с подстановочным знаком)

server {

    client_max_body_size 0;
    proxy_read_timeout 300;
    proxy_connect_timeout 300;
    proxy_send_timeout 300;

    listen 80;

    #server_name web-imobil.localhost;
    server_name web-imobil.localhost *.web-imobil.localhost;

    index index.php index.html;
    error_log  /var/log/error.log;
    access_log /var/log/access.log;

    root /var/www/html/web-imobil/public;

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass ms-web-imobil:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }

    location / {
        try_files $uri $uri/ /index.php?$query_string;
        gzip_static on;
    }
}

Названия контейнеров “ms-imobil” и “ms-web-imobil”

Я нашел решение…

Проблема заключалась в том, что я видел домашнюю страницу nginx, потому что контейнер внутри приложения получал доступ к API и заходил в папку /var/www/html, но ему все еще нужно было зайти в папку “imobil/public”, но этого не происходило. Файл nginx, к которому обращалось приложение, был /var/www/html/index.nginx-debian.html.

Поэтому я понял, что проблема была внутри контейнера ms-imobil.

Я искал решение и нашел его в файле default nginx внутри приложения (/etc/nginx/sites-enabled/default).
Я изменил его, чтобы получить доступ к папке по умолчанию приложения (/var/www/html/imobil/public) и настроил его для доступа к index.php, и это сработало!

Ответ или решение

Для настройки двух сервисов с использованием PHP-FPM и NGINX важно грамотно спроектировать конфигурацию серверов и контейнеров, избегая распространенных ошибок, которые могут привести к проблемам с доступом. Рассмотрим ваш случай подробнее и предложим оптимальные решения.

Проблема

Вы создали два контейнера: один для административной панели и API, а второй — для фронтенда с поддержкой поддоменов. При попытке доступа к API из фронтенда всегда отображается стандартная страница приветствия NGINX, что говорит о неправильной конфигурации маршрутов или доступов между контейнерами.

Анализ конфигурации

На основании предоставленных вами конфигурационных файлов можем выделить следующие аспекты:

  1. Ошибки в пути к файлам:

    • Ошибка может возникать из-за того, что при обращении с фронтенда к API запрос ведётся не в ту директорию. Например, NGINX по умолчанию обрабатывает файлы из /var/www/html/index.nginx-debian.html, вместо ожидаемой директории API /var/www/html/imobil/public.
  2. Конфигурация NGINX:

    • Проверьте, что все конфигурации NGINX настроены правильно, особенно пути к root и обработку index.php. Для API-конфигурации необходимо убедиться, что запросы корректно обрабатываются.
  3. Настройка прокси:

    • Убедитесь, что настройки прокси (fastcgi_pass) указаны правильно и направляют на соответствующие экземпляры PHP-FPM.

Решение проблемы

Для решения проблемы убедитесь в следующем:

  1. Измените конфигурацию NGINX для API:
    Убедитесь, что в конфигурации вашего API-сервера указаны корректные пути для root и для index.php:

    location ~ \.php$ {
       try_files $uri =404;
       include fastcgi_params;
       fastcgi_split_path_info ^(.+\.php)(/.+)$;
       fastcgi_pass ms-imobil:9000;  # Убедитесь, что на самом деле это тот контейнер
       fastcgi_index index.php;
       fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
       fastcgi_param PATH_INFO $nginx_path_info;  # Переменная NGINX
    }
  2. Проверьте директории и права доступа:
    Убедитесь, что NGINX имеет доступ к нужным директориям, и все файлы имеют правильные права. Это может быть причиной, по которой NGINX возвращает стандартную страницу.

  3. Используйте корректные пути в конфигурации:
    Если вы изменяли стандартный сайт, проверьте в /etc/nginx/sites-enabled/default, чтобы указать правильный путь:

    root /var/www/html/imobil/public;  # Убедитесь, что путь правильный

Заключение

Ваша проблема возникала из-за неправильных путей и конфигураций NGINX при обращении к контейнерам. После внесения необходимых изменений и проверки всех путей, как вы уже заметили, было исправлено. Убедитесь, что конфигурации всех компонентов системы согласованы между собой для избежания подобных ситуаций в будущем.

Если у вас возникнут дополнительные вопросы или проблемы, обязательно вернитесь за помощью. Успехов в настройке ваших сервисов!

Оцените материал
Добавить комментарий

Капча загружается...