C.I.
Hi all! In the previous article, we looked in detail at the implementation of continuous integration of CI based on Gitea/Forgejo in the Gitorion platform. In this article, we bring to your attention a closer look at the implementation of continuous CD delivery in the Gitorion platform based on Jenkins.
Jenkins Agents
Jenkins executes all pipeline commands in agents, which it launches as modules in the Kubernetes cluster using a Web hook from Gitea/Forgejo. Below is an example of Jenkins agents executing pipelines for branches dev1, dev2, dev3 and main. After the pipeline is executed, the Jenkins agent module exits.
The Jenkins agent module specification was set in the 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
“””
}
}
The agent pulls the Git repository of the microservice from Gitea/Forgejo using a Web hook and executes the pipeline stages in the Jenkinsfile.
Docker-in-Docker
To build Docker images, we installed the Docker-in-Docker (dind) service in the Kubernetes cluster and connected it to Jenkins agents. The docker build command in the Build stage of building a Docker image of a microservice will be executed in the Docker-in-Docker module.
Docker Registry
To store the assembled Docker images, we installed a private Docker Registry repository in the Kubernetes cluster. Jenkins Agent executes the docker push command and pushes the Docker image built at the Build stage to the Docker Registry repository. At the stage of delivering a microservice to a Kubernetes cluster, Deployment or StatefulSet resources take Docker images from the private Docker Registry repository and use them to launch Docker microservice containers in the Kubernetes cluster.
Multibranch Pipeline
In the previous article about continuous integration of CI based on Gitea/Forgejo, we mentioned that each programmer makes changes to the code only within his own branch. Jenkins has a pipeline like the Multibranch Pipeline, which automatically discovers new branches in the Git repository and launches its own pipeline for each of them. The programmer creates a new branch with the commands:
git checkout -b dev3
git push --set-upstream origin dev3Gitea/Forgejo sends a Webhook to Jenkins. Jenkins uses a Web hook to automatically find a new branch and launch a pipeline for it.
Pipeline stages
Regardless of the name of the branch, the Build stage is launched first, in which the Docker image of the microservice is built and placed in the private Docker Registry repository. Next, the pipeline retrieves the branch name from the Webhook. For a branch, main starts the Staging stage and delivers the microservice to the Staging loop.
For all other branches, the pipeline launches the Review stage and deploys the microservice to the Development loop.
The Staging and Review stages use the same helm chart templates in the microservice's Git repository so that Review delivers the same things as Staging and Production. The helm chart contains a configs directory with microservice configs separately for each Development, Staging and Production circuit.
Linking Gitea commits to Helm revisions
At the time of deploying the microservice to Staging, the Jenkins Agent extracts the SHA1 of the commit from the Gitea/Forgejo Web hook.
Each new deployment of a microservice is another revision of helm. We added the SHA1 of the commit to the helm revision names, thereby linking the SHA1 of the commits to the helm revision numbers.
We also used SHA1 of commits as tags when naming Docker images:
image: docker-registry.jenkins.svc.cluster.local/owneruser/backend/main:bb7cfed40a
Promote promotion from Staging to Production
After demonstrating the programmers’ work to the customer in the Staging environment, the team lead manually launches the Promote microservice promotion pipeline from Staging to Production. The pipeline executes the command:
helm history staging-owneruser-backend -n stagingTakes the SHA1 of the commit corresponding to the revision that has “deployed” in the STATUS column (see screenshot above). Retrieves from the private Docker Registry image repository a Docker image whose tag corresponds to a commit with the “deployed” status:
image: docker-registry.jenkins.svc.cluster.local/owneruser/backend/main:74e5cbd967
and delivers the circuit to Production. The Build stage is ignored because building the Docker image is not needed in the Promote stage.
Rollback to previous versions
In case a microservice with an error is delivered to production, we have developed a Rollback pipeline to rollback to previous versions. To be able to quickly restore production operations while programmers fix the error.
To rollback Rollback, the team lead needs to decide which commit in Gitea/Forgejo he wants to rollback to, set the SHA1 of the commit in the pipeline parameters and manually start the pipeline.
Jenkins Agent will rollback with the helm rollback command to the revision corresponding to the selected commit.
Conclusion
In the next article, we will take a closer look at the intricacies of implementing Single Sign-On (SSO) into all services of the Gitorion platform using Keycloak. Thank you.
