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


18

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?

Respuestas:


19

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.


3
La idea central es en realidad "cada contenedor debe tener una sola preocupación" y "no es necesariamente cierto que deba haber un solo proceso del sistema operativo por contenedor". docs.docker.com/engine/userguide/eng-image/…
user2640621

Admito que es un atajo para llegar a la idea, nginx no es un solo proceso monolítico ni es php-fpm, pero reemplaza el proceso por preocupación en mi respuesta y todavía está bien nginx hace el enrutamiento, php-fpm hace la interpretación
Tensibai

3
La respuesta suele ser un servicio, un puerto por contenedor, no un solo proceso. Por otro lado, si tiene múltiples procesos en ejecución en un contenedor, debe considerar algunos procesos de inicio, administración de servicios, reinicios, registros independientes, dependencias de paquetes independientes, se vuelve un poco más complicado. Y a veces el mapeo 1: 1 se convierte en mapeo 1: n al escalar.
Jiri Klouda

@Jiri jugando al abogado del diablo: ¿entonces un apache frente a una aplicación de rieles que usa una base de datos postgres debería ir dentro del mismo contenedor? Es solo un servicio en un punto de vista externo después de todo.
Tensibai

1
Respuesta de @JiriKlouda modificada, espero que sea lo suficientemente detallada como para transmitir todos los puntos planteados en los comentarios.
Tensibai

4

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.


3

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.


¿Te refieres a diferentes imágenes en el mismo contenedor?
CarlosAS

¿Cómo comenzará nginx y php-fpm en el mismo contenedor? Por favor agregue un ejemplo.
030

1
@ 030 aquí un ejemplo
CarlosAS

2
@carlos Ejemplo muy válido para fines de desarrollo, bloquearía este tipo de cosas para uso de producción (la supervisión del supervisor dentro de un contenedor puede convertir una pistola de pie con bastante facilidad)
Tensibai

No estoy de acuerdo con esa respuesta, con este razonamiento, un servidor apache con seguridad mod que habla con un tomcat que habla con un servidor postgresql que aloja una sola aplicación debe caber dentro de un solo contenedor.
Tensibai

-1

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

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.