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 basée sur Docker comprenant plusieurs microservices. Il doit consumr des messages Amazon SQS et les traiter. Au début, je voulais utiliser AWS Elastic Beanstalk, mais je suis tombé sur le service de conteneur EC2. Maintenant je ne sais pas lequel choisir.

Elastic Beanstalk prend désormais en charge les environnements multi-conteneurs. C’est bien parce que chaque microservice a son propre serveur d’applications dans un conteneur de 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 soumis à une lourde charge, car il doit traiter énormément de messages SQS, les quatre autres sont presque inactifs, car ils ne nécessitent pas beaucoup de processeurs ou ne contiennent pas beaucoup de messages SQS. Supposons que le 5ème conteneur exécute un serveur d’applications JBoss. Pour autant que je sache, le serveur ne peut consumr qu’un nombre limité de requêtes parallèles, même s’il y a suffisamment de CPU / mémoire disponible.

Si le conteneur JBoss Docker n’est pas capable de gérer le nombre de requêtes, mais qu’il y a suffisamment de CPU / mémoire disponible, je souhaite bien sûr 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 seconde instance, qui est configurable via un groupe de mise à l’échelle automatique dans EB. Maintenant, une seconde instance tourne, mais chaque conteneur à l’exception du cinquième est presque inactif, bien sûr, je ne veux pas qu’il apparaisse inutile à la deuxième instance, ce qui serait un gaspillage de ressources. Seul le 5ème devrait apparaitre et les autres devraient évoluer comme la 5ème échelle en fonction de parameters configurables comme par exemple: CPU / mémoire / SQS.

Je ne sais pas exactement si Amazon ECS fait cela, ou si c’est possible, mais je ne trouve vraiment aucune source sur Internet à propos de ce sujet, qui est généralement dit, basé sur des instances / conteneurs.

EB vs ECS revient vraiment à contrôler. Voulez-vous contrôler votre dimensionnement et votre capacité ou souhaitez-vous que cela soit plus abstrait et que vous vous concentrez 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 indiquer si la mise à l’échelle automatique doit être utilisée ou non. Avec EB, vous fournissez simplement un fichier Dockerfile et EB prend en charge le dimensionnement de votre approvisionnement en nombre et en taille de nœuds, vous pouvez essentiellement oublier l’infrastructure avec l’itinéraire EB.

Voici la documentation de EB sur Docker: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_docker.html

Avec ECS, vous devez d’abord construire l’infrastructure avant de pouvoir déployer le fichier Dockerfile. Cela se résume à 1) votre connaissance de 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 aidera quelqu’un.

La réponse acceptée n’est pas assez claire: sur la base de ce que l’OP décrit, l’OP veut un ECS, pas un MCEB (Multi-Container Elastic Beanstalk). Autant que je sache, MCEB ne tente jamais de conditionner efficacement des conteneurs dans des instances. OP demande dans un commentaire, “si un seul est en charge, il ne redimensionne que celui-ci, ou augmente-t-il toujours les instances et lance-t-il tous les conteneurs, peu importe leur charge?” Et la réponse est “le dernier”; MCEB augmente les instances et démarre tous les conteneurs, quelle que soit leur charge.

modifier

N’utilisez pas l’architecture que vous imaginez.

Comment micro sont vos microservices? Serait-ce ridicule de leur donner chacun un t2.nano? Ensuite, faites-en 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 1/31/18

AWS Fargate semble plutôt cool.