Предположим, у вас есть приложение Node.js, развернутое на AWS ECS. В этом посте мы проведем вас через процесс добавления рабочего процесса непрерывной интеграции в это приложение с помощью AWS Code Pipeline с нулевым временем простоя.

Добавление API проверки работоспособности для вашего приложения

Поскольку мы говорим о ECS, приложение Node.js будет контейнерным и запускаться в среде докеров под управлением Elastic Load Balancer. Типичная конфигурация балансировщика нагрузки должна указывать на TCP-порт, на котором работает приложение, и проверять, открыт ли порт. Это не надежный способ проверки работоспособности вашего приложения, поскольку вполне возможно, что порт открыт, но приложение не загружается из-за недавнего изменения кода. Во-первых, мы добавим /status api в приложение, которое будет возвращать утвердительный ответ HTTP при каждом вызове, как показано ниже.

У нас есть простая конечная точка /status api, которая просто возвращает 200 OK при вызове. Но вы можете добавить логику для проверки работоспособности зависимых компонентов и отправки консолидированного сигнала о работоспособности с помощью вышеуказанного API.

Настройка ELB для использования API монитора работоспособности

Перейдите в консоль балансировщика нагрузки для приложения Node.js из ECS и щелкните вкладку Health Check. Там будет отображаться конфигурация на основе порта по умолчанию. Давайте переопределим это, нажав кнопку Edit Health Check. Добавьте следующую конфигурацию, как показано на этом снимке экрана:

Несколько замечаний:

  • порт должен быть тем, который приложение прослушивает внутри контейнера. В приведенном выше примере приложение работает на порту 3000.
  • интервал подразумевает, что api проверки работоспособности вызывается каждые 30 секунд (YMMV)
  • рекомендуется иметь более высокий порог здорового состояния, чем порог нездоровья, например 4 и 2. Подробнее об этом в следующем пункте.
  • Закройте конфигурацию ELB и откройте определение задачи приложения. В процессе развертывания обновите Minimum Healthy Percent до 100 и Maximum Percent до 200. Таким образом, когда развертывается новая версия кода, ELB будет поддерживать старые и новые экземпляры приложения в течение некоторого времени и уничтожать старый экземпляр после достижения порога работоспособности с новой развернутой версией.

Настройка конвейера развертывания с помощью Code Pipeline

Типичный конвейер развертывания в контексте приложения Node.js будет состоять из следующих шагов:

Мы рассмотрим шаги по созданию вышеуказанного конвейера CI / CD для нашего приложения, чтобы гарантировать, что всякий раз, когда новый код регистрируется, все тесты запускаются, код выравнивается и сертифицируется, упаковывается и развертывается, не вызывая сбоев.

  1. Сначала перейдите в консоль Code Pipeline и нажмите кнопку Create Pipeline.

2. Укажите репозиторий, в котором доступен код приложения.

3. На следующем экране выберите поставщика сборки как AWS CodeBuild и добавьте имя проекта, выбрав параметр создания новой сборки.

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

4. Чтобы ускорить сборку, включите кеш и выберите имя корзины S3. Теперь мы добавим файл build_spec.yml, который будет находиться в корневом каталоге репозитория кода.

5. Мы быстро рассмотрим конфигурацию, представленную в buildspec.yml.

  • Текущая фиксация git фиксируется как IMAGE_TAG, к которому добавляется суффикс к имени образа докера.
  • Мы используем npm ci вместо npm install для установки зависимостей на этапе перед сборкой. Обратитесь к документации npm, чтобы понять, почему эта команда более эффективна и чиста.
  • Команда входа в систему aws предназначена для инициализации переменных, чтобы впоследствии отправить образ докера в AWS ECR.
  • После этапа предварительной сборки мы запускаем набор тестов, и если это успешно, мы создаем образ докера (в этом сообщении предполагается, что у вас есть Dockerfile в корне репозитория, относящегося к загрузке приложения Node.js)
  • На этапе после сборки мы отправляем образ докера в ECR и создаем imagedefinitions.json файл, который будет использоваться на этапе развертывания.

8. Теперь, когда мы запустили набор тестов и упаковали приложение, оно готово к развертыванию.

9. Нажмите «Далее», чтобы перейти к шагу 4. Выберите «Поставщик развертывания» Amazon ECS и выберите соответствующие значения для кластера и имени службы, в которых выполняется ваше приложение.

10. В качестве последнего шага выберите имя файла изображения imagedefinitions.json, которое мы создали после упаковки приложения.

11. Нажав «Далее», вам будет предложено создать роль для конвейера кода или выбрать существующую роль, если вы настроили другие проекты. Делай как надо.

12. В качестве следующего шага просмотрите конфигурацию и отправьте изменения для создания конвейера.

Сине-зеленое развертывание

Окончательная настройка будет выглядеть так:

ELB будет продолжать пинговать каждый экземпляр задачи текущей запущенной версии приложения, используя URL-адрес /status, чтобы подтвердить, что все задачи исправны (предположим, что количество задач равно 3).

Когда в репозитории исходного кода регистрируется новая фиксация, Code Pipeline обнаружит изменение и выполнит шаги, указанные в build_spec.yml. При развертывании новой версии ECS создаст новое определение задачи с последним образом и на короткий период времени там будет 6 запущенных экземпляров приложения (помните, что ранее мы установили Maximum Percent равным 200 ). 3 со старой версией кода и 3 с последней версией.

После того, как ELB подтвердит, что три новых экземпляра задачи исправны, он убьет 3 старых экземпляра и восстановит счетчик задач до трех. Вуаля!

Учить больше