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 и могу связаться с ним через балансировщик нагрузки, но только на первом открытом порту (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 000 всех целевой группе.

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

Прямо сейчас, если я попытаюсь попасть в порт 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, которая сейчас для меня слишком сложна. Похоже, мой вариант использования должен быть довольно стандартным / дружелюбным к новичкам.

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