Блог

Введение

Я развертываю приложение Django, использующее Сельдерей для фоновых задач в Amazon ECS, и мы используем CodePipeline для CI/CD. Я хотел бы иметь возможность разделить это на три службы ECS, каждая из которых выполняет только одну задачу — это для того, чтобы их можно было масштабировать независимо. Это оказывается трудно сделать, сохраняя при этом две ключевые цели дизайна:

1. Непрерывная доставка изменений — должна быть автоматизирована
2. Изменениями инфраструктуры необходимо управлять в виде кода

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

Для сервиса, который принимает трафик, все это работает нормально. Проблема связана с теми службами в ECS, которые выполняют фоновые задачи. Вот, я натыкаюсь на препятствие в этом:

• Группы развертывания CodeDeploy настаивают на том, чтобы их связывали с балансировщиком нагрузки, и
• Любому поставщику развертывания, который занимается обновлением определения задачи, требуется Группа развертывания.
  • Я думаю, что это ограничено поставщиками «CodeDeploy» и «ECS Blue/Green».
• Ни мой «планировщик», ни «рабочий» сервис не принимают трафик

Итак, все сводится к следующему: какое развертывание я могу выполнить, которое не требует балансировки нагрузки, но все равно позволит мне обновить определение задачи как часть развертывания?

Подробные сведения

Теперь, чтобы дать вам более подробную информацию, список услуг, которые я хочу, таков:

• служба «веб» — запускает Django, доступ к ALB через порт 8000
• служба «планировщик» — запускает сельдерей «удар», без открытого порта
• служба «рабочий» — запускает работника сельдерея, без открытого порта

Для службы «веб» CI/CD прост, у нас есть приложение для развертывания с кодом, с группой развертывания, которая связана с балансировщиком нагрузки приложений и имеет правильные целевые группы, и это делает развертывание «Синим/зеленым».

Мы создали некоторые пользовательские инструменты, которые генерируют замену taskdef.json и appspec.yml для каждой из услуг. Эти инструменты вызываются на этапе сборки нашего конвейера и (для «веб -» службы) применяются во время развертывания; это делается для того, чтобы обновления сред приложений и ресурсов также управлялись в коде.

Так что поток идет:

1. Создайте новый контейнер docker
2. Создание новых taskdef.json шаблонов из исходного кода — заполнение идентификаторов ресурсов (секретов и т.д.) Путем запроса стека CloudFormation
3. Создайте новое appspec.yml с номером редакции определения задачи, увеличенным на 1
4. CodeDeploy создает новую версию приложения на основе новых спецификаций приложений и TaskDef (артефакты сборки с предыдущего шага) и развертывает обновленную службу в кластере.

Это хорошо работает для «веб -» службы, и я хотел бы сделать что-то подобное для двух других служб, но я не могу найти способ ни того, ни другого: не иметь Группы развертывания, но все еще обновлять Определение задачи; или иметь группу развертывания, но не иметь Балансировщика нагрузки (потому что нет трафика для балансировки нагрузки).

Is there a trick to this? Or a deployment type I’ve missed that is aimed at background services?

I would appreciate any advice you have to offer. Thanks!