Почему моя служба ECS не может зарегистрировать доступные экземпляры EC2 на моем ELB?
У меня есть конфигурация запуска EC2, которая создает оптимизированный ECS AMI. У меня есть группа автоматического масштабирования, которая гарантирует, что у меня всегда есть как минимум два доступных экземпляра. Наконец, у меня есть балансировщик нагрузки.
Я пытаюсь создать службу ECS, которая распределяет мои задачи по экземплярам в балансировщике нагрузки.
После прочтения документации по балансировке нагрузки ECS я понял, что моя ASG не должна автоматически регистрировать мои экземпляры EC2 в ELB, потому что ECS позаботится об этом. Итак, мой ASG не указывает ELB. Аналогично, мой ELB не имеет зарегистрированных экземпляров EC2.
Когда я создаю свою службу ECS, я выбираю ELB, а также выбираю ecsServiceRole. После создания службы я никогда не вижу доступных экземпляров на вкладке Экземпляры ECS. Служба также не может запускать какие-либо задачи, с очень общей ошибкой...
службе не удалось разместить задачу, так как ресурсы не найдены.
Я занимаюсь этим уже около двух дней и не могу понять, какие параметры конфигурации настроены неправильно. У кого-нибудь есть идеи относительно того, что может быть причиной того, что это не работает?
Обновление @ 25.06.2015:
Я думаю, что это может иметь какое-то отношение к ECS_CLUSTER настройка пользовательских данных.
В моей конфигурации запуска автоматического масштабирования EC2, если я оставляю ввод пользовательских данных полностью пустым, экземпляры создаются с ECS_CLUSTER значение "по умолчанию". Когда это происходит, я вижу автоматически созданный кластер с именем "default". В этом кластере по умолчанию я вижу экземпляры и могу регистрировать задачи в ELB, как и ожидалось. Моя проверка работоспособности ELB (HTTP) проходит, как только задачи зарегистрированы в ELB, и в мире все хорошо.
Но если я изменю это ECS_CLUSTER При настройке чего-то особенного я никогда не вижу кластер, созданный с таким именем. Если я вручную создаю кластер с таким именем, экземпляры никогда не становятся видимыми внутри кластера. Я не могу зарегистрировать задачи в ELB в этом сценарии.
Есть идеи?
8 ответов
В итоге все закончилось тем, что моим экземплярам EC2 не были назначены публичные IP-адреса. Похоже, что ECS должна иметь возможность напрямую связываться с каждым экземпляром EC2, что потребовало бы, чтобы каждый экземпляр имел публичный IP. Я не назначал своим публичным IP-адресам экземпляров контейнера, потому что думал, что они будут все за общим балансировщиком нагрузки, и каждый экземпляр контейнера будет частным.
У меня были похожие симптомы, но я нашел ответ в файлах журнала:
/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
Если вы не можете сделать это на вновь запущенных экземплярах, вы можете сделать это после запуска экземпляра, а затем перезапустить службу.
Вам определенно не нужны публичные IP-адреса для каждого из ваших частных экземпляров. Правильный (и самый безопасный) способ сделать это - настроить шлюз NAT и подключить этот шлюз к таблице маршрутизации, которая подключена к вашей частной подсети.
Это подробно описано в документации VPC, в частности, в Сценарии 2: VPC с публичными и частными подсетями (NAT).
Другая проблема, которая может возникнуть, это не назначение роли с правильной политикой для конфигурации запуска. У моей роли не было AmazonEC2ContainerServiceforEC2Role политика (или разрешения, которые он содержит), как указано здесь.
Возможно также, что агент ECS создает файл в /var/lib/ecs/data, в котором хранится имя кластера.
Если агент сначала запускается с именем кластера по умолчанию, вам нужно удалить этот файл, а затем перезапустить агент.
Проверьте таблицу маршрутов на наличие исходящего соединения с интернет-шлюзом. Это один из важных факторов, позволяющих ECS взаимодействовать с автоматическим масштабированием/EC2 и регистрировать их.
У меня возникла пара проблем с регистрацией экземпляров EC2 в моем кластере ECS. Однако это может быть связано с особенностями управления ролями, группами безопасности и VPC. Ваши результаты могут отличаться.
- мне нужно было указать
ECS_CLUSTER=в данных пользователя для шаблона запуска EC2 — это раздел «Дополнительные сведения» при создании шаблона запуска или запуске экземпляра EC2.
#!/bin/bash
echo ECS_CLUSTER=GenericSericeECSClusterPROD >> /etc/ecs/ecs.config
- Мне нужно было создать конечные точки VPC для следующих сервисов Amazon, прежде чем мои экземпляры EC2 смогут зарегистрироваться в моем кластере ECS:
- com.amazonaws.us-east-2.ecs
- com.amazonaws.us-east-2.ecs-agent
- com.amazonaws.us-east-2.ecs-телеметрия
После этого я перезагрузил свои экземпляры, и они смогли зарегистрироваться в кластере ECS.
Там где несколько слоев проблем в нашем случае. Я перечислю их, чтобы они могли дать вам представление о проблемах, которые необходимо решить.
Моя тюрьма должна была иметь 1 ECS в 1 хозяине. Но ECS вынуждает вас иметь 2 подсети под вашим VPC, и у каждой есть 1 экземпляр хоста докера. Я пытался просто иметь 1 док-хост в 1 зоне доступности и не мог заставить его работать.
Тогда другая проблема заключалась в том, что единственная из подсетей имела подключенный к ней интернет-шлюз. Таким образом, один из них не был доступен для общественности.
Конечным результатом было то, что DNS обслуживал 2 IP для моего ELB. И один из IP будет работать, а другой нет. Таким образом, я видел случайные 404 при доступе к NLB с использованием общедоступного DNS.