Seamless CI/CD with Jenkins + Helm and Kubernetes
There are many ways and platforms you can use to solve CI/CD for your company nowadays. As we were already using Jenkins jobs for deployments and everyone at the team knew it well it was the obvious choice, but we shifted towards pipelines.
To implement this you need:
- A Kubernetes cluster where you are going to deploy your applications
- Helm deployment files for your application
- Jenkins CI pipelines
The big picture
Jenkins will fetch branches and tags from the selected repository and run all steps defined for the pipeline inside your project's Jenskinsfile .
Kubernetes is an orchestration tool for containers so we need to be deploying applications as Docker containers so they can run and be managed inside this orchestration tool.
Helm is a “package manager” for Kubernetes. Basically it reads, parses and injects values into a series of “Helm templates” that in the end results in a series of Kubernetes objects. Helm then bundles all of this objects into a Helm release and installs it in the configured kubernetes cluster. You can supply to helm some input values to configure each installation which is flexible enough to install for example the same application configured differently for multiple environments (e.g dev, staging and production).
The jenkins pipeline
Here is an example of our declarative Jenkins pipeline file:
You should include a file with name “Jenkinsfile” in your project repository and jenkins will use it to define the pipeline. For brevity i only included the deployment step. In this step you will call the Helm installation or upgrade. This will apply a helm upgrade to your previously installed Helm release or if no release exists Helm will execute an helm install with the given release name (e.g. prod-my-app).
It’s a good idea to include the namespace as prefix or suffix for the helm release name because release names are only a name for helm and not installed as part of a Kubernetes namespace.
If you attempt to install a release-dummy on namespace dev and a release-dummy on namespace staging it will fail because release-dummy will already exist, Helm doesn’t care about namespace. To solve this we include a prefix of the namespace on the release name.
The deployment file
Make sure you have configured your app to run as a Kubernetes Deployemnt or StatefulSet or avoid having down time between deploys. Check the deployment.yaml helm template below:
And that’s it, there are a lot of concepts to learn to put this all together but when you have it all covered up you will never have to put that much effort into deploying new applications and managing releases.
When you are done you push the commits into master or create a new tag and the code will appear in your servers without no more clicking.
