Блог

Мы развертываем образ Docker, который запускает простой Sinatra API, в службе ECS Fargate. Прямо сейчас наше определение задачи определяет изображение с помощью :production тега. Мы хотим использовать CodeDeploy для развертывания с синим / зеленым цветом.

При изменении кода — следует ли нам вставлять новый образ с :production тегом и принудительно выполнять новое развертывание в нашей службе или вместо этого использовать определенные теги в определении нашей задачи (например :97b9d390d869874c35c325632af0fc1c08e013cd ) и создать новую редакцию задачи, а затем обновить нашу службу, чтобы использовать эту новую редакцию задачи?

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

Если мы используем первый подход, сможет ли CodeDeploy откатить неудачное развертывание в случае возникновения проблемы?

Короткий ответ

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

Длинный ответ

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

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

Хорошо то, что ваша старая задача изображения, если она работает правильно, все еще должна быть активна, поскольку минимальная запущенная задача будет равна 1, а поскольку другая задача постоянно терпит неудачу, ваша старая задача изображения не будет списана.

Однако вы можете преодолеть это, добавив событие CloudWatch для запуска лямбда-выражения, которое либо обновляет новую ревизию задачи с помощью тега good image, либо запускает текущий Fargate с предыдущей ревизией определения задачи. Вот статья от AWS об этом: https://aws.amazon.com/blogs/compute/automating-rollback-of-failed-amazon-ecs-deployments /

Немного больше о том, как работает развертывание Fargate здесь и помогает вашей старой задаче, запущенной при сбое нового развертывания, сначала создается новая задача, когда все новые задачи выполняются нормально, старая задача выводится из эксплуатации. Поэтому, если новые задачи не выполняются должным образом, старая задача все еще должна быть активна.