Предположим, у вас есть приложение 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 для нашего приложения, чтобы гарантировать, что всякий раз, когда новый код регистрируется, все тесты запускаются, код выравнивается и сертифицируется, упаковывается и развертывается, не вызывая сбоев.
- Сначала перейдите в консоль 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 старых экземпляра и восстановит счетчик задач до трех. Вуаля!