docker - imagenes - ¿Cuántos contenedores deben existir por host en producción? ¿Cómo deberían dividirse los servicios?

docker tag example

Question

Estoy tratando de entender mejor los beneficios de Docker y no estoy realmente entendiendo cómo funcionaría en la producción.

Digamos que tengo un frontend web, un backend api de descanso y un db. Eso hace 3 contenedores.

Digamos que quiero 3 de la parte frontal, 5 del backend y 7 de la db. (Pregunta menor: ¿Alguna vez tiene sentido tener menos dbs que servidores backend?)

Ahora, dado el escenario anterior, si los empaco en el mismo host, obtengo el beneficio de usar los recursos del host de manera eficiente, pero luego estoy DOA cuando esa máquina falla o tiene una partición de red.

Si los separo en 1 aplicación completa (es decir, 1 FE, 1 BE y 1 DB) por host, y coloco contenedores adicionales en su propio host, obtengo algunas ventajas de usar los recursos de manera eficiente, pero me parece que todavía pierdo significativamente cuando tengo una partición de red, ya que eliminará múltiples servicios.

Por lo tanto, casi estoy llegando a la conclusión de que debería colocar 1 contenedor por host, pero eso significa que estoy usando mis recursos de manera bastante ineficiente y, ¿cuáles son los beneficios de los contenedores en producción? Quiero decir, un sistema operativo puede ser un par de conciertos adicionales por máquina en tamaño de almacenamiento, pero la mayoría de los proveedores de la nube le ofrecen un mínimo de 10 gigas de almacenamiento. Y seamos sinceros, un backend de API de reposo o un front-end web ni siquiera se acercará a los 10 conciertos ... incluso a los sistemas operativos.

Entonces, después de todo eso, ¿estoy tratando de averiguar si me estoy perdiendo el punto de los contenedores? ¿Están los beneficios de mantener todos los contenedores de una aplicación en 1 host, en su mayoría relacionados con las pruebas y los beneficios de desarrollo?

Sé que hay beneficios al mover contenedores entre diferentes proveedores / máquinas fácilmente, pero en su mayor parte, no lo veo como un gran beneficio personal, ya que eso era factible con imágenes ...

¿Hay otros beneficios para los contenedores en producción que me estoy perdiendo? ¿O son los principales beneficios para la prueba y el desarrollo? (¿Estoy pensando en contenedores en producción mal)?

Answer 1

Esto depende del tipo de aplicación que ejecute en sus contenedores. Desde lo alto de mi cabeza, puedo pensar en un par de maneras diferentes de ver esto:

• ¿Su disco de aplicación es pesado?
• ¿Necesitas que la aplicación falle guardada en múltiples máquinas?
• ¿Puede ejecutar varias instancias diferentes de diferentes aplicaciones en el mismo host sin disminuir el rendimiento de ellas?
• ¿Utiliza software como kubernetes o swarm para manejar sus máquinas?

Creo que la mayoría de las preguntas son interesantes para responder, incluso sin contenedores. Los contenedores pueden liberarlo de pensar en hosts individuales, pero aún tiene que decidir y medir la carga de sus máquinas host.

Answer 2

Nota : la pregunta es muy amplia y podría llenar un libro completo, pero arrojaré algo de luz.

Beneficios de los contenedores.

La parte interesante acerca de los contenedores no se trata de su uso en un solo host, sino de su uso en hosts conectados en un clúster grande. No mire a sus máquinas como hosts de docker independientes, sino como un conjunto de recursos para alojar sus contenedores.

Los contenedores solos no son innovadores ( es decir, el CTO de Docker que indica en la última DockerCon que "a nadie le importan los contenedores" ), pero unido a los programadores de última generación y los marcos de orquestación de contenedores, se convierte en una abstracción muy poderosa para manejar la calidad de producción software.

En cuanto al argumento de que también se aplica a las máquinas virtuales, sí, pero los contenedores tienen alguna ventaja técnica (ver: ¿En qué se diferencia Docker de una máquina virtual normal ) sobre las máquinas virtuales que las hace más cómodas de usar?

En un solo host

En un solo host, los beneficios que puede obtener de los contenedores son (entre muchos otros):

• Utilícelo como un entorno de desarrollo que imita el comportamiento en un clúster de producción real.
• Construcciones reproducibles independientes del host (convenientes para compartir)
• Probar software nuevo sin inflar su máquina con paquetes que no utilizará a diario.

Extensión desde un único host a un grupo de máquinas (clúster)

Cuando llega el momento de administrar un clúster de producción, hay dos enfoques:

• Cree un par de hosts de la ventana acoplable y ejecute / conecte contenedores juntos "manualmente" a través de scripts o utilizando soluciones como la ventana acoplable. El control de la vida útil de sus servicios / contenedores está a su cargo, y debe estar preparado para manejar el tiempo de inactividad del servicio.
• Permita que un orquestador de contenedores se encargue de todo y supervise la vida útil de sus servicios para enfrentar mejor las fallas.

Hay muchos orquestadores de contenedores: Kubernetes , Swarm , Mesos , Nomad , Cloud Foundry , y probablemente muchos otros. Alimentan a muchas empresas e infraestructuras a gran escala, como Ebay, por lo que seguramente encontraron un beneficio al usarlas.

Elija la estrategia de replicación correcta

Un contenedor se utiliza mejor como recurso desechable, lo que significa que puede detener y reiniciar la base de datos de forma independiente y no debería afectar al servidor (aparte de lanzar un error porque la base de datos está inactiva). Como tal, debería poder manejar cualquier tipo de partición de red siempre que sus servicios se repliquen correctamente en varios hosts .

Debe elegir una estrategia de replicación adecuada para asegurarse de que su servicio siga funcionando. Por ejemplo, puede replicar su base de datos en las zonas de disponibilidad del proveedor de la nube, de modo que cuando una zona completa se desactiva, sus datos permanezcan disponibles.

Al usar Kubernetes, por ejemplo, puede colocar cada uno de sus contenedores (1 FE, 1 BE y 1 DB) en un pod. Kubernetes se ocupará de replicar este pod en muchos hosts y controlará que estos pods estén siempre en funcionamiento, si no se creará un nuevo pod para hacer frente a la falla.

Si desea mitigar el efecto de las particiones de red, especifique las afinidades de los nodos , insinuando al programador que coloque contenedores en el mismo subconjunto de máquinas y que se replique en un número apropiado de hosts.

¿Cuántos contenedores por host?

Realmente depende de la cantidad de máquinas que uses y de los recursos que tengan.

La regla es que no debes inflar un host con demasiados contenedores si no especificas ninguna restricción de recursos (en términos de CPU o memoria). De lo contrario, corre el riesgo de comprometer al host y agotar sus recursos, lo que a su vez afectará a todos los demás servicios de la máquina. Una buena estrategia de replicación no solo es importante en un solo nivel de servicio, sino también para garantizar una buena salud para el conjunto de servicios que comparten un host.

La restricción de recursos debe tratarse de acuerdo con el tipo de carga de trabajo: una base de datos probablemente usará más recursos que su contenedor de front-end, por lo que debe dimensionarlo en consecuencia.

Como ejemplo, al utilizar Swarm, puede especificar explícitamente la cantidad de CPU o memoria que necesita para un servicio determinado (consulte la documentación de servicio de la ventana acoplable ). Aunque hay muchas posibilidades y también puede dar un límite superior / inferior en términos de uso de la CPU o la memoria. Dependiendo de los valores elegidos, el programador fijará el servicio a la máquina correcta con los recursos disponibles.

Kubernetes funciona prácticamente de la misma manera y puede especificar límites para sus pods (consulte la documentation ).

Mesos tiene políticas de administración de recursos más detalladas con marcos (para cargas de trabajo específicas como Hadoop, Spark y muchas más) y con capacidades de exceso de comunicación. Mesos es especialmente conveniente para el tipo de cargas de trabajo de Big Data.

¿Cómo deberían dividirse los servicios?

Realmente depende de la solución de orquestación:

• En Docker Swarm, crearía un servicio para cada componente (FE, BE, DB) y establecería el número de replicación deseado para cada servicio.
• En Kubernetes, puede crear un pod que abarque toda la aplicación (FE, BE, DB y el volumen adjunto al DB) o crear pods separados para el volumen FE, BE, DB +.

Generalmente: usar un servicio por tipo de contenedor. Con respecto a los grupos de contenedores, evalúe si es más conveniente escalar todo el grupo de contenedores (como una unidad atómica, es decir, una cápsula) que administrarlos por separado.

Resumir

Los contenedores se utilizan mejor con un marco / plataforma de orquestación. Hay muchas soluciones disponibles para lidiar con la programación de contenedores y la administración de recursos. Elija uno que pueda adaptarse a su caso de uso y aprenda a usarlo. Siempre elija una estrategia de replicación adecuada, teniendo en cuenta los posibles modos de falla. Especifique las restricciones de recursos para sus contenedores / servicios cuando sea posible para evitar el agotamiento de los recursos, lo que podría conducir a la caída de un host.