¿Cuáles son las ventajas de dockerizar nginx y php en diferentes contenedores?

Acabo de comenzar a trabajar con Docker y Kubernetes y he estado viendo muchas pilas, en las que algunas personas crean nginx + php en una sola imagen y algunas construyen una imagen con nginx y otra con php (montando la misma ruta y adjuntando ambos contenedores en el mismo despliegue en Kubernetes).

¿Cuáles serían las ventajas de construir dos imágenes acoplables en lugar de instalar ambas nginx + php en la misma?

PHP con nginx generalmente se realiza usando php-fpm, que es un proceso separado.

Manteniendo la idea central del acoplador de un proceso (ver el final de la respuesta para más detalles sobre este punto) por contenedor, tiene sentido tener el proceso nginx y el proceso php-fpm en contenedores separados.

Como la comunicación entre nginx y php-fpm surge a través de fastcgi, el contenedor php-fpm también puede estar en un host separado y esto permite utilizar un grupo de contenedores php-fpm detrás de nginx.

Después del muro de comentarios aquí hay un poco más de antecedentes, la documentación de la ventana acoplable tiene un párrafo sobre la idea de que un contenedor debe tener solo una preocupación .

La idea principal de un contenedor de Linux ( lxc ) es ejecutar un proceso en un espacio de nombres aislado en el nivel de la CPU y la memoria, además de agregar un aislamiento en el nivel del sistema de archivos.
La ventaja es que el compromiso de un proceso dentro de este espacio de nombres no permitirá leer la memoria de otros procesos y, como tal, debería evitar otro compromiso en el host.

Mientras hablan de nginx y php-fpm, funcionan en pareja pero cada uno tiene su propia preocupación, nginx hará la parte HTTP, enrutamiento, validación de encabezados, etc. y php-fpm hará la interpretación del código y devolverá la parte html a nginx . Si bien es habitual tener ambos juntos sirviendo una sola aplicación que no es obligatoria.

Dependiendo del contexto, puede ser más fácil tener un contenedor que incluya toda la pila de una aplicación, en una estación de trabajo de desarrollador, por ejemplo. Pero idealmente para uso en producción, trate de mantener la menor interacción dentro del contenedor, ya que separar los procesos en el mismo contenedor con el supervisor trae su parte del problema en términos de proceso zombie y manejo de registros (ejemplo de la historia aquí solo con fines ilustrativos).

Así que finalmente citaré la página acoplable con algo de énfasis:

Si bien "un proceso por contenedor" es con frecuencia una buena regla general, no es una regla difícil y rápida. Use su mejor criterio para mantener los contenedores tan limpios y modulares como sea posible .

No hay una "regla de bala de plata" que se aplique a todo, siempre es un equilibrio entre la complejidad dentro del contenedor y la complejidad que orquesta los contenedores mismos.

En realidad, un punto que falta aquí es la escalabilidad horizontal. Hay un artículo de Jamie Alquiza que hace mucho tiempo abordó esto:

http://archive.is/pDzz0

En resumen, escala su php-fpm horizontalmente para alcanzar un mayor rendimiento. Escalar Nginx + php-fpm juntos no le ofrece ningún beneficio. Te animo a que hagas algunas pruebas de estrés (por ejemplo, Tsung, Gatling, etc.; no hagas Apache ab, que es un juguete muy viejo) tú mismo para verificar lo que dice el artículo. Personalmente, tengo varias experiencias en el mundo real que demuestran que el artículo es cierto en general.

Pero hay dos inconvenientes (tal vez no para Kubernetes) para máquinas / VM de metal desnudo:

1. ¿Cómo configurar Nginx para descubrir dinámicamente los cambios del contenedor php-fpm? Esta es la parte facil.
2. ¿Cómo compartimos los mismos sistemas de volumen / archivo después de escalar? Los contenedores Nginx y php-fpm deben leer exactamente el mismo contenido para alcanzar la consistencia. Esto te deja con la menor parte del rompecabezas (y la parte más divertida) para trabajar.

EDITADO: ahora es casi la mitad del año 2019. El modelo anterior, php-fpm + nginx en el mismo pod, tiene un uso diferente. Si está familiarizado con la malla de servicio, entonces nginx (o lo que se llama Nginmesh) sirve como un sidecar para manejar el tráfico con rumbo este-oeste. El tráfico con destino este-oeste se usa principalmente para autenticarse entre servicios u otras funcionalidades sofisticadas, mientras que php-fpm puro no puede hacerlo.

No existe un beneficio significativo que supere la necesidad de administrar dos contenedores. Siempre que tenga una relación 1: 1 entre los procesos y sirvan para un único propósito, colóquelos en el mismo contenedor.

La ventaja es: puede ejecutar múltiples contenedores php-fpm en el back-end, lo llamamos clúster PHP, a través de varios puertos. Ejemplo de puerto 9000, 9001, 9002 ... y así sucesivamente