Jenkins is a powerful automation and CI/CD tool that can become an essential part of your Kubernetes pipeline.
There are several ways to manage your cloud infrastructure in a DevOps environment. DevOps on its own is developed as an approach that encourages fast-flowing app development and IT teams to move from development to testing and release in a seamless way.
Jenkins optimizes that flow of work through automation and the seamless integration of Continuous Integration (CI) and Continuous Delivery (CD) into the development pipeline. It’s possible to deploy these techniques using a Jenkins pod within Kubernetes which can be scaled according to the specific needs of the team.
The CI/CD Pipeline
Jenkins is well-established and synonymous with the terms CI/CD. It is the perfect tool for automating the development and deployment of apps and microservices and is currently the most popular automation tool on the market. Jenkins has more than 1,000 plugins that allow for easy integration with other systems, including Kubernetes. Not only do the plugins provide multi-system integration but the significantly enhance Jenkins’ power, making it capable of helping you build and deploy almost any project type. We cover the top 20 Jenkins plugins that you need in your life here in another post.
Setting up your own CI/CD pipeline is easy thanks to the native compatibility of Jenkins and Kubernetes. Deploying Jenkins on Kubernetes provides important benefits over a standard VM-based deployment. For example, gaining the ability to have project-specific Jenkins slaves (agents) on demand, instead of having a pool of VMs idle waiting for a job. It will use master-agent architecture to fully automate the creation and deployment of microservices—and the environment they need—for testing and deployment.
Jenkins can be deployed using Helm, kubectl* *or GUIs for deploying new pods to the cluster. Once installed, the next step is to configure the Jenkins plugin for K8s. We need to configure settings such as where an agent finds the Jenkins master, what Docker images we will use for the agents, etc. Of course, it’s also crucial to configure Jenkins to work with your CI/CD workflow, including setting the testing and deployment parameters and how the Jenkins-controlled cluster must be set up. Staging a continuous delivery environment becomes fully automated once Jenkins is up and running.
Setting Up a Pipeline in Jenkins
Getting Jenkins started is only the beginning. The next step is configuring your CI/CD pipeline within Jenkins itself. You can begin by running minikube service Jenkins and accessing Jenkins using its web UI.
You then have the option to install the necessary plugins. Depending on the pipeline you want to create, you may want to download and install suitable plugins to enable automation and better management of the pipeline. Using the Kubernetes plugin is a must.
Another plugin worth talking about is the Kubernetes Continuous Deploy plugin, which is specifically designed to handle the continuous delivery aspect of the pipeline. This plugin will handle the creation of new pods for testing as well as the transition between testing and deployment.
After all the plugins are configured, restart Jenkins. A nice feature that Jenkins offers is the ability to automate those manual changes so the next time you have to configure the CI/CD system (e.g., in the event of infrastructure migration) you don’t have to pass through the manual changes again. You simply receive an instance with the same configuration and plugins you had previously. The script install_plugins.sh embedded into the Jenkins Docker image and the Jenkins config file config.xml makes this happen.
Now you can go ahead and then create your first pipeline, assign credentials to it, and begin developing inside the pipeline itself. Remember that Jenkins doesn’t always pull code from local storage; you need to issue a push request manually the first time you configure it.
Create the first pipeline and you can optimize minikube to run your new application immediately. Manual push request is actually handy in most CI/CD workflows because now you have more control over the codes you want to push all the way through the pipeline.
Pushing Changes in Different Situations
When you open your application code and make changes to it, Jenkins will not immediately update the deployment pods. Instead, you have to commit the changes and wait for Jenkins to pull those changes (depending on how that checkout of code was configured) before additional actions can be done.
On the Jenkins UI, there is a Build Now command for running new builds. After the build is completed, you will see the changes appearing the next time you use minikube to run your app. The way Jenkins pipelines are configured makes this tool incredibly useful.
You can, for example, use Jenkins to power your multi-team development. Jenkins pipeline runs as a code, which means any user with the right credentials can commit changes and execute the processes built into the pipeline.
It is also very versatile. The pipeline and the processes in it will automatically resume should your server suddenly crash. Jenkins will never lose control of the cluster it manages, so you can use Jenkins to completely eliminate the need for manual configurations of the CI/CD environment.
A personal favorite is the way Jenkins can be used to manage multiple pipelines, and that admins can have a clear view of all pipelines in the system. Coupled with the ability to pause and resume pipelines, using Jenkins to manage developments of microservices and larger projects is very rewarding.
Another great plugin is called Pipeline and Pipeline Multibranch that helps us to visualize the CI/CD flow. It allows a JenkinsFile to be defined into the repo with all the steps we want Jenkins to execute. There is no need to do manual configurations from the GUI (which might be reserved for Administrators only) and enables the flexibility of letting the developers control the flow for a given project/branch. Since it is in Github, it is also versioned alongside any other app library.
Jenkins and Kubernetes
That brings us back to our main point: leveraging Jenkins on Kubernetes. From the way Jenkins works as a tool, it is easy to see how this automation measure complements Kubernetes perfectly. Once the plugin is configured, every time a new build/job is triggered, Jenkins will create a pod inside K8s (through an on-demand agent designed to perform that work). Once done, the pod will be destroyed, avoiding the need for having a fixed pool of agents waiting for job execution. As you can see, Kubernetes provides the robust CI/CD infrastructure every development team needs, while Jenkins significantly simplifies the management of that environment.
The combination has the ability to improve CI/CD workflows in different situations, including in larger development projects. If you take into account the bounty of Jenkins plugins available—including Kubernetes Pipeline, Credentials, and more—already available today, you know you have a powerful CI/CD tool to work with. It even comes with the ability to separate non-setup and material work in the pipeline; what’s not to love?
#kubernetes #jenkins
