Не удается добраться до контейнера в кластере ECS Fargate, который выглядит правильно настроенным - PullRequest
Новая
       18

Не удается добраться до контейнера в кластере ECS Fargate, который выглядит правильно настроенным

0 голосов
/ 24 марта 2020

У меня есть кластер ECS Fargate, который я настроил после чтения инструкций в другом посте StackOverFlow . У меня есть несколько контейнеров, которые я вставил в репозитории ECR и могу успешно запускать контейнеры. Но переход к http://PUBLIC-IP-ADDRESS не дает доступа к службе, предоставляемой контейнером.

В моем последнем тесте я просто использовал контейнер httpd из Docker Hub потому что это просто и предоставляет веб-страницу по умолчанию. Все еще не повезло.

VP C имеет две подсети - publi c и private - и был сконструирован в соответствии с инструкциями в посте, приведенном выше. Я присоединяю контейнеры - в качестве службы ECS - к публикации c su bnet, а также настраиваю службу, чтобы сделать ее общедоступным c IP-адресом.

Publi c su bnet (CIDR 10.0.1.0/24) имеет следующую таблицу маршрутов: 

10.0.0.0/16 local
0.0.0.0/0 igw-0ad0671cc2924857e

Правила входящих сетевых ACL 

100 ALL Traffic ALL ALL 0.0.0.0/0 ALLOW
  * ALL Traffic ALL ALL 0.0.0.0/0 DENY

Правила исходящих сетевых ACL 

100 ALL Traffic ALL ALL 0.0.0.0/0 ALLOW
  * ALL Traffic ALL ALL 0.0.0.0/0 DENY

(Это правила по умолчанию)

Приватный su bnet (CIDR 10.0.2.0/24) имеет ту же конфигурацию, но вместо этого таблица маршрутизации подключается к шлюзу NAT. Шлюз NAT размещен в publi c net.

Единственное, что я сделал в отличие от инструкций по конфигурации VP C, - это группа безопасности. При создании служб я настраиваю службу с группой безопасности по умолчанию , поставляемой с VP C. Эта группа безопасности разрешает весь трафик c как входящий, так и исходящий.

Для определения задачи - я создал httpd TD, используя сетевой режим awsvp c (это Fargate ECS) , 1/2 ГБ памяти, 0,25 vCPU, открывающий порт 80 на контейнере,

Для Службы я подключил его к VP C, дал ему имя httpd , прикрепил это к publi c su bnet и сказал, что использует publi c IP-адрес.

Служба и содержащаяся в ней Задача запускаются правильно, и Задача показывает publi c IP-адрес , Доступ к этому IP-адресу приводит к долгому ожиданию, и в конечном итоге веб-браузер сдается. (время ожидания)

ОБНОВЛЕНИЕ -

Я не знал о необходимости иметь балансировщик нагрузки. Я попытался добавить балансировщик нагрузки. Но это не имело значения.

Чтобы добавить балансировщик нагрузки, необходимо добавить дополнительные подсети publi c, настроенные, как указано выше. Балансировщик нагрузки приложения подключен к подсетям VP C и publi c. Он прослушивает HTTP (порт 80).

Затем я заново создал службу для контейнера httpd . Во время создания сервиса я сделал все возможное, чтобы настроить его для балансировки нагрузки, а затем описание сервиса дает следующую сводку: 

Target Group Name   Container Name  Container Port
ecs-ecs-go-httpd             httpd              80

1 Ответ

0 голосов
/ 24 марта 2020

ELB не требуется, если вы пытаетесь попасть в указанный c контейнер. Запустите тест TCP для порта 80 и посмотрите ответ.

Powershell: Test-NetConnection <IP address> -port 80

Bash: nc -z <IP address> <80>

Если вы не можете соединиться более чем через 80, то вернитесь назад через части:

  • Откройте задачу
    • Нажмите на ссылку на ENI
    • Дважды проверьте, что группа безопасности имеет 80 открытых
  • Откройте определение задачи
    • Откройте определение контейнера
    • Убедитесь, что порт хоста и порт контейнера оба 80

Если это не проблема с либо группа безопасности, либо определение задачи, которое оставляет только конфигурацию VP C и образ контейнера.

  • Протестируйте образ контейнера, запустив его локально и нажав его на localhost: 80
  • Протестируйте конфигурацию VP C, запустив другой экземпляр EC2 в том же su bnet, что и ваш контейнер с той же группой безопасности
    • S SH in

Если вы можете S SH in, то проблема, скорее всего, не в маршрутизации вопрос. Если вы не можете S SH дважды проверить таблицу маршрутов, VP C ACL и su bnet ACL.

Из нового экземпляра EC2

  • Убедитесь 80 широко открыт, и попробуйте поразить ваш контейнер с его локальным IP
  • Установите веб-сервер
  • Попробуйте поразить это снаружи на порт 80

Если вы можете набрать 80 на вашем экземпляре EC2 с той же группой безопасности в том же su bnet, тогда вы устранили все возможные проблемы с сетью и можете сосредоточиться на том, что может быть не так с конфигурацией ECS.

Наконец, не забудьте снова заблокировать вашу группу безопасности и списки ACL, если вы открыли что-то шире.

...