☰

nginx proxy inverso a php-fpm

tag-icon • tag-icon php nginx docker reverse-proxy
nginx proxy inverso a php-fpm

Tengo algunos problemas conceptuales con una configuración de Nginx. Comenzando con un nginxproxy inverso de terminador SSL, utilizo una docker-compose.ymlconfiguración con algunos contenedores, cada uno de los cuales proporciona un servicio virtual. Estos servicios se proporcionan como subdirectorios bajo un único nombre de host:

net --443--> nginx
             | | `--- ContainerA "https://example.com/serviceA/"
             | `----- ContainerB "https://example.com/serviceB/"
             `------- ContainerC "https://example.com/serviceC/"

Fragmentos de listas de procesos:

nginx:~$ ps fax
127285 ?        Ss     0:00  nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf -g daemon off;
127419 ?        S      0:00   \_ nginx: worker process
127420 ?        S      0:00   \_ nginx: worker process
127421 ?        S      0:00   \_ nginx: worker process

ContainerA:~$ ps fax
127132 ?        Ss     0:09  php-fpm: master process (/etc/php/7.0/fpm/php-fpm.conf)
234053 ?        S      8:27   \_ php-fpm: pool www
236952 ?        S      8:12   \_ php-fpm: pool www
259123 ?        S      6:42   \_ php-fpm: pool www

Pensé que se ganaría eficiencia ejecutando una sola instancia de nginxy usándola php-fpmen cada uno de los contenedores.

Ipensarque la premisa de php-fpmes tal que los contenedores no necesitan nginxprocesos propios; el nginxproceso se comunica con cada contenedor a través del puerto 9000 (la parte de red funciona). Sin embargo, en la práctica tengo problemas, por lo que necesito verificar que mi premisa sea sólida:

¿Es correcta esta suposición de una nginxarquitectura básica php-fpm?Alternativamente, ¿se pretende utilizar una infraestructura nginx/ adecuada en concierto directo (mismo host y sistema de archivos) o es razonable y eficiente el alojamiento múltiple/sistema de archivos múltiple?php-fpmphp-fpm

(Recientemente me comuniqué para contratar ayuda y su primera respuesta fue "debe ejecutar nginxen cada contenedor", lo cual, según mi comprensión, no tenía sentido php-fpm).

(Hay muchas preguntas aquí que hacen nginx.confpreguntas específicas, no sobre esta arquitectura ciertamente de nivel superior).

Respuesta1

Esta es una respuesta débil, pero creo:

Sí, esta es en general la filosofía correcta, pero con algunas salvedades. php-fpmestá ahí para procesar .phparchivos, pero creo que no para servir todos los archivos (que no sean php). Para eso, el proceso frontal nginxnecesita ver todos los archivos, incluso si no realiza el procesamiento PHP real.

Para que esto suceda de manera inteligente usando Docker, los archivos en el php-fpmcontenedor deben compartirse explícitamente con el nginxcontenedor. La forma preferida de hacer esto en Docker es proporcionar un volumen con nombre y usarlo para ambos contenedores. Por ejemplo, un docker-compose.ymlarchivo:

version: '2'
services:
  serviceA:
    image: ... # something served with php-fpm
    volumes:
    - tmpvolA:/path/to/serviceA
  serviceB:
    image: ... # something served with php-fpm
    volumes:
    - tmpvolB:/path/to/serviceB
  nginx:
    image: ...
    volumes:
    - tmpvolA:/var/www/serviceA
    - tmpvolB:/var/www/serviceB
volumes:
  tmpvolA:
  tmpvolB:

(Muchos campos no están incluidos...) Los dos volúmenes enumerados al final son los "volúmenes con nombre" de los que habla Docker, y están vacíos por una razón: están destinados a estar vacíos cuando inicie el script, y estarán vacíos. ser llenado por uno de los contenedores. (En realidad, puede ser ocupado por ambos o por ninguno, dependiendo de varios factores).

Un efecto secundario de esto es que los volúmenespersistir.

  • "Esto es bueno" para la eficiencia, ya que no se recrea innecesariamente.
  • "Esto es malo" porque un beneficio de tener servicios virtualizados es que puedes reiniciarlos y tener garantizado un borrón y cuenta nueva. Con volúmenes con nombre persistentes, no se obtiene (automáticamente) un borrón y cuenta nueva, ya que los archivos utilizados en la instancia anterior se utilizarán en lugar de la versión austera en una capa fs inferior.

La solución a este "mal" es vaciar los volúmenes manualmente. Esto se puede hacer al apagar con docker-compose down -v, según la ayuda:

    -v, --volumes       Remove named volumes declared in the `volumes` section
                        of the Compose file and anonymous volumes
                        attached to containers.

También se puede hacer manualmente con docker volume rm <volume-id>o docker volume prune(lo que elimina todos los volúmenes actualmente no utilizados, ya sean temporales o con nombre o lo que sea).

información relacionada