Easily Automate Your CI/CD Pipeline With Jenkins, Helm, and Kubernetes

Developers don’t want to think about infrastructure and why it takes so long to deploy their code to a real testing environment. They just want it up and running!

This 6-step workflow will easily automate your CI/CD pipeline for quick and easy deployments using Jenkins, Helm, and Kubernetes.

Nowadays it’s critical to get your releases out fast, which requires having an automated CI/CD pipeline that takes your code from text to binaries to a deployed environment. Implementing an automated pipeline in the past has been challenging, especially when dealing with legacy applications. This is where Kubernetes comes in. Kubernetes has revolutionized the way we deploy and manage our containerized applications. Using Helm together with Kubernetes, you gain simplified application deployment.

This article will show you how to prepare and configure your environment to achieve a complete automated CI/CD pipeline for your containerized applications using Jenkins, Helm, and Kubernetes. You will receive tips on how to optimize your pipeline and a working template for customizing your own pipeline.

In order to get familiar with the Kubernetes environment, I have mapped the traditional Jenkins pipeline with the main steps of my solution.

Note: This workflow is also applicable when implementing other tools or for partial implementations.

Setting Up the Environment

Configure the Software Components

Before you create your automated pipeline, you need to set up and configure your software components according to the following configuration:

A Kubernetes Cluster

• Set up the cluster on your data center or on the cloud.

A Docker Registry

A Helm Repository

Isolated Environments

• Create different namespaces or clusters for Development and Staging
• Create a dedicated and isolated cluster for Production

Jenkins Master

• Set up the master with a standard Jenkins configuration.
• If you are not using slaves, the Jenkins master needs to be configured with Docker, Kubectl, and Helm.

Jenkins Slave(s)

• It is recommended to run the Jenkins slave(s) in Kubernetes to be closer to the API server which promotes easier configuration.
• Use the Jenkins Kubernetes plugin to spin up the slaves in your Kubernetes clusters.

Prepare Your Applications

Follow these guidelines when preparing your applications:

• Package your applications in a Docker Image according to the Docker Best Practices.
• To run the same Docker container in any of these environments: Development, Staging or Production, separate the processes and the configurations as follows:
• For Development: Create a default configuration.
• For Staging and Production: Create a non-default configuration using one or more:
• Configuration files that can be mounted into the container during runtime.
• Environment variables that are passed to the Docker container.

The 6-Step Automated CI/CD Pipeline in Kubernetes in Action

General Assumptions and Guidelines

• These steps are aligned with the best practices when running Jenkins agent(s).
• Assign a dedicated agent for building the App, and an additional agent for the deployment tasks. This is up to your good judgment.
• Run the pipeline for every branch. To do so, use the Jenkins Multibranch pipeline job.

1. Get code from Git

Developer pushes code to Git, which triggers a Jenkins build webhook.

Jenkins pulls the latest code changes.

2. Run build and unit tests

Jenkins runs the build.

Application’s Docker image is created during the build.- Tests run against a running Docker container.

3. Publish Docker image and Helm Chart

Application’s Docker image is pushed to the Docker registry.

Helm chart is packed and uploaded to the Helm repository.

4. Deploy to Development

Application is deployed to the Kubernetes development cluster or namespace using the published Helm chart.

Tests run against the deployed application in Kubernetes development environment.

5. Deploy to Staging

1. Application is deployed to Kubernetes staging cluster or namespace using the published Helm chart.
2. Run tests against the deployed application in the Kubernetes staging environment.

6. [Optional] Deploy to Production

The application is deployed to the production cluster if the application meets the defined criteria. Please note that you can set up as a manual approval step.

Sanity tests run against the deployed application.

If required, you can perform a rollback.

Create Your Own Automated CI/CD Pipeline

Feel free to build a similar implementation using the following sample framework that I have put together just for this purpose:

Bon voyage for your Kubernetes CI/CD voyage!

Originally published at dzone.com.