CI/CD Kubernetes платформа Gitorion. Непрерывная доставка CD на базе Jenkins25.03.2024 07:15

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

Jenkins Agents

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

Модули агентов 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

Docker-in-Docker

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

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-репозитории и запустил для нее пайплайн

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

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

Стадия Staging

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

Стадия 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

Каждый новый деплой микросервиса — это очередная ревизия helm. Мы добавили SHA1 коммита к именам ревизий helm, тем самым связав SHA1 коммитов с номерами ревизий 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

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

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

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

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

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

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

Заключение

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