amazon web services - fargate - ¿Debo usar AWS Elastic Beanstalk o el Amazon EC2 Container Service(ECS) para escalar los contenedores Docker?
ecs tutorial (2)
EB vs ECS realmente se reduce al control. ¿Desea controlar su escala y capacidad o desea tener más abstraído y en su lugar se centra principalmente en su aplicación. ECS le otorgará control, ya que debe especificar el tamaño y la cantidad de nodos en el clúster y si se debe usar o no el escalado automático. Con EB, usted simplemente proporciona un archivo Docker y EB se encarga de aumentar el aprovisionamiento de la cantidad y el tamaño de los nodos, básicamente puede olvidarse de la infraestructura con la ruta EB.
Aquí está la documentación de EB sobre Docker: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_docker.html
Con ECS tendrá que construir la infraestructura primero antes de que pueda comenzar a desplegar el Dockerfile, por lo que se reduce a 1) su familiaridad con la infraestructura y 2) el nivel de esfuerzo que desea invertir en la infraestructura frente a la aplicación.
Desarrollé una aplicación basada en Docker compuesta de múltiples microservicios. Debe consumir los mensajes de Amazon SQS y procesarlos. Al principio quise usar AWS Elastic Beanstalk, pero luego me caí sobre el Servicio de Contenedores EC2. Ahora no sé cuál elegir.
A partir de ahora, Elastic Beanstalk es compatible con Multi-Container-Environments. Eso es genial porque cada microservicio tiene su propio servidor de aplicaciones dentro de un contenedor acoplable. El siguiente problema es escalar:
No sé cómo funciona el mecanismo de escala. Por ejemplo: Tengo 5 contenedores Docker en mi Elastic Beanstalk Environment. Ahora, solo el quinto contenedor Docker está bajo una gran carga, ya que tiene una gran cantidad de mensajes SQS para procesar, los otros cuatro están casi inactivos, ya que no necesitan mucha CPU o tal vez no tienen muchos mensajes SQS. Supongamos que el quinto contenedor ejecuta un servidor de aplicaciones JBoss. Por lo que sé, el servidor solo puede consumir una cantidad limitada de solicitudes paralelas, incluso si hay suficiente CPU / memoria disponible.
Si el contenedor JBoss Docker no puede manejar la cantidad de solicitudes, pero hay suficiente CPU / memoria disponible, por supuesto quiero iniciar automáticamente un segundo contenedor Docker / JBoss en la misma instancia. Pero, ¿qué ocurre si no tengo suficiente CPU / memoria? Por supuesto, quiero activar una segunda instancia, que se puede configurar a través de un grupo de escalado automático en EB. Ahora aparece una segunda instancia, pero cada contenedor, excepto el quinto, está casi inactivo, por supuesto, no quiero que engendren 4 innecesarios también en la segunda instancia, lo que sería una pérdida de recursos. Solo el 5to debe engendrar y los otros deben escalar como la 5ta escala en base a parámetros configurables como, por ejemplo: CPU / memoria / SQS.
No sé exactamente si Amazon ECS está haciendo eso, o si es posible en absoluto, pero realmente no puedo encontrar ninguna fuente en Internet sobre este tema, que en general se dice, escalando en función de instancias / contenedores.
No para resucitar una pregunta muerta, pero con suerte esto ayuda a alguien.
La respuesta aceptada no es lo suficientemente clara: según lo que OP describió, OP quiere ECS, no Multi-Container Elastic Beanstalk (MCEB). Hasta donde puedo decir, MCEB nunca intenta empacar eficientemente contenedores en instancias. OP pregunta en un comentario, "si solo uno está bajo carga, solo escala este, ¿o siempre escala las instancias y arranca todos los contenedores, sin importar bajo qué carga están?" Y la respuesta es "el último"; MCEB amplía las instancias e inicia todos los contenedores, sin importar en qué carga se encuentren.
Editar
No uses la arquitectura que estás imaginando.
¿Qué tan micro son tus microservicios? ¿Sería ridículo darles a cada uno un t2.nano? Luego, conviértelos en una aplicación de Docker EB de un solo contenedor: las aplicaciones de trabajo de EB pueden ser impulsadas por mensajes de SQS. O use apex.run .
Editar 31/01/18
AWS Fargate parece bastante genial.