Como iniciar o Nginx (ou ouvir uma porta http) após a inicialização do PHP-FPM em um único contêiner?

Como iniciar o Nginx (ou ouvir uma porta http) após a inicialização do PHP-FPM em um único contêiner?

Tenho problemas ao executar Nginx+PHP-FPM em um único contêiner no Cloud Run. Meu contêiner é baseado em Alpine e gerencia a inicialização de Nginx e PHP-FPM pelo Supervisor. No geral, funciona bem, mas há um curto período de tempo entre o momento em que o Nginx começa a escutar uma porta HTTP e o início do PHP-FPM. Isso leva ao aparecimento de erros HTTP 502 com a seguinte mensagem de log:

6#6: *3 connect() failed (111: Connection refused) while connecting to upstream, client: 169.254.8.129, server: _, request: "POST / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000"

O problema aqui é que o Cloud Run decide que o contêiner está pronto para lidar com solicitações quando abre a porta 8080. Imediatamente após a abertura da porta, o Cloud Run envia uma solicitação que sempre falha na primeira tentativa porque o FPM ainda não está pronto. A mensagem de log NOTICE: fpm is running, pid 4aparece depois que a primeira solicitação chega e falha.

Como gerenciar o Nginx para abrir sua porta somente quando o PHP-FPM estiver pronto?

Configuração do supervisor:

[supervisord]
nodaemon=true
logfile=/dev/null
logfile_maxbytes=0
pidfile=/run/supervisord.pid

[program:php-fpm]
command=php-fpm -F
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
autorestart=false
startretries=0

[program:nginx]
command=nginx -g 'daemon off;'
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
autorestart=false
startretries=0

Configuração Nginx:

# Write temporary files to /tmp so they can be created as a non-privileged user
client_body_temp_path /tmp/client_temp;
proxy_temp_path /tmp/proxy_temp_path;
fastcgi_temp_path /tmp/fastcgi_temp;
uwsgi_temp_path /tmp/uwsgi_temp;
scgi_temp_path /tmp/scgi_temp;

access_log /dev/stdout;
error_log /dev/stderr notice;

server {
        listen 8080 default_server;

        index index.php;

        keepalive_requests    10;
        keepalive_timeout     60 60;

        root /var/www/html/app/public;

        charset utf-8;

        server_name _;

        # Deny hidden files (.htaccess, .htpasswd, .DS_Store).
        location ~ /\. {
            deny            all;
            access_log      off;
            log_not_found   off;
        }
        ########################
        # mappings             #
        ########################

        location ~ \.(js|css|png|jpg|ico) {
            expires 5d;
            try_files $uri $uri/ =404;
            return 404;
        }

        # Allow fpm ping and status from localhost
        location ~ ^/(fpm-status|fpm-ping)$ {
            access_log off;
            allow 127.0.0.1;
            deny all;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            include fastcgi_params;
            fastcgi_pass 127.0.0.1:9000;
        }

        location / {
            client_max_body_size 100m;
            try_files $uri @fpm;
        }

        location @fpm {
            # worker may take long time to finish (max 1 hour)
            fastcgi_read_timeout 3600s;
            fastcgi_split_path_info ^(.+\.php)(/.*)$;
            include fastcgi_params;
            fastcgi_param HTTP_PROXY "";
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME /var/www/html/app/public/index.php;
            fastcgi_param SCRIPT_NAME index.php;
        }
}

Habilitei as páginas de ping/status do FPM. Posso usá-los para acionar a abertura da porta Nginx?

Atualização 1:

Tentei ajustar as prioridades do supervisor e iniciar os segundos:

...
[program:php-fpm]
...
priority=100
startsecs=3

[program:nginx]
...
priority=200

Mas sem sucesso:

[18-Dec-2020 00:31:04] NOTICE: ready to handle connections
[18-Dec-2020 00:31:04] NOTICE: fpm is running, pid 3
2020-12-18 00:30:30,689 INFO success: php-fpm entered RUNNING state, process has stayed up for > than 3 seconds (startsecs)
2020-12-18 00:30:28,388 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
Error POST 502 549 B 3.286 s Google-Cloud-Scheduler https://***.run.app/
169.254.8.129 - - [18/Dec/2020:00:30:27 +0000] "POST / HTTP/1.1" 502 150 "-" "Google-Cloud-Scheduler"
169.254.8.129 - - [18/Dec/2020:00:30:27 +0000] "POST / HTTP/1.1" 502 150 "-" "Google-Cloud-Scheduler" "35.187.131.214"
2020/12/18 00:30:27 [error] 6#6: *3 connect() failed (111: Connection refused) while connecting to upstream, client: 169.254.8.129, server: _, request: "POST / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "***.run.app"
2020-12-18 00:30:26,937 INFO spawned: 'nginx' with pid 4
2020-12-18 00:30:26,829 INFO spawned: 'php-fpm' with pid 3
2020-12-18 00:30:25,730 INFO supervisord started with pid 1
2020-12-18 00:30:25,704 CRIT Supervisor is running as root. Privileges were not dropped because no user

Ambos os aplicativos ainda são iniciados pelo Supervisord simultaneamente e o nginx é inicializado primeiro. O RUNNINGestado que o Supervisord aplica aos aplicativos não significa nada para o Cloud Run.

Responder1

Por enquanto, acabei com o seguinte script de ponto de entrada que garante que o PHP-FPM esteja em execução antes de iniciar o nginx:

#!/usr/bin/env sh
set -e

# Start PHP-FPM as a daemon in the background
php-fpm -D

# Wait until PHP-FPM is up and accepts connections. Fail if not started in 10 secs.
for run in $(seq 20)
do
  if [ "$run" -gt "1" ]; then
    echo "Retrying..."
  fi
  RESPONSE=$(
    SCRIPT_NAME=/fpm-ping \
    SCRIPT_FILENAME=/fpm-ping \
    REQUEST_METHOD=GET \
    cgi-fcgi -bind -connect 127.0.0.1:9000 || true)
  case $RESPONSE in
    *"pong"*)
      echo "FPM is running and ready. Starting nginx."
      # Run nginx without exiting to keep the container running
      nginx -g 'daemon off;'
      exit 0
      ;;
  esac
  sleep .5
done
echo "FPM has failed to start on-time, exiting"
exit 1

O apk add fcgicomando é necessário (como no Alpine Linux).

Também suponho que o php-fpm -Dcomando sempre sai depois que o FPM está pronto, portanto, não são necessários loops, apenas execute os comandos um após o outro. Mas eu não testei.

Responder2

O Supervisor realmente poderia usar uma startdelayopção, mas atualmente não tem uma. Para atrasar o início do nginx, altere o comando especificado para Supervisor (tópico relacionado):

  1. Execute um shell para dormir e inicie o nginx diretamente:

    [program:nginx]
    command=bash -c "sleep 5 && exec nginx -g 'daemon off;'"
    ...
    
  2. Execute um script que durma antes de iniciar o nginx:

    [program:nginx]
    command=delayed-nginx.sh
    ...
    

    delayed-nginx.sh:

    #!/bin/bash
    sleep 5
    exec nginx -g 'daemon off;'
    

Resposta original

Eu não usei especificamente o Supervisor, masesta respostapode funcionar para você. Isso fará com que o Supervisor inicie o nginx apenas quando php-fpmestiver em execução.

[program:php-fpm]
command=php-fpm -F
...
priority=100

[program:nginx]
command=nginx -g 'daemon off;'
...
priority=200

Você também pode precisar definir startsecsum valor mais alto (do que o padrão de 1 segundo) para que o Supervisor só considere php-fpmser iniciado depois de estar em execução por um longo período de tempo, por exemplo, 5 segundos:

[program:php-fpm]
command=php-fpm -F
...
priority=100
startsecs=5

Veja mais na documentação do Supervisor.

informação relacionada