как обрабатывать ECS развертывает в CodePipeline для изменений в определении задачи

Question

Я развертываю задачу ECS Fargate с двумя контейнерами: 1 обратный прокси-сервер nginx и 1 сервер python. Для каждого из них у меня есть репозиторий ECR, и у меня есть CIP / CD CodePipeline, настроенный с

CodeCommit -> CodeBuild -> CodeDeploy

Этот поток отлично работает для простых изменений кода. Но что, если я хочу добавить другой контейнер? Я, конечно, могу обновить свой buildspec.yml, чтобы добавить сборку контейнера, но мне также необходимо 1) обновить определение задачи и 2) назначить это определение задачи моей службе.

Вопросы:

1) Если я использую CLI на своем этапе CodeBuild, чтобы создать новое определение задачи и связать его с моей службой, не вызовет ли это развертывание? И тогда мой CodeDeploy попытается развернуть снова, поэтому я закончу развертывание дважды?

2) Этот подход в конечном итоге создаст новое определение задачи и обновит службу при каждом отдельном развертывании. Это плохо? Должен ли я иметь какую-то логику, чтобы вытащить последнюю версию задачи и отличить JSON от версии CodeCommit и обновлять только при наличии разницы?

Спасибо!

Answer 1

Рабочий задания ECS CodePipeline копирует определение задачи и обновляет Image и ImageTag для контейнера, указанного в файле 'imagedefinitions.json', а затем обновляет службу ECS с помощью этого нового TaskDef. Работник не может добавить новый контейнер в определение задачи.

Если я использую CLI на своем этапе CodeBuild для создания нового определения задачи и связывания его с моей службой, не будетэто вызвать развертывание? И тогда мой CodeDeploy попытается развернуть снова, поэтому я закончу развертывание дважды?

Я так не думаю. Существует ли правило события CloudWatch, которое запускает CodeDeploy таким образом?

Этот подход заканчивается созданием нового определения задачи и обновлением службы при каждом отдельном развертывании. Это плохо? Должен ли я иметь какую-то логику, чтобы вытащить ревизию задачи LATEST и отличить JSON от версии CodeCommit и обновлять только при наличии различий?

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

Я задам вопрос, зачем вам добавлять новые контейнеры в определение задачи во время выполнения во время развертывания. Как правило, определение задачи следует изменять реже, и следует регулярно изменять только тег image: в нем - это то, что помогает вам выполнить действие ECS Deploy.