Dois-je utiliser AWS Elastic Beanstalk ou Amazon EC2 Container Service (ECS) pour mettre à l'échelle les conteneurs Docker?
J'ai développé une application Docker composée de plusieurs microservices. Il doit consommer les messages Amazon SQS et les traiter. Au début, je voulais utiliser AWS Elastic Beanstalk, mais je suis ensuite tombé sur le service de conteneur EC2. Maintenant, je ne sais pas lequel choisir.
Pour l'instant, Elastic Beanstalk prend en charge les environnements multi-conteneurs. C'est formidable car chaque microservice a son propre serveur d'applications dans un conteneur Docker. Le problème suivant est la mise à l'échelle:
Je ne sais pas comment fonctionne le mécanisme de mise à l'échelle. Par exemple: J'ai 5 conteneurs Docker dans mon environnement Elastic Beanstalk. Maintenant, seul le cinquième conteneur Docker est sous forte charge, car il a une énorme quantité de messages SQS à traiter, les quatre autres sont presque inactifs, car ils n'ont pas besoin de beaucoup de CPU ou n'ont peut-être pas beaucoup de messages SQS. Supposons que le 5e conteneur exécute un serveur d'applications JBoss. Autant que je sache, le serveur ne peut consommer qu'une quantité limitée de requêtes parallèles même s'il y a suffisamment de CPU/mémoire disponible.
Si le conteneur Docker JBoss n'est pas en mesure de gérer le nombre de demandes, mais qu'il y a suffisamment de CPU/mémoire disponible, bien sûr, je veux démarrer automatiquement un deuxième conteneur Docker/JBoss sur la même instance. Mais que se passe-t-il si je n'ai pas assez de CPU/mémoire? Bien sûr, je veux tourner sur une deuxième instance, qui est configurable via un groupe de mise à l'échelle automatique dans EB. Maintenant, une deuxième instance tourne, mais chaque conteneur sauf le 5ème est presque inactif, bien sûr, je ne veux pas qu'ils génèrent 4 inutiles à la deuxième instance, ce qui serait un gaspillage de ressources. Seule la 5ème devrait apparaître et les autres devraient évoluer comme la 5ème échelle en fonction de paramètres configurables comme par exemple: CPU/mémoire/SQS.
Je ne sais pas exactement si Amazon ECS fait cela, ou si c'est possible du tout, mais je ne trouve vraiment aucune source sur Internet à propos de ce sujet, qui est en général dit, en fonction de la mise à l'échelle en fonction des instances/conteneurs.
EB vs ECS se résume vraiment à contrôler. Voulez-vous contrôler votre mise à l'échelle et votre capacité ou souhaitez-vous que cela soit plus abstrait et concentrez-vous plutôt sur votre application. ECS vous donnera le contrôle, car vous devez spécifier la taille et le nombre de nœuds dans le cluster et si l'auto-scaling doit être utilisé ou non. Avec EB, vous fournissez simplement un Dockerfile et EB s'occupe de faire évoluer votre provisioning du nombre et de la taille des nœuds, vous pouvez essentiellement oublier l'infrastructure avec la route EB.
Voici la documentation EB sur Docker: http://docs.aws.Amazon.com/elasticbeanstalk/latest/dg/create_deploy_docker.html
Avec ECS, vous devrez d'abord créer l'infrastructure avant de pouvoir commencer à déployer le Dockerfile, ce qui revient vraiment à 1) votre familiarité avec l'infrastructure et 2) le niveau d'effort que vous souhaitez consacrer à l'infrastructure par rapport à l'application.
Ne pas ressusciter une question morte, mais j'espère que cela aide quelqu'un.
La réponse acceptée n'est pas assez claire: sur la base de ce que OP décrit, OP veut ECS, pas Multi-Container Elastic Beanstalk (MCEB). Pour autant que je sache, MCEB n'essaie jamais d'emballer efficacement des conteneurs dans des instances. OP demande dans un commentaire, "si un seul est sous charge, il ne fait que mettre à l'échelle celui-ci, ou fait-il toujours évoluer les instances et démarrer tous les conteneurs, quelle que soit la charge?" Et la réponse est "ce dernier"; MCEB met à l'échelle les instances et démarre tous les conteneurs, quelle que soit la charge sous laquelle ils se trouvent.
Modifier
N'utilisez pas l'architecture que vous imaginez.
À quel point vos microservices sont-ils micro? Serait-il ridicule de leur donner à chacun un t2.nano? Faites-en ensuite chacune une application Docker EB à conteneur unique - les applications de travail EB peuvent être pilotées par des messages SQS. Ou utilisez apex.run .
Modifier le 31/01/18:
AWS Fargate semble plutôt cool.
Modifier le 6/5/19:
Utilisez EKS si vous avez besoin d'orchestrer des conteneurs pour satisfaire une démangeaison. Mais vraiment, essayez d'éviter cela. Les systèmes distribués sont difficiles.