Простые сине-зеленые развертывания на Amazon EC2

Amazon EC2 Container Service (ECS) — это решение Amazon для запуска и организации контейнеров Docker. Он предоставляет интерфейс для определения и развертывания контейнеров Docker для запуска на кластерах экземпляров EC2.

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

В ECS вы создаете определения задач , которые очень похожи на файл docker-compose.yml. Определение задачи — это коллекция определений контейнера , каждое из которых имеет имя, образ Docker для запуска и параметры для переопределения точки входа и команды образа. В определении контейнера также указываются переменные среды, сопоставления портов, тома для монтирования, выделение памяти и ЦП, а также вопрос о том, следует ли считать конкретный контейнер необходимым, и именно поэтому ECS знает, является ли задача работоспособной или ее необходимо перезапустить. ,

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

Если у вас есть определение задачи, вы можете создать сервис из нее. Служба позволяет вам определить количество задач, которые вы хотите запустить, и связать их с Elastic Load Balancer (ELB). Когда задача сопоставляется с определенными портами, например 443, для каждого экземпляра EC2 в кластере ECS может быть запущен только один экземпляр задачи. Следовательно, вы не можете запустить больше задач, чем у вас есть экземпляры EC2. На самом деле вам нужно убедиться, что вы выполняете по крайней мере на одну задачу меньше, чем количество экземпляров EC2, чтобы использовать преимущества сине-зеленых развертываний. Определения задач являются версионными, а службы настроены на использование определенной версии определения задач.

Что такое сине-зеленые развертывания?

Сине-зелёный, чёрно-красный, фуксия-барвинок, действительно не имеет значения, какие цвета используются. Дело в том, что есть две отдельные, но равные среды.

В любой момент ваше приложение работает в одной из сред, в то время как другая среда либо уничтожается для сохранения ресурсов, либо бездействует в ожидании следующего обновления. Эта вторая среда позволяет развертывать обновления, не прерывая текущую живую среду. После того как развертывание будет готово, балансировщик нагрузки / маршрутизатор может быть обновлен для маршрутизации трафика в новую среду.

Эта концепция не нова, но она не получила широкого распространения в связи с требованием второй среды. В зависимости от размера и сложности архитектуры вашего приложения, вторая среда может быть довольно дорогой и сложной в управлении. Использование контейнеров Docker и архитектуры микросервисов может немного облегчить эту проблему. Использование ECS для управления контейнерами в EC2 может еще больше облегчить эту нагрузку.

Как Amazon ECS управляет сине-зелеными развертываниями

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

Рассматривая наиболее простой пример, рассмотрим наличие двух экземпляров EC2 в кластере ECS. У вас есть служба, определенная для запуска одного экземпляра задачи. Эта задача будет выполняться только на одном из экземпляров EC2. Когда определение задачи обновляется, а служба обновляется для использования нового определения задачи, ECS запустит новую задачу во втором экземпляре EC2, зарегистрирует ее в ELB, опустошит соединение из первого, а затем прекратит выполнение старой задачи.

Как я уже упоминал ранее, вам нужно убедиться, что у вас есть хотя бы один дополнительный экземпляр EC2, доступный в кластере, по сравнению с количеством задач, которые вы установили в службе. Если бы в этом базовом примере у нас были запущены две задачи, то в каждом из экземпляров EC2 было бы по одному, у ECS не было бы резервных мощностей для запуска нового, и поэтому развертывание сине-зеленого цвета не могло произойти. Чтобы запустить процесс, вам придется вручную убить хотя бы одну из задач.

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

Ниже приведен ряд диаграмм, иллюстрирующих упрощенный процесс сине-зеленого развертывания в ECS.

1. Для начала у нас есть один сервис, выполняющий две задачи. Эти две задачи разделены между экземпляром EC2 1 и экземпляром EC2 2.

   

2. Создано обновленное определение задачи, а служба обновлена ​​для использования нового определения задачи. ECS запускает новую задачу в EC2 Instance 3 и начинает очищать соединения от предыдущих задач.

   

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

   

4. Когда ECS выполнил желаемое количество запущенных задач, он убивает все оставшиеся задачи, которые все еще выполняли предыдущую версию задачи.

   

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

Развертывание ECS: простой и элегантный способ запуска сине-зеленых развертываний

Запуск сине-зеленых развертываний в ECS довольно прост: создайте новую версию определения задачи (никаких изменений не требуется) и обновите службу, чтобы использовать новое определение. Делать это вручную каждый раз, когда вы хотите развернуть, немного неудобно, особенно если ничего не нужно менять в определении задачи.

Как команда разработчиков нам нравится осуществлять непрерывный процесс интеграции и доставки, который позволяет нам легко запускать развертывания путем объединения кода с соответствующими ветвями в git-репо. Слияние с разработкой означает, что оно должно быть развернуто в нашей промежуточной среде, а слияние с основным означает, что оно должно быть развернуто на производстве. Мы не хотим никакой дальнейшей ручной обработки, кроме слияния и толчка для мерзавца.

Наш непрерывный процесс интеграции клонирует наш репозиторий, создает образы Docker, выполняет модульные тесты для образа, помещает образ в наш частный реестр (который работает на ECS) и, наконец, запускает сине-зеленое развертывание на ECS. Когда мы искали решения для запуска обновления / развертывания в ECS, варианты были сложными. Мы могли бы использовать Amazon CodeDeploy или Elastic Beanstalk, но для этого требовался другой процесс сборки, который не соответствовал тому, что мы выполняли в CI.

Поскольку все, что требуется для запуска сине-зеленого развертывания, — это обновление определения задачи и службы, мы написали сценарий оболочки, который принимает несколько параметров и затем работает с инструментами командной строки AWS, чтобы получить текущее определение задачи, создать новая версия от него, и обновите сервис для его использования. Это работает довольно хорошо и очень просто. После запуска обновления он отслеживает службу, чтобы убедиться, что она запускает обновленную версию перед выходом. Если он увидит, что работает новая версия, он выйдет с нормальным нулевым кодом состояния; в противном случае он выходит с ошибкой. Таким образом, наш процесс CI / CD знает, было ли успешным развертывание, и мы можем получать уведомления о неудачных развертываниях.

Кстати, наш скрипт доступен с открытым исходным кодом с лицензией MIT.

ecs-deploy доступен как в виде сценария оболочки, так и в виде образа Docker. Скрипт использует утилиты Linux, такие как sed, которые не ведут себя одинаково на Linux и Mac, не говоря уже о Windows. Использование образа Docker может дать вам больше согласованности.

Требования к ecs-deploy

ecs-deploy использует другое программное обеспечение для выполнения своей работы. В частности, он использует инструмент CLI AWS, обычно устанавливаемый через pip с помощью команды pip install awscli . Он также использует jq который является JSON-анализатором командной строки.

Хотя сценарий не требует установки каких-либо переменных среды, настоятельно рекомендуется установить учетные данные API AWS таким образом, чтобы они не попадали в историю оболочки и список процессов. Регион AWS также можно задать с помощью переменной среды, чтобы параметры командной строки были минимальными.

Использование сценария оболочки

Если вы клонировали ecs-deploy или загрузили ecs-deploy в свой путь, вы можете просто запустить его, чтобы получить полный набор параметров использования. Вот пример:

В этом примере предполагается, что вы настроили переменные среды для AWS_ACCESS_KEY_ID , AWS_SECRET_ACCESS_KEY и AWS_DEFAULT_REGION .

Использование образа Docker

Если вы не хотите устанавливать jq и AWS CLI (или зависимые инструменты Python, такие как easy_install ), вы можете просто запустить образ Docker.

Лучший способ использовать образ Docker — клонировать репозиторий проекта ecs-deploy и использовать предоставленную конфигурацию docker-compose.yml. Используя Docker Compose для запуска образа, вы можете предоставить переменные среды, связанные с AWS, через файл, чтобы они не входили в аргументы командной строки. Когда вы клонируете репозиторий, скопируйте файл local.env.dist в local.env и добавьте свои учетные данные в файл. Затем вы можете использовать docker-compose run ecsdeploy для запуска образа.

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

Если вы хотите включить ecs-deploy в собственный проект docker-compose, вы можете просто добавить еще один сервис с этим:

Обязательно настройте файл env_file с вашими учетными данными AWS для безопасной работы.

В заключении

Сине-зеленые развертывания предоставляют отличный способ минимизировать производственное влияние во время выпуска, а Amazon EC2 Container Service упрощает многие связанные с этим сложности. Я признаю, что наш вариант использования относительно прост, и что более крупные и более сложные приложения, возможно, не так легко развернуть таким способом, но это абсолютно заслуживает изучения. Комфорт при автоматизации развертываний, вызванных изменениями кода, действительно изменил наше поведение и процессы разработки в лучшую сторону. Это делает нас намного более гибкими, и наши разработчики счастливее, не имея обширных процедур сборки и выпуска.

Мы обнаружили, что наш ecs-deploy очень полезен, прост в использовании и надежен для развертываний, и я надеюсь, что вы тоже сможете извлечь из этого пользу. Мы будем благодарны за ваш вклад в его улучшение и будем рады получить новые запросы на новые функции. Оставьте свои комментарии и вопросы ниже, чтобы продолжить разговор.

Ресурсы

• Сервис-контейнер Amazon EC2
• докер
• Docker Compose
• Docker Hub
• AWS CLI
• JQ
• ECS-развернуть