Привет всем! В предыдущей статье мы подробно рассмотрели реализацию непрерывной интеграции CI на базе Gitea/Forgejo в платформе Gitorion. В данной статье предлагаем вашему вниманию подробнее познакомиться с внедрением непрерывной доставки CD в платформу Gitorion на базе Jenkins.
Jenkins Agents
Jenkins выполняет все команды пайплайнов в агентах, которые запускает как модули в кластере Kubernetes по Web-хуку из Gitea/Forgejo. Ниже приведен пример агентов Jenkins, выполняющих пайплайны для веток dev1, dev2, dev3 и main. После выполнения пайплайна модуль агента Jenkins завершается.
Спецификацию модуля агента 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.
Docker-in-Docker
Для сборки Docker-образов установили в кластер Kubernetes сервис Docker-in-Docker (dind) и подключили к агентам Jenkins. Команда docker build в стадии Build сборки Docker-образа микросервиса будет выполнена в модуле Docker-in-Docker.
Docker Registry
Для хранения собранных Docker-образов установили в кластер Kubernetes приватный репозиторий Docker Registry. Jenkins Agent выполняет команду docker push и отправляет Docker-образ, собранный на стадии Build, в репозиторий Docker Registry. На стадии доставки микросервиса в кластер Kubernetes ресурсы Deployment или StatefulSet берут Docker-образы из приватного репозитория Docker Registry и используют для запуска Docker-контейнеров микросервисов в кластере Kubernetes.
Multibranch Pipeline
В предыдущей статье про непрерывную интеграцию CI на базе Gitea/Forgejo мы упоминали, что каждый программист вносит изменения в код только в пределах своей ветки. В Jenkins есть пайплайн типа Multibranch Pipeline, который автоматически обнаруживает новые ветки в Git-репозитории и для каждой из них запускает свой пайплайн. Программист создает новую ветку командами:
git checkout -b dev3
git push --set-upstream origin dev3Gitea/Forgejo посылает Web-хук в Jenkins. Jenkins по Web-хуку автоматически находит новую ветку и запускает для нее пайплайн.
Cтадии пайплайна
Независимо от имени ветки, первой запускается стадия Build, в которой собирается Docker-образ микросервиса и помещается в приватный репозиторий Docker Registry. Далее, пайплайн извлекает из Web-хука имя ветки. Для ветки main запускает стадию Staging и доставляет микросервис в контур Staging.
Для всех остальных веток пайплайн запускает стадию Review и деплоит микросервис в контур Development.
Cтадии Staging и Review используют одни и те же шаблоны templates helm-чарта в Git-репозитории микросервиса, чтобы на Review доставлялось то же самое, что и на Staging и в Production. В helm-чарте содержится директория configs с конфигами микросервиса отдельно для каждого контура Development, Staging и Production.
Связь коммитов Gitea с ревизиями Helm
Jenkins Agent в момент деплоя микросервиса в Staging контур извлекает SHA1 коммита из Web-хука Gitea/Forgejo.
Каждый новый деплой микросервиса - это очередная ревизия helm. Мы добавили SHA1 коммита к именам ревизий helm, тем самым связав SHA1 коммитов с номерами ревизий 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.
Откат Rollback на предыдущие версии
На случай, если в продакшен будет доставлен микросервис с ошибкой, разработали пайплайн отката Rollback на предыдущие версии. Чтобы иметь возможность оперативно восстановить работу продакшена, пока программисты будут исправлять ошибку.
Для отката Rollback тимлиду нужно определиться, до какого коммита в Gitea/Forgejo он хочет откатиться, задать SHA1 коммита в параметрах пайплайна и вручную запустить пайплайн.
Jenkins Agent выполнит откат командой helm rollback до ревизии, соответствующей выбранному коммиту.
Заключение
В следующей статье мы рассмотрим подробнее тонкости реализации единого входа Single Sign-On (SSO) во все сервисы платформы Gitorion при помощи Keycloak. Спасибо.
