Проблема проверки работоспособности ECS с портом управления загрузкой Spring

Настройка-1: (не работает)

У меня в кластере ECS выполняется задача. Но он падает из-за проверки работоспособности сразу после запуска.

Моя служба основана на весенней загрузке, которая имеет как трафик (для вызовов службы), так и порты управления (для проверки работоспособности). У меня permitAll() разрешение на "*/health" путь.

PFA: я настроил то же самое, выбрав опцию переопределения порта на вкладке проверки работоспособности TG.

введите здесь описание изображения Настройка-2: (Работает нормально) У меня такая же настройка в моем файле docker-compose, и я могу получить доступ к конечная точка проверки работоспособности в моем локальном контейнере. Вот как я определил в своем сочинении:

service:
  image: repo/a:name
  container_name: container-1
  ports:
    - "9904:9904" # traffic port
    - "8084:8084". # management Port

Итак, я попытался настроить порт управления на Task Def в разделе контейнера. Я попытался обновить соответствующую службу для этой последней версии TD, но когда я сохраняю эту службу, я получаю сообщение об ошибке. Это правильный способ справиться с этим?

Ошибка в консоли ECS:

Failed updating Service : The task definition is configured to use a dynamic host port, 
but the target group with targetGroupArn arn:aws:elasticloadbalancing:us-east-2:{accountId}:targetgroup/ecs-container-tg/{someId} has a health check port specified.
Service

Два возможных разрешения:

  1. Есть ли способ указать это сопоставление портов в файле докеров?
  2. Другой способ настроить сопоставление портов управления в конфигурации контейнера определения задачи в ECS? (Предпочтительно)
  3. Избавиться от конечной точки исполнительного механизма Spring Boot и реализовать нашу собственную конечную точку для работоспособности? (ПЛОХО: мне нужно реализовать много вещей, чтобы показать все детали, которые возвращаются при весенней загрузке)

docker spring-boot docker-compose amazon-ecs aws-application-load-balancer
person Sravan    schedule 10.07.2020    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Определение задачи настроено на использование динамического порта хоста, но для цели указан порт проверки работоспособности.

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

введите описание изображения здесь

понимание-динамическое-сопоставление-порт-в-амазонке-ecs

Таким образом, в динамическом порте расписание ECS будет назначать и публиковать случайный порт на хосте, который будет отличаться от 8082, поэтому измените настройку проверки работоспособности на порт трафика.

введите описание изображения здесь

это решит проблему со здоровьем, теперь переходите к вашему запросу

Есть ли способ указать это сопоставление портов в файле докеров?

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

Другой способ настроить сопоставление портов управления в конфигурации контейнера определения задачи в ECS? (Предпочтительно)

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

Избавиться от конечной точки исполнительного механизма Spring Boot и реализовать нашу собственную конечную точку для работоспособности? (ПЛОХО: мне нужно реализовать много вещей, чтобы показать все детали, которые возвращаются при весенней загрузке)

Healthcheck - это простой HTTP. Получите вызов, который ALB ожидает 200 HTTP status code в ответ, поэтому вы можете создать простую конечную точку, которая будет возвращать 200 HTTP status code.

person Adiii    schedule 10.07.2020
comment
Спасибо за ваш ответ. Итак, на данный момент я реализовал простую конечную точку в своем сервисе. Ответ этого API: Тело ответа: {status: true, details: Сервер запущен и работает} Проблема все еще возникает из-за (причины сбоя проверки работоспособности с этими кодами: [502]) - person Sravan; 10.07.2020
comment
хорошо, теперь проверьте вкладку событий ECS, есть ли какое-нибудь событие? или приложение действительно работает? умеют ssh к экземпляру? - person Adiii; 10.07.2020
comment
Да нет. событий каждые 3 минуты, он запускает новую задачу, убивая старую задачу. Вот где я обнаружил это сообщение об ошибке 502. EC2 работает, я тоже могу ssh. Я думаю, проблема в том, что ALB не может прочитать ответ, который я отправляю? Потому что у меня была такая же проблема, когда я проходил старую проверку здоровья. Это означает, что ALB может достичь конечной точки работоспособности как в моих случаях (простой конечной точке, так и конечной точке фреймворка). - person Sravan; 10.07.2020
comment
так что кажется, что задача не выполняется, выполните ssh и запустите curl localhost:PORT/health? если это отвечает внутри экземпляра, мы можем исследовать на уровне ALB - person Adiii; 10.07.2020

arrow_upward
0
arrow_downward

Итак, после 2 дней занятий разными делами:

  1. В определении задачи сетевой режим должен быть типа моста.
  2. В определении задачи оставьте блоки ЦП и памяти пустыми. Предоставления их на уровне контейнера должно быть достаточно.
person Sravan    schedule 11.07.2020