Почему мой ECS-сервис не может регистрировать экземпляры EC2 с моим ELB?

Question

У меня есть конфигурация запуска EC2, которая строит оптимизированный ECS AMI. У меня есть группа автомасштабирования, которая гарантирует, что у меня есть как минимум два доступных экземпляра. Наконец, у меня есть балансировка нагрузки.

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

После прочтения документации по балансировке нагрузки ECS, я понимаю, что моя ASG не должна автоматически регистрировать мои экземпляры EC2 с помощью ELB, потому что ECS позаботится об этом. Итак, моя ASG не указывает ELB. Аналогично, у моего ELB нет зарегистрированных экземпляров EC2.

Когда я создаю свою службу ECS, я выбираю ELB, а также выбираю ecsServiceRole. После создания службы я никогда не вижу экземпляров, доступных на вкладке ECS Instances. Служба также не может запускать какие-либо задачи с очень общей ошибкой ...

службе не удалось выполнить задачу, потому что ресурсы не были найдены.

Я занимаюсь этим уже около двух дней и не могу понять, какие настройки конфигурации настроены неправильно. Есть ли у кого-нибудь какие-либо идеи относительно того, что может привести к тому, что это не сработает?

Update @ 06/25/2015:

Я думаю, что это может иметь что-то делать с установкой данных ECS_CLUSTER пользователя.

В моей конфигурации запуска автоматического масштабирования EC2, если я оставляю входные данные пользователя пустыми, экземпляры создаются с использованием значения ECS_CLUSTER значения «по умолчанию». Когда это произойдет, я вижу автоматически созданный кластер с именем «default». В этом кластере по умолчанию я вижу экземпляры и могу регистрировать задачи с помощью ELB, как ожидалось. Моя проверка работоспособности ELB (HTTP) проходит после регистрации задач в ELB, и все это хорошо в мире.

Но, если я изменяю этот параметр ECS_CLUSTER на что-то обычное, я никогда не вижу кластера, созданного с этим именем. Если я вручную создаю кластер с этим именем, экземпляры никогда не станут видимыми внутри кластера. В этом случае я не могу регистрировать задачи с помощью ELB.

Любые идеи?

Answer 1

В конце концов, это закончилось тем, что моим экземплярам EC2 не были назначены публичные IP-адреса. Похоже, что ECS должна иметь возможность напрямую связываться с каждым экземпляром EC2, для чего каждый экземпляр должен иметь публичный IP-адрес. Я не назначал общедоступные IP-адреса экземпляров контейнера, потому что я думал, что все они будут за общим балансировщиком нагрузки, и каждый экземпляр контейнера будет закрыт.

Answer 2

Другой проблемой, которая может возникнуть, является не назначение роли с правильной политикой в ​​конфигурацию запуска. В моей роли не было политики AmazonEC2ContainerServiceforEC2Role (или разрешений, которые она содержит) как specified here.

Answer 3

Также может быть, агент ECS создает файл в/var/lib/ecs/data, который хранит имя кластера.

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

Answer 4

я имел схожие симптомы, но в конечном итоге найти ответ в лог-файлах:

/var/log/ecs/ecs-agent.2016-04-06-03:

2016-04-06T03:05:26Z [ERROR] Error registering: AccessDeniedException: User: arn:aws:sts::<removed>:assumed-role/<removed>/<removed is not authorized to perform: ecs:RegisterContainerInstance on resource: arn:aws:ecs:us-west-2:<removed:cluster/MyCluster-PROD 
    status code: 400, request id: <removed> 

В мой случай, ресурс существовал, но не был доступен. Похоже, что OP указывает на ресурс, который не существует или не отображается. Являются ли ваши кластеры и экземпляры в одном регионе? Журналы должны подтвердить данные.

В ответ на другие посты:

Вам НЕ нужен публичный IP-адрес.

Вам нужна: роль ecsServiceRole или эквивалентная IAM, назначенная экземпляру EC2, чтобы поговорить с службой ECS. Кроме того, необходимо указать кластер ECS и может быть сделано с помощью пользовательских данных во время экземпляра запуска или конфигурации запуска определения, например, так:

#!/bin/bash 
echo ECS_CLUSTER=GenericSericeECSClusterPROD >> /etc/ecs/ecs.config 

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

Answer 5

Там, где в нашем случае есть несколько проблем. Я перечислил их, чтобы они могли дать вам некоторое представление о проблемах, которые нужно продолжить.

Мой гаол должен был иметь 1 ECS в 1 хосте. Но ECS заставляет вас иметь 2 подсетей под вашим VPC, и каждый из них имеет 1 экземпляр узла докера. Я пытался просто иметь 1 докер-хост в 1 зоне доступности и не мог заставить его работать.

Тогда еще одна проблема заключалась в том, что только одна из подсетей имела прикрепленный к ней интернет-шлюз. Поэтому один из них не был доступен публике.

Конечным результатом был DNS, обслуживающий 2 IP-адреса для моего ELB. И один из IP-адресов будет работать, а другой - нет. Таким образом, я видел случайные 404s при доступе к NLB с использованием общедоступного DNS.

Answer 6

Вы определенно делаете не нужны публичные IP-адреса для каждого из ваших частных экземпляров. Правильный (и безопасный) способ сделать это - настроить шлюз NAT и подключить этот шлюз к таблице маршрутизации, которая привязана к вашей частной подсети.

Это подробно описано в документации VPC, в частности Scenario 2: VPC with Public and Private Subnets (NAT).