Tobías, parte de nuestro equipo, nos ha hecho el favor de redactar este artículo porque controla muy bien dicho tema.
Solución:
Nota: La pregunta es muy amplia y podría llenar todo un libro, pero arrojaré algo de luz.
Beneficios de los contenedores
La parte interesante 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 sus máquinas como hosts docker independientes, sino como un conjunto de recursos para alojar sus contenedores.
Los contenedores por sí solos no son innovadores (es decir. El CTO de Docker indica en el último DockerCon ese “a nadie le importan los contenedores”), pero junto con los programadores de última generación y los marcos de orquestación de contenedores, se convierten en una abstracción muy poderosa para manejar software de nivel de producción.
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 los hace convenientes de usar.
En un solo host
En un solo host, los beneficios que puede obtener de los contenedores son (entre muchos otros):
- Úselo como un entorno de desarrollo que imite el comportamiento en un clúster de producción real.
- Construcciones reproducibles independientes del host (conveniente para compartir)
- Probar nuevo software sin sobrecargar su máquina con paquetes que no usará a diario.
Ampliación de un solo host a un grupo de máquinas (clúster)
Cuando llega el momento de administrar un clúster de producción, existen dos enfoques:
- Cree un par de hosts de docker y ejecute / conecte contenedores juntos “manualmente” a través de scripts o usando soluciones como docker-compose. 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.
- Deje que un orquestador de contenedores se encargue de todo y controle la vida útil de sus servicios para afrontar mejor las fallas.
Hay muchos orquestadores de contenedores: Kubernetes, Enjambre, Mesos, Nómada, Fundición en la nubey probablemente muchos otros. Impulsan a muchas empresas e infraestructuras a gran escala, como Ebay, por lo que seguro que encontraron un beneficio en su uso.
Elija la estrategia de replicación correcta
Un recipiente se utiliza mejor como recurso disponible lo que significa que puede detener y reiniciar la base de datos de forma independiente y no debería afectar al backend (aparte de arrojar 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 estén replicado correctamente en varios hosts.
Debes elegir un estrategia de replicacion, para asegurarse de que su servicio se mantenga en funcionamiento. Por ejemplo, puede replicar su base de datos en las zonas de disponibilidad del proveedor de la nube para que cuando una zona completa caiga, sus datos permanezcan disponibles.
Con 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 supervisará 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 afinidades de nodo, sugiriendo al programador que coloque contenedores en el mismo subconjunto de máquinas y los replique en una cantidad adecuada de hosts.
¿Cuántos contenedores por host?
Realmente depende de la cantidad de máquinas que use y de los recursos que tengan.
La regla es que no debe sobrecargar un host con demasiados contenedores si no especifica ninguna restricción de recursos (en términos de CPU o memoria). De lo contrario, corre el riesgo de comprometer el 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 el buen estado del conjunto de servicios que comparten un host.
La restricción de recursos debe tratarse según 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 dimensionar en consecuencia.
Como ejemplo, con Swarm, puede especificar explícitamente la cantidad de CPU o memoria que necesita para un servicio determinado (consulte la documentación del servicio de Docker). Aunque hay muchas posibilidades y también puede dar un límite superior / límite inferior en términos de uso de CPU o memoria. Dependiendo de los valores elegidos, el programador fijará el servicio en 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 documentación).
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 compromiso excesivo. Mesos es especialmente conveniente para el tipo de cargas de trabajo de Big Data.
¿Cómo se deben dividir 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: utilice 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 vaina) 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 se adapte a su caso de uso y aprenda a usarlo. Elija siempre 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 que podría conducir a la caída de un host.