This blog covers the fundamental Jenkins architecture and its related components. If you are a beginner in Jenkins, it will help you understand how Jenkins components work together and the key configurations involved.
What is Jenkins?
Jenkins is an easy-to-use open-source CI/CD tool. It has been around for some time, and several organizations use it for their CI/CD needs.
Important Note: It is essential to have an understanding of Continuous integration, continuous delivery, and continuous deployment to understand Jenkins better.
Jenkins has huge community support and an ocean of plugins that can integrate with many open-source and enterprise tools to make your life so easy.
Jenkins is commonly used for the following.
- Continuous Integration for application and infrastructure code.
- Continuously deliver pipeline to deploy the application to different environments using Jenkins pipeline as code.
- Run batch operations using Jenkins jobs.
- Run ad-hoc operations like backups, cleanups, remote script execution, event triggers, etc.
The following diagram shows the overall architecture of Jenkins.
Following are the key components in Jenkins
- Jenkins Master Node
- Jenkins Agent Node
- Jenkins Web Interface
Lets 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 run an Ansible role in a remote host. There 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 agent 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 agents are the worker nodes for the jobs configured in Jenkins server. When you trigger a Jenkins job from the master, the actual execution happens on the agent nodes.
Note: You can run jobs in the Jenkins server without a Jenkins agent. However, the recommended approach is to have a Jenkins master-agent setup 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 agents attached to a master with a combination of Windows, Linux servers, and even Docker containers as build agents.
Also, you can restrict jobs to run on specific agents, depending on the use case. For example, if you have an agent with java 8 configurations, you can assign this agent for jobs that require Java 8 environment.
There is no single standard for using the agents. 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-agent Connectivity
You can connect a Jenkins master and agent in two ways
- Using the SSH method: Uses the ssh protocol to connect to the agent. The connection gets initiated from the Jenkins master. Ther should be connectivity over port 22 between master and agent.
- Using the JNLP method: Uses java JNLP protocol. In this method, a java agent gets initiated from the agent 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 agents
- Agent Nodes: These are servers (Windows/Linux) that will be configured as static agents. These agents 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 agents when is not used. Typically during nights & weekends.
- Agent Clouds: Jenkins Cloud agent is a concept of having dynamic agents. Means, whenever you trigger a job, a agent 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 makes Jenkins migration very easy as compared to other tools.
It is essential to back up the Jenkins data folder every day. For some reason, if your Jenkins server data gets corrupt, you can restore the whole Jenkins with the data backup.
In this blog, I have explained Jenkins architecture and its key components.
I personally like Jenkins for its huge community support and extensive office and community documentation.