AWS ECS: мониторинг состояния обновления службы

Question

Я пытаюсь перенести набор микросервисов из Docker Swarm в AWS ECS с помощью Fargate.

Я создал кластер ECS. Более того, я инициализировал репозитории с использованием ECR, каждый из которых содержит изображение микросервиса.

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

Кроме того, я создал определение задачи, которое связано со службой. Это определение задачи содержит один контейнер и всю необходимую информацию. Более того, его служба определяет, что задача будет выполняться в VPC, связана с балансировщиком нагрузки и имеет целевую группу. Я предполагаю, что при каждом новом развертывании используется образ с тегом "последний".

Пока с тем, что я объяснил, все ясно и работает хорошо.

Ниже часть, которая смущает меня. После каждой новой сборки я хотел бы обновлять сервис для развертывания новых задач с образом обновления. Я использую cli, чтобы сделать это с помощью следующей команды:

aws ecs update-service --cluster <cluster-name> --service <service-name>

Обычно после выполнения команды я наблюдаю за журналами развертывания на вкладке событий и проверяю состояние службы с помощью следующей команды:

aws ecs describe-services --cluster <cluster-name> --service <service-name>

Наконец, я попытался смоделировать случай, когда вновь созданное изображение содержит неверный код. Таким образом, новые задачи не смогут быть развернуты. Что я засвидетельствовал, так это то, что Фаргейт будет продолжать (без остановки) развертывать новые задачи. Кроме того, помимо журналов событий, describe-services Команда не содержит релевантной информации, кроме того, что делает Fargate (например, регистрация / отмена регистрации задач). Я удивлен, что не смог найти ни одного механизма, который инструктирует Fargate или службу остановить развертывание и выполнить откат к уже существующему.

Я нашел эту статью ( https://aws.amazon.com/blogs/compute/automating-rollback-of-failed-amazon-ecs-deployments/), в которой содержится решение. Однако это довольно сложный процесс, предполагающий, что каждое новое развертывание инициируется новым определением задачи, а это не то, что мне нужно.

Поэтому, учитывая то, что я описал выше, я надеюсь, что вы можете ответить на следующие вопросы:

1) Использование команд консоли (для целей автоматизации). Есть ли способ дать Fargate команду автоматически останавливать текущее развертывание после неудачного развертывания новых задач после нескольких попыток?

2) Используя команды CLI, есть ли способ отслеживать текущее состояние развертывания? Например, при выполнении обновления службы для службы в Docker Swarm терминал генерирует прямые журналы процесса обновления

3) Есть ли способ для Fargate после неудачного развертывания сигнализировать об ошибке, флаге или сообщении?

Answer 1

На данный момент у вас есть способ сделать это:

      aws ecs wait services-stable --cluster MyCluster --services MyService

Предыдущий пример приостанавливается и продолжается только после того, как он может подтвердить, что служба, работающая в кластере, стабильна. Вернется 255код выхода после 40 неудачных проверок.

Чтобы отменить развертывание, включите ECS Circuit Breaker при создании службы:

      aws ecs create-service \
     --service-name MyService \
     --deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true}" \
     {...}

Использованная литература:

• Проверка развертывания службы.
• Автоматический выключатель

Answer 2

На данный момент ECS не предлагает напрямую статус развертывания. После запуска развертывания нет другого способа определить его статус, кроме как постоянно опрашивать обновления, пока у вас не будет достаточно информации, чтобы сделать из них выводы. Плюсunexpected container exitsнигде не регистрируются. Вы должны искать среди неудачных задач. Я получаю их с помощью правила cloudwatch, которое запускает лямбду при изменении состояния задачи.

Рекомендую прочитать: https://medium.com/@aaron.kaz.music/monitoring-the-health-of-ecs-service-deployments-baeea41ae737