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

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

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

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

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

Служба

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

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

Обновление @06/25/2015:

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

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

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

Любые идеи?

Ответ 1

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

Ответ 2

У меня были похожие симптомы, но я нашел ответ в файлах журнала:

/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

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

Ответ 3

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

Если агент сначала запускает имя кластера "default", вам нужно удалить этот файл, а затем перезапустить агент.

Ответ 4

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

Это подробно описано в документации VPC, в частности Сценарий 2: VPC с публичными и частными подсетями (NAT).

Ответ 5

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

Ответ 6

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

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

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

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