Привет всем! В предыдущей статье мы подробно рассмотрели реализацию непрерывной интеграции CI на базе Gitea/Forgejo в платформе Gitorion. В данной статье предлагаем вашему вниманию подробнее познакомиться с внедрением непрерывной доставки CD в платформу Gitorion на базе Jenkins.

Jenkins Agents

Jenkins выполняет все команды пайплайнов в агентах, которые запускает как модули в кластере Kubernetes по Web-хуку из Gitea/Forgejo. Ниже приведен пример агентов Jenkins, выполняющих пайплайны для веток dev1, dev2, dev3 и main. После выполнения пайплайна модуль агента Jenkins завершается.

Модули агентов Jenkins в кластере Kubernetes
Модули агентов Jenkins в кластере Kubernetes

Спецификацию модуля агента Jenkins задали в Jenkinsfile.

Jenkinfile

pipeline {

agent {
kubernetes {
inheritFrom 'build-service-pod'
yaml """
apiVersion: v1
kind: Pod
metadata:
name: docker-in-docker
labels:
app.kubernetes.io/component: jenkins-dind
app.kubernetes.io/instance: jenkins
spec:
containers:
- name: docker-client
image: docker:23.0.1-alpine3.17
imagePullPolicy: IfNotPresent
env:
- name: DOCKER_HOST
value: tcp://dind.jenkins.svc.cluster.local:2375
"""
}
}

Агент вытягивает Git-репозиторий микросервиса из Gitea/Forgejo по Web-хуку и выполняет стадии пайплана в Jenkinsfile.

Jenkins Agent вытягивает Git-репозиторий из Gitea/Forgejo
Jenkins Agent вытягивает Git-репозиторий из Gitea/Forgejo

Docker-in-Docker

Для сборки Docker-образов установили в кластер Kubernetes сервис Docker-in-Docker (dind) и подключили к агентам Jenkins. Команда docker build в стадии Build сборки Docker-образа микросервиса будет выполнена в модуле Docker-in-Docker.

Jenkins Agent собирает Docker-образ микросервиса
Jenkins Agent собирает Docker-образ микросервиса

Docker Registry

Для хранения собранных Docker-образов установили в кластер Kubernetes приватный репозиторий Docker Registry. Jenkins Agent выполняет команду docker push и отправляет Docker-образ, собранный на стадии Build, в репозиторий Docker Registry. На стадии доставки микросервиса в кластер Kubernetes ресурсы Deployment или StatefulSet берут Docker-образы из приватного репозитория Docker Registry и используют для запуска Docker-контейнеров микросервисов в кластере Kubernetes.

Jenkins Agent отправляет Docker-образ в приватный репозиторий Docker Registry
Jenkins Agent отправляет Docker-образ в приватный репозиторий Docker Registry

Multibranch Pipeline

В предыдущей статье про непрерывную интеграцию CI на базе Gitea/Forgejo мы упоминали, что каждый программист вносит изменения в код только в пределах своей ветки. В Jenkins есть пайплайн типа Multibranch Pipeline, который автоматически обнаруживает новые ветки в Git-репозитории и для каждой из них запускает свой пайплайн. Программист создает новую ветку командами:

git checkout -b dev3
git push --set-upstream origin dev3

Gitea/Forgejo посылает Web-хук в Jenkins. Jenkins по Web-хуку автоматически находит новую ветку и запускает для нее пайплайн.

Multibranch Pipeline нашел новую ветку dev3 в Git-репозитории и запустил для нее пайплайн
Multibranch Pipeline нашел новую ветку dev3 в Git-репозитории и запустил для нее пайплайн

Cтадии пайплайна

Независимо от имени ветки, первой запускается стадия Build, в которой собирается Docker-образ микросервиса и помещается в приватный репозиторий Docker Registry. Далее, пайплайн извлекает из Web-хука имя ветки. Для ветки main запускает стадию Staging и доставляет микросервис в контур Staging.

Стадия Staging
Стадия Staging

Для всех остальных веток пайплайн запускает стадию Review и деплоит микросервис в контур Development.

Стадия Review
Стадия Review

Cтадии Staging и Review используют одни и те же шаблоны templates helm-чарта в Git-репозитории микросервиса, чтобы на Review доставлялось то же самое, что и на Staging и в Production. В helm-чарте содержится директория configs с конфигами микросервиса отдельно для каждого контура Development, Staging и Production.

Связь коммитов Gitea с ревизиями Helm

Jenkins Agent в момент деплоя микросервиса в Staging контур извлекает SHA1 коммита из Web-хука Gitea/Forgejo.

Коммиты в Gitea/Forgejo
Коммиты в Gitea/Forgejo

Каждый новый деплой микросервиса - это очередная ревизия helm. Мы добавили SHA1 коммита к именам ревизий helm, тем самым связав SHA1 коммитов с номерами ревизий helm.

Связь SHA1 коммитов Gitea/Forgejo c номерами ревизий helm
Связь SHA1 коммитов Gitea/Forgejo c номерами ревизий helm

Так же SHA1 коммитов мы использовали в качестве тэгов при именования Docker-образов:

image: docker-registry.jenkins.svc.cluster.local/owneruser/backend/main:bb7cfed40a

Промоушен Promote со Staging на Production

После демонстрации в окружении Staging наработок программистов заказчику, тимлид вручную запускает пайплайн промоушена Promote микросервиса со Staging на Production. Пайплайн выполняет команду:

helm history staging-owneruser-backend -n staging

Берет SHA1 коммита, соответствующего ревизии, у которой в столбце STATUS стоит "deployed" (см. скрин выше). Извлекает из приватного репозитория образов Docker Registry Docker-образ, тэг которого соответствует коммиту со статусом "deployed":

image: docker-registry.jenkins.svc.cluster.local/owneruser/backend/main:74e5cbd967

и доставляет в Production контур. Стадия Build игнорируется, поскольку сборка Docker-образа не нужна на стадии промоушена Promote.

Стадия промоушена Promote со Staging на Production
Стадия промоушена Promote со Staging на Production

Откат Rollback на предыдущие версии

На случай, если в продакшен будет доставлен микросервис с ошибкой, разработали пайплайн отката Rollback на предыдущие версии. Чтобы иметь возможность оперативно восстановить работу продакшена, пока программисты будут исправлять ошибку.

Для отката Rollback тимлиду нужно определиться, до какого коммита в Gitea/Forgejo он хочет откатиться, задать SHA1 коммита в параметрах пайплайна и вручную запустить пайплайн.

Список коммитов, до которых можно сделать откат Rollback
Список коммитов, до которых можно сделать откат Rollback

Jenkins Agent выполнит откат командой helm rollback до ревизии, соответствующей выбранному коммиту.

Откат Rollback до заданного коммита
Откат Rollback до заданного коммита

Заключение

В следующей статье мы рассмотрим подробнее тонкости реализации единого входа Single Sign-On (SSO) во все сервисы платформы Gitorion при помощи Keycloak. Спасибо.

Комментарии (0)