Chapter 2- Traditional Jenkins approach
Let’s first see what can be the traditional approach of using Jenkins in any organization, it’s architecture and the limitations of the same.
Topic is further divided into 2 subtopics for better understanding.
2.1 Jenkins architecture
Traditionally, when Jenkins is being used in an organization intranet; Jenkins master and slave agents run on a dedicated server or on a shared server with other tools which the organization uses. This setup is not at all scalable and eventually will fail.
Below picture shows the traditional Jenkins setup in any organization.
From the above pic you can see the source code repository and Jenkins setup. The Jenkins master integrate slave machines (one or many) to distribute the workload among available slaves.
Jenkins Architecture is based on 2 distributed components.
- Jenkins Server (or Master)
- Jenkins Node/Slave/Build Server
Jenkins server is a web based dashboard which is powered by a war file. Using Dashboard, You can configure the Jobs or projects but the actual build takes place in active Slave machine. By default one Nodes/Slave is configured and running in Jenkins Server itself. You can add more Nodes/Slaves as well using IP addresses with use of user name, Password and ssh/jnlp-tcp methods.
Main Jenkins server is the master. In short, the master’s job is to schedule the job among slaves, dispatching builds to the slaves for the actual execution, monitor the slaves status and presenting the build results on the dashboard. In a distributed architecture, a master instance of Jenkins also executes jobs. The job of the slaves is to execute build jobs dispatched by the master server. We have option to configure a project to always execute on a particular slave server, or a particular type of slave server, or simply let Jenkins pick from available slaves.
Jenkins is developed using Java and Java is platform independent thus Jenkins servers and nodes/slave can be configured in any servers including Windows, Linux and Mac. Slave’s operating system will not have any effect and impact of executing jobs on it.
2.2 How Jenkins is mission critical to your IT Setup? What can go wrong?
In this setup you have a master server and limited numbers of slaves, at any point if master is down or crashed your whole release management process will be hit. Also provisioning a new slave is a time consuming process, it goes on from procurement to prepare a server with lots of tools and software installed.
Apart from it, frequency of usage is also not uniformed, in office most developers will check in code by EOD and that brings peak load at a certain time and for the rest of the time it’s not utilized. So provisioning a new slave for peak load is waste of resources and also delays the overall execution process.
When a master’s load is increased due to more jobs and/or due to more frequent builds, it’s most likely to run out of resources. Sticking with this kind of standalone configuration would eventually crash Jenkins.
To come back; up and running with your whole Jenkins setup you will need to enhance the resources of master node(increasing memory or number of CPUs, etc). It also requires time to maintain and upgrade the machine and during that time the master together with all the build environment will be down, all the jobs will be in stop state and the whole Jenkins infrastructure will become unusable.
So for the release management process to run smoothly, availability of Jenkins is highly critical. It should be self-healed, autoscaled and to have characteristics of vertical or horizontal growth. In the next chapter will see how the same can be achieved in cloud hosted instances and what benefits it would bring to your execution cycle.
