AWS: настройка ECS / ALB, преобразование файл docker-compose, отображение портов на несколько контейнеров

Я знаю, что это не «оригинальный вопрос». Общая тема освещена широко. Тем не менее, у меня проблемы с моей конкретной настройкой:

Я пытаюсь в основном преобразовать следующий файл docker-compose в развертывание на основе ECS в AWS.

version: '3'
services:
  app:
    build:
      context: .
      dockerfile: ./docker/Dockerfile
    restart: always
    container_name: "my-app"
    volumes:
      - ./src:/app/src
      - ./.env:/app/.env
      - ./store:/app/store
    ports: #HOST:CONTAINER
      - "3000:3000"
      - "4000:22"
    networks:
      - my-network
  my-micorservice:
    build:
      context: .
      dockerfile: docker/Dockerfile.MY.MICROSERVICE
    restart: always
    container_name: "my-microservice"
    ports:
      - "5000:5000"
    networks:
      - my-network
networks:
    bb-network:
      driver: bridge

Я использую AWS ECS, ECR, за ALB, развернутым на EC2

У меня есть одна служба, работающая в моем кластере, внутри которой я «определил» это развертывание.
У сервиса есть одно определение задачи.
В задаче 2 контейнера.

Контейнер 1 (my-app) - это веб-сервер, прослушивающий порт 3000.
Контейнер 1 (my-app) также имеет SSHD-сервер, прослушивающий порт 22.
(Теперь я понимаю, что есть более эффективные способы управления SSH в ECS, давайте сделаем вид, что это не имеет значения для этого вопроса).

Отображение порта в настоящее время 0: 3000 в определении контейнера.

Контейнер 2 (my-microservice) также имеет веб-сервер, работающий на порту 5000

Я использую одну целевую группу 1.

Первоначально я успешно развернул контейнер 1 и могу связаться с ним через балансировщик нагрузки, но только через первый открытый порт (3000 через общедоступный 80/443 через ALB)

Теперь я пытаюсь добавить контейнер 2 и достичь вторая услуга через порт 22 в контейнере 1.
Задача успешно запускается, проверки состояния проходят.

Однако я все еще могу получить доступ к контейнеру 1 извне и только на первом сопоставленном порту (порт 3000 через общедоступный 80 или общедоступный 443).

Если я попытаюсь определить дополнительные правила сопоставления портов в конфигурации контейнера 1, задача больше не будет выполняться.

Например, если я попытаюсь изменить контейнер 1 на определения сопоставления портов:
0: 3000
22:22
или
3000: 3000
22:22
или
0: 3000
0:22

Я получаю:
«не удалось разместить задачу, потому что ни один экземпляр контейнера не удовлетворял всем его требованиям. Самый близкий соответствующий экземпляр контейнера 7a628412-1ecc-4f8d-8615-672cfd62bb17 уже использует порт, необходимый для вашей задачи. "

Я временно сделал все порты в группе безопасности широко открытыми и установил правила маршрутизации в ALB, который пересылает 80 443 22 500 всех целевой группе.

Судя по другой логике, мне кажется, что мне нужно несколько целевых групп, но я не могу определить более одной целевой группы при создании службы .
Т.е. каждое определение балансировщика нагрузки принимает только одну целевую группу, а каждое определение службы принимает только один балансировщик нагрузки.

Прямо сейчас, если я пытаюсь попасть в порт 5000, это также направляется в контейнер 1, а не в контейнер 2.

В итоге я пытаюсь достичь:

• контейнер 1: общедоступный 80 и общедоступный 443 -> контейнер 1 3000
• контейнер 1: общий 22 (или, если необходимо, другой порт, например 4000) -> контейнер 1 22
• контейнер 2: общий 5000 -> контейнер 2 5000
• контейнер 2 к контейнеру 1: 3000: 3000
• контейнер 1 к контейнеру 2: 5000: 5000
• контейнер 1 к контейнеру 2: 22:22

примечание: все это было настроено через графический интерфейс администратора AWS до сих пор

Я много тестировал и обновлял методом проб и ошибок, и считаю, что мой базовый подход / понимание должно быть ошибочным.

1. Нужны ли мне отдельные услуги для каждого контейнера?
2. Нужна ли мне одна услуга, но отдельные задачи для каждого контейнера? (если последнее, ПОЧЕМУ Могу ли я создать несколько контейнеров в одной задаче ??)
3. Нужен ли мне новый ALB для каждого контейнера?
4. Новая целевая группа для каждого и т. Д.?
5. или ALB здесь ошибается, и мне нужно вернуться к классическому балансировщику нагрузки?
6. Наконец, следует ли оставить все как есть и попробовать создать третий контейнер NGINX, который действует как прокси-сервер маршрутизации, и попытаться таким образом контролировать входящий трафик? Похоже, это и должна быть работа балансировщиков нагрузки, но я немного запутался!

Извините за длинный пост. Если мне не хватает соответствующей информации о настройке или мне нужно очистить ее. Я сделаю так.

Наконец, я прочитал об инструменте создания ecs-cli, но хотел бы сначала понять, как это сделать «вручную», прежде чем пытаться использовать более автоматизированный инструмент.

Здесь приветствуются любые отзывы или советы, а также указатели на полезные руководства, которые могут иметь отношение к этому варианту использования. Большинство из найденных мной, которые имеют дело с этим, как правило, относятся к более сложной топографии VPN, которая сейчас для меня слишком сложна. Похоже, мой вариант использования должен быть довольно стандартным / дружелюбным к новичкам.

большое спасибо!