Вы не должны иметь все контейнеры в одном и том же определении задачи. Из документов :
Весь ваш стек приложений не должен существовать в одной задаче
определение , и в большинстве случаев не должно. Ваше приложение может охватывать
несколько определений задач путем объединения связанных контейнеров в их
собственные определения задач, каждое из которых представляет отдельный компонент.
Кроме того, обратите внимание, что вы ограничены 10 определениями контейнеров в одном определении задачи, и совершенно нормально использовать только одно определение контейнера в каждом из ваших определений задач.
Что касается масштабирования, вы можете создать сервис для каждого определения задачи. Это позволяет логически разделять компоненты в вашем стеке для независимого масштабирования. Например, если у вас есть 2 службы, одна для фонового API-сервиса и другая для интерфейсного nginx, вы можете создать для них 2 отдельных определения задач, каждое из которых будет масштабироваться независимо.
Возможные причины сгруппировать определения контейнеров в одно определение задачи:
- Они имеют одну логическую цель или общий жизненный цикл (начинаются и заканчиваются вместе).
- Вы хотите масштабировать их вместе.
- Вы хотите, чтобы контейнеры совместно использовали ресурсы, такие как тома данных.
- Контейнеры должны работать на одном и том же экземпляре хоста и выполнять такие вещи, как общение через локальный хост.
С другой стороны, если контейнеры выполняют отдельные логические функции, независимо масштабируются, не разделяют жизненный цикл или ресурсы, такие как тома, вам, вероятно, лучше использовать несколько определений / служб задач.
Существует также некоторая документация по архитектуре приложения для ECS здесь , которая объясняет это далее.