Привет всем! В предыдущей статье мы подробно рассмотрели реализацию непрерывной интеграции CI на базе Gitea/Forgejo в платформе Gitorion. В данной статье предлагаем вашему вниманию подробнее познакомиться с внедрением непрерывной доставки CD в платформу Gitorion на базе Jenkins.
Jenkins Agents
Jenkins выполняет все команды пайплайнов в агентах, которые запускает как модули в кластере Kubernetes по Web-хуку из Gitea/Forgejo. Ниже приведен пример агентов Jenkins, выполняющих пайплайны для веток dev1, dev2, dev3 и main. После выполнения пайплайна модуль агента Jenkins завершается.
![Модули агентов Jenkins в кластере Kubernetes Модули агентов Jenkins в кластере Kubernetes](https://habrastorage.org/getpro/habr/upload_files/024/6bc/fd0/0246bcfd0ae9cf0851ab1febe27f4f9a.png)
Спецификацию модуля агента 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](https://habrastorage.org/getpro/habr/upload_files/8c8/04e/10d/8c804e10dbebad4e598d0ef671306826.png)
Docker-in-Docker
Для сборки Docker-образов установили в кластер Kubernetes сервис Docker-in-Docker (dind) и подключили к агентам Jenkins. Команда docker build в стадии Build сборки Docker-образа микросервиса будет выполнена в модуле Docker-in-Docker.
![Jenkins Agent собирает Docker-образ микросервиса Jenkins Agent собирает Docker-образ микросервиса](https://habrastorage.org/getpro/habr/upload_files/753/50d/535/75350d5355b969048e94a4450ab83179.png)
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](https://habrastorage.org/getpro/habr/upload_files/199/d08/c3f/199d08c3faaec5e37f5b5ba48435f840.png)
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-репозитории и запустил для нее пайплайн](https://habrastorage.org/getpro/habr/upload_files/5ec/027/1b6/5ec0271b615090c0fdfec9f1af445389.png)
Cтадии пайплайна
Независимо от имени ветки, первой запускается стадия Build, в которой собирается Docker-образ микросервиса и помещается в приватный репозиторий Docker Registry. Далее, пайплайн извлекает из Web-хука имя ветки. Для ветки main запускает стадию Staging и доставляет микросервис в контур Staging.
![Стадия Staging Стадия Staging](https://habrastorage.org/getpro/habr/upload_files/c6a/d58/1ad/c6ad581ad299fd17ec3b4b74cd3d5cfb.png)
Для всех остальных веток пайплайн запускает стадию Review и деплоит микросервис в контур Development.
![Стадия Review Стадия Review](https://habrastorage.org/getpro/habr/upload_files/3bb/52f/160/3bb52f160e0978b9f88b5a6da9873cda.png)
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](https://habrastorage.org/getpro/habr/upload_files/bc6/681/7fa/bc66817faaec8d517db8e27a91b62c71.png)
Каждый новый деплой микросервиса - это очередная ревизия helm. Мы добавили SHA1 коммита к именам ревизий helm, тем самым связав SHA1 коммитов с номерами ревизий helm.
![Связь SHA1 коммитов Gitea/Forgejo c номерами ревизий helm Связь SHA1 коммитов Gitea/Forgejo c номерами ревизий helm](https://habrastorage.org/getpro/habr/upload_files/a6f/e88/0cf/a6fe880cf211e3bfc8fcf184ef836f9a.png)
Так же 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](https://habrastorage.org/getpro/habr/upload_files/9e0/ba7/8b6/9e0ba78b6ae08fc539d9e4ac2de55e35.png)
Откат Rollback на предыдущие версии
На случай, если в продакшен будет доставлен микросервис с ошибкой, разработали пайплайн отката Rollback на предыдущие версии. Чтобы иметь возможность оперативно восстановить работу продакшена, пока программисты будут исправлять ошибку.
Для отката Rollback тимлиду нужно определиться, до какого коммита в Gitea/Forgejo он хочет откатиться, задать SHA1 коммита в параметрах пайплайна и вручную запустить пайплайн.
![Список коммитов, до которых можно сделать откат Rollback Список коммитов, до которых можно сделать откат Rollback](https://habrastorage.org/getpro/habr/upload_files/db1/68c/456/db168c4561e05bffb5e3da166e0aeada.png)
Jenkins Agent выполнит откат командой helm rollback до ревизии, соответствующей выбранному коммиту.
![Откат Rollback до заданного коммита Откат Rollback до заданного коммита](https://habrastorage.org/getpro/habr/upload_files/abf/a9e/2a5/abfa9e2a5a7896ba605e6f50b944522e.png)
Заключение
В следующей статье мы рассмотрим подробнее тонкости реализации единого входа Single Sign-On (SSO) во все сервисы платформы Gitorion при помощи Keycloak. Спасибо.