Jenkins is an easy to use opensource CI/CD tool. This blog covers the fundamental Jenkins components architecture. If you are a beginner to Jenkins, it will help you gain some idea on how Jenkins components work together and the key configurations involved.
The following diagram shows the overall architecture of Jenkins.
Following are the key components in Jenkins
- Jenkins Master Node
- Jenkins Slave Node
- Jenkins Web Interface
Let look at each component in detail.
Jenkins Master (Server)
Jenkins’s server or master node holds all key configurations.
The following are the key Jenkins master components.
- Jenkins Jobs: A job is a collection of steps that you can use to build your source code, test your code, run a shell script, or to run an Ansible role in a remote host. Ther are multiple job types available to support your workflow for continuous integration & continuous delivery.
- Jenkins Plugins: Plugins are community-developed modules that you can install in your Jenkins server. It lets you add more functionalities that are not natively available in Jenkins. You can also develop your custom plugins. Check out all plugins from the Jenkins Plugin Index
- Jenkins User: Jenkins has its own user database. It can be used for Jenkins’s authentication.
- Jenkins Global Security: Jenkins has the following two primary authentication methods.
- Jenkins’s own user database:- Set of users maintained by Jenkins’s own database.
- LDAP Integration:- Jenkins authentication using corporate LDAP configuration.
- Jenkins Credentials: If you want to save any secret information that has to be used in the jobs, you can store it as a credential. All credentials are encrypted by Jenkins.
- Jenkins Nodes/Clouds: You can configure multiple slave nodes (Linux/Windows) or clouds (docker, kubernetes) for executing Jenkins jobs.
- Jenkins Global Settings (Configure System): Under Jenkins global configuration, you have all the configurations of installed plugins and native Jenkins global configurations. Also, you can configure global environment variables under this section.
- Jenkins Logs: Provides logging information on all Jenkins server actions including job logs, plugin logs, webhook logs, etc.
All the configurations for the above-mentioned components will be present as a config file in the Jenkins master node.
Note: Jenkins doesn’t have a database. All Jenkins configurations are stored as flat config files. Mostly xml files.
Jenkins slaves are the worker nodes for the jobs configured in Jenkins server.
Note: You can run jobs in Jenkins server without a Jenkins slave. However, the recommended approach is to have segregated Jenkins Slaves for different job requirements so that you don’t end up messing up the Jenkins server for any system wide configuration changes required for a job.
You can have any number of Jenkins slaves attached to a master with a combination of Windows & Linux servers.
Also, you can restrict jobs to run on specific slaves, depending on the use case. For example, if you have a slave with java 8 configurations, you can assign this slave for jobs that require Java 8 environment.
There is no single standard for using the slaves. You can set up a workflow and strategy based on your project needs.
Jenkins Web Interface
Jenkins 2.0 introduced a very intuitive web interface called “Jenkins Blue Ocean”. It has a good visual representation of all the pipelines.
Jenkins Master-Slave Connectivity
You can connect a Jenkins master and slave in two ways
- Using the SSH method: Uses the ssh protocol to connect to the slave. The connection gets initiated from the Jenkins master. Ther should be connectivity over port 22 between master and slave.
- Using the JNLP method: Uses java JNLP protocol. In this method, a java agent gets initiated from the slave with Jenkins master details. For this, the master nodes firewall should allow connectivity on specified JNLP port. Typically the port assigned will be 50000. This value is configurable.
There are two types of Jenkins slaves
- Slave Nodes: These are servers (Windows/Linux) that will be configured as static slaves. These slaves will be up and running all the time and stay connected to the Jenkins server. Organizations use custom scripts to shut down and restart the slaves when is not used. Typically during nights & weekends.
- Slave Clouds: Jenkins Cloud slave is a concept of having dynamic slaves. Means, whenever you trigger a job, a slave will be deployed as a VM/container on demand and gets deleted once the job is completed. This method saves money in terms of infra cost when you have a huge Jenkins ecosystem and continuous builds.
All the Jenkins data will be store in the following folder location. Data includes all jobs config files, plugins configs, secrets, node information, etc.
It is very important to back up the Jenkins data folder every day. For some reason, if your Jenkins server data gets corrupt, you can restore whole Jenkins with the data backup.