Как использовать blue-green-деплой: руководство по выкату одного и нескольких приложений

Всем привет! На связи Юрий Шахов, DevOps-инженер компании «Флант». Недавно мне нужно было организовать бесшовный деплой клиентских приложений. Я изучил различные подходы для этого и остановился на стратегии blue-green-деплоя. Но проблема была в том, что я не мог найти материалов с практическими примерами, в найденных статьях описывались только теоретические аспекты. Поэтому мне пришлось изучать подход blue-green-деплоя самостоятельно. И теперь мне захотелось поделиться этим опытом.

В статье я задеплою приложение в blue-green, а также покажу, как работает смена между blue и green на практике. Я не буду рассматривать различные стратегии деплоя, а также их преимущества. Для ознакомления с теорией blue-green и других вариаций рекомендую почитать наш материал про различные стратегии деплоя в Kubernetes.

Эту же статью я поделил на две части: сначала рассмотрим реализацию деплоя приложения в blue-green-стратегии, а затем попробуем werf bundle для деплоя нескольких приложений из одного репозитория. Есть разные способы реализовать эту стратегию, можно использовать дополнительные инструменты, такие как Service Mesh, Argo CD и другие. Я же буду деплоить с помощью werf, все ресурсы описывать как Helm-шаблоны, а для развёртывания использовать GitLab. Предполагается, что читатель знаком с этими технологиями. Особенность здесь в том, что применяются нативные сущности и механизмы в виде лейблов для Kubernetes. Далее green и blue будем называть «версиями» приложения. Также в этой статье не будем рассматривать вопросы миграции баз данных, хотя для некоторых приложений это может быть необходимо.

Простой blue-green

Предположим, что у нас есть приложение и мы хотим его задеплоить. Делать это будем в два этапа: 

1. Деплой самого приложения (deploy_app), например Deployment и Service.

2. Смена версии: деплой Ingress с нужным именем Service (deploy_ingress). В этой стадии будет переключение трафика между версиями приложения.

Представим это в виде пайплайна:

Для реализации определим переменную deploy_version (значение будем брать из GitLab CI, который рассмотрим позже), которая будет равна blue или green и будет подставляться в Helm-шаблоны. Для Deployment и Service добавляем лейблы:

{{ $deploy_version := "" }} {{ if .Values.werf.deploy_version }} {{ $deploy_version = print "-" .Values.werf.deploy_version }} {{ end }} --- apiVersion: apps/v1 kind: Deployment metadata:   name: {{ .Chart.Name }}{{ $deploy_version }}   labels:     app: {{ .Chart.Name }}{{ $deploy_version }} ... --- apiVersion: v1 kind: Service metadata:   name: {{ .Chart.Name }}{{ $deploy_version }} spec:   selector:     app: {{ .Chart.Name }}{{ $deploy_version }} ...

Чтобы трафик дошёл до пода, нужно создать Ingress. Для обращения к определённой версии приложения мы будем указывать Service с нужным именем (blue или green). В таком случае шаблон Ingress будет выглядеть следующим образом:

{{ $deploy_version := "" }} {{ if .Values.werf.deploy_version }} {{ $deploy_version = print "-" .Values.werf.deploy_version  }} {{ end }} --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata:   name: example   labels:     deploy-version: {{ .Values.werf.deploy_version | quote }} spec:   ingressClassName: nginx   rules:   - host: example.com     http:       paths:       - path: /         pathType: Prefix         backend:           service:             name: {{ .Chart.Name }}{{ $deploy_version }}             port:               name: http  tls:   - hosts:     - example.com     secretName: {{ .Chart.Name }}-tls

Вместо изменений на Ingress можно изменять Service, направляя трафик на blue или green Deployment по лейблам, но делать этого не рекомендуется. В таком случае мы потеряем возможность обращаться к Deployment по имени Service в кластере. Это может быть проблемой для проверки правильности обновления, так как не получится обратиться к новой версии до того, как на неё направится весь трафик. 

Ещё можно создать второй Ingress, ведущий на неактивную версию, с другим доменом для тестирования. В таком случае нужно закрыть его за авторизацией для ограничения доступа.

Теперь рассмотрим пайплайн. При деплое приложения необходимо объявлять переменную deploy_version — версию, на которую будет производиться деплой. Для werf это можно сделать так:

werf converge --set "werf.deploy_version=${DEPLOY_VERSION}"

Также во время деплоя будем проверять, что версия не является активной, то есть на неё не идёт трафик, и наш выкат не повлияет на пользователей. Сама проверка реализована следующим образом: мы получаем информацию о том, на какой Service указывает работающий в кластере Ingress, и находим там blue или green.

Ниже пример полного gitlab-ci.yml:

stages:   - deploy_app   - deploy_ingress  .check_upstreams: &check_upstreams   - APP_CURRENT_ACTIVE=$(werf kubectl -n ${WERF_NAMESPACE} get ingress example --output=custom-columns='SVCs:..service.name' --no-headers --ignore-not-found | awk -F '-' {'print $NF'})  .deploy_app:   stage: deploy_app   script:     - *check_upstreams     - if [[ ${KUBE_CURRENT_ACTIVE} == ${UPSTREAM} ]];       then         tput setaf 9 && echo "Обнаружена попытка деплоя на активную версию, деплой будет остановлен!" && exit 1;       else         werf converge \           --release example-${UPSTREAM} \           --set "werf.deploy_version=${UPSTREAM}";       fi;   allow_failure: false  .deploy_ingress:   stage: converge_ingresses   script:     - *check_upstreams     - if [ ${APP_CURRENT_ACTIVE} == ${DEPLOY_VERSION} ];       then         tput setaf 9 && echo "Обнаружена попытка переключения на активную версию, деплой будет остановлен!" && exit 1;       else         werf converge         --set "werf.deploy_version=${DEPLOY_VERSION}"       fi;  Deploy to blue:   extends: .deploy_app   environment:     name: production   variables:     UPSTREAM: "blue"  Deploy to green:   extends: .deploy_app   environment:     name: production   variables:     UPSTREAM: "green"  Switch to blue:   extends: .deploy_ingress   environment:     name: production   variables:     DEPLOY_VERSION: "blue"  Switch to green:   extends: .deploy_ingress   environment:     name: production   variables:     DEPLOY_VERSION: "green"

Что мы в итоге сделали:

1. Скорректировали Helm-шаблоны для Deployment, Service и Ingress, добавив к ним «цвет» нашей версии.

2. Написали CI, который:

   • деплоит приложение в blue и green;

   • деплоит Ingress, который переключает трафик на нужную версию;

   • проверяет, что деплои не происходят на активную версию.

А теперь перейдём к части с бандлами.

Деплой нескольких приложений с помощью werf bundle

Зачем могут понадобиться бандлы? Допустим, клиенту необходимо деплоить несколько приложений вместе, соответственно, делать это удобнее из одного репозитория. Механизм бандлов позволяет опубликовать чарт приложения и деплоить его в дальнейшем без доступа к конкретному Git-репозиторию. Всё, что требуется, — это доступ к container registry, где хранится бандл. Такой подход позволяет упростить процесс доставки чарта приложений.

Упаковывать приложения мы будем с помощью werf bundle. Подробно на описании инструмента останавливаться не будем, с его преимуществами и кейсами использования можно ознакомиться в документации.

Создание бандлов происходит в основном репозитории приложения, здесь же сконцентрируемся только на развёртывании. В CI-файле укажем названия приложений и соответствующие переменные для каждого из них: репозиторий, тег бандла и название Ingress:

variables:   FIRST_REPO_BUNDLE: registry.gitlab.awesome.ru/frontend/first   FIRST_TAG: "0.1"   FIRST_INGRESS: first ...  # apps_for_matrix & apps_for_bash должны содержать одинаковые значения!  .apps_for_matrix: &apps_for_matrix   ["FIRST", "SECOND", "THIRD", "FOURTH", "FIFTH"]  .apps_for_bash: &apps_for_bash   APPLICATIONS=("FIRST", "SECOND", "THIRD", "FOURTH", "FIFTH")

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

На этой стадии должны выполняться следующие условия:

• Активная версия у всех приложений одинаковая.

• У приложения нет активных версий (при условии, что оно ещё не было задеплоено в кластер).

stages:   - check_upstreams   - deploy_apps   - deploy_ingresses  .base_werf: &base_werf   - set -x   - type trdl && source $(trdl use werf 2)   - werf version   - type werf && source $(werf ci-env gitlab --verbose --as-file)  .check_upstreams: &check_upstreams   - *base_werf   - *apps_for_bash   - |     GREEN=false     BLUE=false     EMPTY=0      for APP in ${APPLICATIONS[@]}     do       REPOSITORY_INGRESS=${APP}_INGRESS       APP_CURRENT_ACTIVE=$(werf kubectl -n ${WERF_NAMESPACE} get ingress ${!REPOSITORY_INGRESS} --output=custom-columns='SVCs:..service.name' --no-headers --ignore-not-found | awk -F '-' {'print $NF'})        EMPTY=$((EMPTY+1))       if [[ ${APP_CURRENT_ACTIVE} == "green" ]];         then GREEN=true;       elif [[ ${APP_CURRENT_ACTIVE} == "blue" ]];         then BLUE=true;       elif [[ -z ${APP_CURRENT_ACTIVE} ]];         then EMPTY=$((EMPTY-1));       else         tput setaf 9 && echo "Что-то пошло не так! Статус версий некорректен" && exit 1;       fi;     done      if [[ ${GREEN} != ${BLUE} ]];       then       if [[ ${GREEN} ]]         COLOR="green"         then tput setaf 14 && echo "Статус версий для приложений одинаков — green, можно продолжать деплой";       elif [[ ${BLUE} ]]         COLOR="blue"         then tput setaf 14 && echo "Статус версий для приложений одинаков — blue, можно продолжать деплой";       fi;     elif [[ ${EMPTY} = 0 ]]       then tput setaf 14 && echo "Ingress для данных приложений в кластере не обнаружено, можно продолжать деплой";     else       tput setaf 9 && echo "Статус версий для приложений отличается, деплой будет остановлен!!!" && exit 1;     fi;  Check_upstreams:   stage: check_upstreams   script:     - *check_upstreams   environment:     name: production   when: always   allow_failure: false 

Деплой приложения будет происходить с применением бандла. В эту команду мы передаём все необходимые аргументы и не забываем указать разное имя релиза (флаг --release) для разных приложений, иначе деплой одного будет перезаписывать деплой предыдущего. Далее с помощью parallel:matrix на стадии деплоя будет автоматически создано нужное количество джоб деплоя, исходя из количества приложений:

Ниже пример реализации деплоя приложений в CI:

.deploy_apps: &deploy_apps   stage: deploy_apps   before_script:     - *base_werf     - REPOSITORY_BUNBLE=${REPOSITORY_NAME}_REPO_BUNDLE     - REPOSITORY_TAG=${REPOSITORY_NAME}_TAG     - REPOSITORY_INGRESS=${REPOSITORY_NAME}_INGRESS     - APP_CURRENT_ACTIVE=$(werf kubectl -n ${WERF_NAMESPACE} get ingress ${!REPOSITORY_INGRESS} --output=custom-columns='SVCs:..service.name' --no-headers --ignore-not-found | awk -F '-' {'print $NF'})     - |       if [[ ${APP_CURRENT_ACTIVE} = ${DEPLOY_VERSION} ]];         then tput setaf 9 && echo "Обнаружена попытка деплоя на активную версию, деплой будет остановлен!!!" && exit 1;       fi;   script:     - werf cr login -u nobody -p ${BUNDLE_PULLER_PASSWORD} ${!REPOSITORY_BUNBLE}     - werf bundle apply       --release $(echo ${!REPOSITORY_BUNBLE} | cut -d / -f4)-${DEPLOY_VERSION}-${CI_ENVIRONMENT_SLUG}       --repo ${!REPOSITORY_BUNBLE}       --tag ${!REPOSITORY_TAG}       --set "werf.deploy_version=${DEPLOY_VERSION}"   when: manual  Deploy to Green:   extends: .deploy_apps   stage: deploy_apps   environment:     name: production   parallel:     matrix:       - REPOSITORY_NAME: *apps_for_matrix   variables:     DEPLOY_VERSION: "green"

Так мы получили пайплайн, который позволяет из одного репозитория деплоить разные приложения из ранее опубликованных бандлов.

Заключение

Blue-green помогает надёжно и быстро выкатить обновления своих приложений. Эта стратегия упрощает процесс и даёт возможность тестировать новую версию перед её полноценным запуском. А бандлы особенно полезны для деплоя нескольких приложений одновременно. Это делает управление и обновление более наглядными и централизованными, что особенно важно для больших проектов.

В статье мы рассмотрели деплой приложений в стратегии blue-green с помощью GitLab-CI и модифицировали наш CI для деплоя нескольких приложений из одного репозитория. Это руководство помогает написать CI и развернуть своё приложение из GitLab. Надеюсь, оно будет полезным. 

P. S.

Читайте также в нашем блоге:

• Стратегии деплоя в Kubernetes: rolling, recreate, blue/green, canary, dark (A/B-тестирование)

• Автоматизируем сборку и деплой приложения в GitLab CI/CD: подробное руководство с примерами

• Первые шаги с werf: собираем и деплоим простое приложение в Kubernetes