hub - ¿Debo usar contenedores Docker separados para mi aplicación web?

docker store (5)

¿Necesito usar un contenedor Docker separado para mi aplicación web compleja o puedo poner todos los servicios requeridos en un contenedor? ¿Alguien podría explicarme por qué debería dividir mi aplicación en muchos contenedores (por ejemplo, contenedor php-fpm , contenedor mysql , contenedor mongo ) cuando tengo la capacidad de instalar y lanzar todo en un solo contenedor?

Algo en lo que pensar cuando se trabaja con Docker es cómo funciona dentro. Docker reemplaza su PID 1 con el comando que especifica en la ENTRYPOINT CMD (y ENTRYPOINT , que es un poco más compleja) en su Dockerfile. PID 1 es normalmente donde vive su sistema init (sysvinit, runit, systemd, lo que sea). Su contenedor vive y muere por cualquier proceso que se inicie allí. Cuando el proceso muere, su contenedor muere. Stdout y stderr para ese proceso en el contenedor es lo que se le da en la máquina host cuando escribe los docker logs myContainer . Por cierto, esta es la razón por la que necesita saltar a través de aros para iniciar servicios y ejecutar cronjobs (cosas que normalmente realiza su sistema de inicio). Esto es muy importante para entender la motivación para hacer las cosas de cierta manera.

Ahora, puedes hacer lo que quieras. Hay muchas opiniones sobre la forma "correcta" de hacer esto, pero puedes deshacerte de todo eso y hacer lo que quieras. Entonces, PODRÍA descubrir cómo ejecutar todos esos servicios en un contenedor. Pero ahora que sabe cómo docker reemplaza PID 1 con cualquier comando que especifique en CMD (y ENTRYPOINT ) en sus Dockerfiles, podría pensar que es prudente tratar de mantener sus aplicaciones funcionando en sus propios contenedores y dejar que trabajen entre sí. A través de la unión de contenedores . ( Actualización - 27 de abril de 2017: la vinculación de contenedores ha quedado en desuso en lugar de la red de contenedores de ole regular, que es mucho más sólida, ya que la idea es que simplemente une sus contenedores de aplicaciones a la misma red para que puedan comunicarse entre sí) .

Si necesita un poco de ayuda para decidir, puedo decirle por mi propia experiencia que termina siendo mucho más limpio y fácil de mantener cuando separa sus aplicaciones en contenedores individuales y luego se vinculan entre sí. Ahora mismo estoy construyendo una instalación de Wordpress desde HHVM, y estoy instalando Nginx y HHVM / php-fpm con la instalación de Wordpress en un contenedor, y las cosas de MariaDB en otro contenedor. En el futuro, esto me permitirá colocar una instalación de Wordpress de reemplazo directamente frente a mis datos de MariaDB casi sin problemas. Vale la pena en contenedorizar por aplicación. ¡Buena suerte!

Algunos le dirán que debe ejecutar solo 1 proceso por contenedor. Otros dirán 1 aplicación por contenedor. Esos consejos se basan en principios de microservices .

No creo que los microservicios sean la solución correcta para todos los casos, por lo que no seguiría esos consejos a ciegas solo por esa razón. Si tiene sentido tener múltiples procesos en un contenedor para su caso, entonces hágalo. (Ver Supervisor y Phusion baseimage para esa materia)

Pero también hay otra razón para separar los contenedores: en la mayoría de los casos, es menos trabajo para usted hacer.

En Docker Hub , hay un montón de imágenes de Docker listas para usar. Solo saca los que necesites.

Lo que queda por hacer es entonces:

lea el documento para esas imágenes de ventana acoplable (qué variable de entorno establecer, etc.)
cree un archivo docker-compose.yml para facilitar la operación de esos contenedores

Cuando divide su aplicación web en muchos contenedores, no necesita reiniciar todos los servicios cuando implemente su aplicación. Como tradicionalmente, no reinicia su servidor mysql cuando actualiza su capa web.

Además, si desea escalar su aplicación, es más fácil si su aplicación está dividida en contenedores separados. Luego puede escalar aquellas partes de su aplicación que son necesarias para resolver sus cuellos de botella.

Depende de la visión y el mapa de ruta que tenga para su aplicación. Poner todos los componentes de una aplicación en un nivel en este caso es como poner todos los huevos en una canasta.

Siempre que su aplicación requiera seguridad, los problemas relacionados con el rendimiento que separan esos tres componentes en sus propios contenedores serían una solución ideal. No hace falta mencionar que esta división del trabajo entre contenedores tendría un costo y que estaría relacionada con el cableado de esos contenedores para la comunicación y la seguridad, etc.

Probablemente sea mejor tener su aplicación web en un solo contenedor y sus servicios de soporte como bases de datos, etc. en contenedores separados. Al hacer esto, si necesita hacer actualizaciones continuas o reinicios, puede mantener su base de datos en línea mientras sus nodos de aplicaciones están haciendo reinicios individuales para que no experimente tiempo de inactividad. Si tiene almacenamiento en caché con algo como Redis, etc., esto también es útil por la misma razón. También le permitirá agregar más fácilmente nodos para escalar de forma holgada. También le permitirá administrar los contenedores de una manera más adecuada para un propósito específico. Para el tipo de aplicación que está describiendo, veo muy pocos argumentos para ejecutar todos los servicios en un solo contenedor.