Эластичный бобовый шток против ECS для многоконтактного докера

Question

Работает на многоконтейнерной системе. Я оценивал плюсы и минусы эластичного бобового стебля и ECS. Есть много вопросов, таких как this, в котором говорится, что ECS имеет более точный контроль над контейнерами по сравнению с EB, но они не указали. В моей перспективе здесь есть разница между ними:

+--------------------------------------------+--------------------------------------------------+ 
|    Elastic Beanstalk    |      ECS      | 
+--------------------------------------------+--------------------------------------------------+ 
| Natively support auto-scaling and load  | Auto-scaling can be done with     | 
| balancing. Has the ability to deploy  | some extra efforts. But other AWS resources  | 
| other AWS resources along with the   | cannot be deployed with ECS.      | 
| containers.        |             | 
+--------------------------------------------+--------------------------------------------------+ 
| Container definitions are written in  | Container definitions has to be written in a  | 
| dockerrun.aws.json file. All the links  | separate task definition file. Scaling of the | 
| can be written here. This is more like  | container can be specified in     | 
| docker compose file.      | service definitions.        | 
+--------------------------------------------+--------------------------------------------------+ 
| Scaling happens based on CloudWatch  | Here, we have a precise control to scale   | 
| metric. But when a new instance is   | a particular task (container). This is more  | 
| launched, the whole containers in   | like declarative. It does not take in to account | 
| task definition file will be launched  | about the instances, it maintains the count of | 
| again (imperative), even though some  | tasks correctly. Scales based on the    | 
| of the containers actually has no traffic. | CPU/Memory usage of a specific container.  | 
+--------------------------------------------+--------------------------------------------------+ 

Я не уверен в третьем пункте. Исправьте меня, если я ошибаюсь. Если есть другие различия между этими двумя, дайте мне знать.

Answer 1

Первый пункт: если вы не используете Эластичный бобовый шток и хотите развернуть другие ресурсы AWS с вашим приложением, создайте шаблон CloudFormation и используйте наборы изменений CloudFormation для запуска, обновления и срыва приложения.

С третьим пунктом в эластичном бобовом стебле используется функция автоматического масштабирования AWS, которая работает только на уровне создания и удаления экземпляров EC2. Таким образом, если вы используете единую контейнерную среду с несколькими контейнерами в Elastic Beanstalk, масштабирование не только создаст другой контейнер, но и весь экземпляр EC2 с Docker со всеми одинаковыми контейнерами. Автомасштабирование также можно использовать из шаблона CloudFormation без использования Elastic Beanstalk. Он по-прежнему работает только на уровне экземпляров EC2.

Другим вариантом является использование эластичного бобового стебля с его автоматическим масштабированием, настройка среды на один контейнер-докер с контейнером, который вы хотите масштабировать, и добавить другие контейнеры как AWS::ECS::Service custom resources. Например, ваш единственный контейнер может быть обработанным тяжелым интерфейсом, а другой контейнер может быть общим хранилищем данных. Таким образом, вы получите хорошее управление версиями/развертыванием/развертыванием из Elastic Beanstalk, но имеете контейнеры, которые являются единичными (для каждой эластичной среды Beanstalk).