Background: We started using Jenkins standalone, and it worked perfectly fine for six months. But with more and more teams using the tool and an increasing load, we naturally hit the performance overhead.
Since we didn’t have Kubernetes then, the only options we had were to either opt for a master-agent configuration through servers or scale the server vertically by adding more CPU and memory. We chose the latter as it was quicker and more comfortable for us. However, we realized this wasn’t going to last long, and started looking for alternative options. Eventually, the CTO of the company decided to go ahead with a cloud strategy. That was good for us.
Goals: Our ultimate goal was to seamlessly enable DevOps within the organization. Therefore, we decided to move our Jenkins to the cloud and shift it to a Kubernetes cluster we had built and had migrated all tools to.
"Jenkins allowed us to run builds in a scalable fashion and a more or less independent way."
Solution & Results: We had two options: either containerise the master and use it standalone or build a scalable Jenkins by using Kubernetes. We came up with the following architecture: One replica of Jenkins master runs as a control plane. All users log in to the master to build and manage their jobs. Using the Jenkins Kubernetes plugin, we then employ Kubernetes to spin up additional Jenkins agent containers when someone triggers a build. It runs the job in the container and, when successful, removes the container.
Jenkins allowed us to run builds in a scalable fashion and more or less independent way. This allowed multiple builds to run in parallel with a near infinite scaling capacity. It also helped us optimise cost due to the elasticity of the Kubernetes Infrastructure and Google Cloud platform in general. The results?
builds are 10X faster
cost reduction as Jenkins uses the same Kubernetes cluster
faster time to delivery because of no performance bottlenecks