У меня возникают проблемы с пониманием смысла AWS реализации обнаружения служб в ECS при использовании режима моста и в целом пути к (относительно базовым c) контейнерным сетям, несмотря на многочисленные AWS сообщения в блоге по этому вопросу.
Обнаружение службы, как мне кажется, связано с решением динамически генерируемой доступности контейнеров (в задачах), поэтому, подобно docker пользовательским сетям, я могу получить доступ к различным задачам в кластере с предопределенным каноническим именем хоста. Name -space в VP C.
Я убедился в VP C, что:
DNS hostnames: Enabled
DNS resolution: Enabled
Когда определение службы определено при использовании режима моста:
- он все еще привязывается к динамической c части имени, которое я не указал.
{
"Name": "my-service.my-namespace.",
"Type": "SRV",
"SetIdentifier": "4b46cb82ba434dasdb163c1f06ca5c083",
"MultiValueAnswer": true,
"TTL": 60,
"ResourceRecords": [
{
"Value": "1 1 27017 4b46cb82ba434dasdb163c1f06ca5c083.my-service.my-namespace."
}
],
"HealthCheckId": "862bd287-2b41-43ac-8442-a3d27042482b"
},
Поэтому мне нужно вручную просматривать записи каждый раз, когда служба создается или обновляется. Я не могу dig
my-service.my-namespace например, эта запись не существует.
И:
2. Каждый раз, когда сервис обновляется, запись восстанавливается ...
Чтобы попасть сюда, мне нужно сделать:
$ aws servicediscovery list-namespaces
$ aws route53 list-resource-record-sets --hosted-zone-id $ZONE_ID --region us-east-1
Мое приложение в настоящее время обращается к хостам задач через внедренные переменные среды, но если запись обновляется при каждом обновлении службы, это не запуск. Кажется, что вся документация / форумы, с которыми я сталкивался, создают какой-то динамический обходной путь поиска 1054 * SRV (кажется, hacki sh?) Или просто переключаются в режим awsvp c, но тогда почему эта служба доступна в все под мостом / хостом?
Очевидно, я упускаю что-то фундаментальное.
Кроме того, я использую динамическое отображение портов c. Если я этого не сделаю, произойдет сбой обновления, когда порт уже используется ошибки. Аналогичным образом, попытка запустить новый экземпляр задачи с помощью планирования создает ту же ошибку.
Я могу подключиться в заданном docker контейнере в задаче с внутренним частным DNS экземпляра, т.е. ip-172-31-52-141.ec2.internal, но здесь я за пределами VP C (?), т.е. теперь мне нужно указать динамически отображаемый порт. Так что это тоже не стартер.
Все это находится за опубликованным c ALB (для динамического c разрешения порта и т.д. c), и это работает нормально, запросы извне AWS правильно разрешаются для целевых групп / целевые услуги.
Если я переключусь в режим awsvp c и включу обнаружение служб, у меня может быть несколько задач / служб, работающих в частном порядке.
Однако что если я хочу, чтобы несколько служб взаимодействовали, но дополнительно с одной службой / task может содержать несколько docker контейнеров (например, локализованный кэш Redis). Я не могу указать «ссылку» для этих контейнеров, если сетевой режим снова не будет «мостом».
вот вопрос TLDR:
У меня есть 2 задачи и служба, связанная с каждой задачей. У каждой задачи может быть несколько экземпляров, поэтому порты должны быть динамическими c. В каждой задаче у меня есть 2 контейнера.
Каков общий подход, позволяющий различным службам взаимодействовать через предопределенное разрешение dns host.namespace, и контейнеры внутри каждой задачи связываются друг с другом?
Извиняюсь за длинный пост, но как новичок в ECS / AWS, я действительно борюсь здесь;)
Любые отзывы или советы действительно приветствуются.