proxy inverso nginx 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 subdirecciones 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 al ejecutar una única instancia de nginxy usarla php-fpmen cada uno de los contenedores.

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

¿Es esta suposición básica de un nginxy php-fpmarquitectura correcta? Alternativamente, ¿una infraestructura adecuada nginx/ está php-fpmdestinada a usarse php-fpmen concierto directo (mismo host y sistema de archivos) o es multi-hosting / multi-filesystem razonable y eficiente?

(Recientemente me contacté para contratar ayuda, y su primera respuesta fue "necesitas correr nginxen cada contenedor", lo que no tenía sentido para mí php-fpm).

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

— r2evans
fuente

Esta es una respuesta débil, pero creo:

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

Para que esto suceda de manera inteligente con 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 la ventana acoplable, y están vacíos por alguna razón: están destinados a estar vacíos cuando inicia el script, y ser llenado por uno de los contenedores. (En realidad, puede ser llenado por ambos o ninguno, dependiendo de varios factores).

Un efecto secundario de esto es que los volúmenes persisten .

"Esto es bueno" para la eficiencia, ya que no se recrea innecesariamente.
"Esto es malo" porque uno de los beneficios de tener servicios virtualizados es que puede reiniciarlo y garantizar una pizarra limpia. Con volúmenes nombrados persistentes, no se obtiene (automáticamente) una pizarra limpia, 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 forma de evitar este "mal" es vaciar los volúmenes manualmente. Esto se puede hacer en el apagado con docker-compose down -v, que 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(que elimina todos los volúmenes no utilizados actualmente, ya sean temporales o con nombre o lo que sea).

— r2evans
fuente