top of page

Build and Run a Jenkins server on Azure

Updated: Jul 12

What is a Jenkins Server?

Jenkins is a popular open-source automation server that sets up continuous integration and delivery (CI/CD) for your software projects. You can host your Jenkins deployment in Azure or extend your existing Jenkins configuration using Azure resources. Jenkins plug-ins are also available to simplify the CI/CD of your applications to Azure.

What is Jenkins software used for?

Jenkins is used for continuous integration and continuous delivery (CI/CD), which are two complementary practices that automate the software development process.

Continuous Integration (CI)

With CI, developers frequently merge their code changes into a shared repository. Jenkins can be configured to automatically trigger builds and tests whenever new code is committed. This helps identify and fix bugs early in the development lifecycle before they become bigger problems later.

Continuous Delivery (CD)

Once the code has been built and tested successfully through CI, CD automates the process of deploying it to production environments. This allows development teams to release new features and fixes to users more frequently and reliably. By automating deployments, CD reduces the risk of errors and inconsistencies that can occur during manual deployments.

Jenkins Advantage

  • Jenkins is managed by a very open community. Every month, they hold public meetings and take input from the public to develop the project.

  • So far, around 280 tickets have closed, and the project publishes a stable release every three months.

  • As technology grows, so does Jenkins. So far, Jenkins has around 320 plugins published in its plugin database. With plugins, Jenkins becomes even more powerful and feature-rich.

  • Jenkins also supports cloud-based architecture so that you can deploy Jenkins on cloud-based platforms.

  • The reason why Jenkins became popular is that a developer for developers created it.

Jenkins Disadvantages

  • Its interface is outdated and not user-friendly compared to current UI trends.

  • Though Jenkins is loved by many developers, it’s not easy to maintain because it runs on a server and requires some skills as a server administrator to monitor its activity.

  • One reason many people don’t implement Jenkins is the difficulty of installing and configuring it.

  • Continuous integrations regularly break due to some small setting changes. Continuous integration will be paused and, therefore, requires some developer attention.

Real work Case Study

Jenkins server for azure


This architecture supports disaster recovery with Azure services but does not cover more advanced scale-out scenarios involving multiple primaries or high availability (HA) without downtime. For general insights about the various Azure components, including a step-by-step tutorial about building a CI/CD pipeline on Azure.


This document focuses on the core Azure operations needed to support Jenkins, including using Azure Storage to maintain build artifacts, the security items needed for SSO, other services that can be integrated, and pipeline scalability. The architecture is designed to work with an existing source control repository. For example, a common scenario is to start Jenkins jobs based on GitHub commits.


The architecture consists of the following components:

  • Resource group. A resource group is used to group Azure assets so they can be managed by lifetime, owner, and other criteria. Use resource groups to deploy and monitor Azure assets as a group and track billing costs by resource group. You can also delete resources as a set, which is useful for test deployments.

  • Jenkins server. A virtual machine is deployed to run Jenkins as an automation server and serves as Jenkins Primary. In the section Install and configure Jenkins, you'll see how to install Jenkins on a new VM.

  • Virtual network. A virtual network connects Azure resources to each other and provides logical isolation. In this architecture, the Jenkins server runs in a virtual network.

  • Subnets. The Jenkins server is isolated in a subnet to facilitate management and segregate network traffic without affecting performance.

  • Network security groups. Use network security groups to restrict network traffic from the Internet to the subnet of a virtual network.

  • Managed disks. A managed disk is a persistent virtual hard disk (VHD) used for application storage, maintenance of the Jenkins server's state, and disaster recovery. Data disks are stored in Azure Storage. Premium storage is recommended for high performance.

  • Azure Blob storage. The Windows Azure Storage Learn how to use Azure Blob storage to store the artefacts created and shared with other Jenkins builds.

  • Azure Active Directory (Azure AD). Azure AD supports user authentication, allowing you to set up SSO. Azure AD service principals define the policy and permissions for each role authorization in the workflow using Azure role-based access control (Azure RBAC). Each service principal is associated with a Jenkins job.

  • Azure Key Vault. To manage secrets and cryptographic keys used to provision Azure resources when secrets are required, this architecture uses Azure Key Vault.

  • Azure monitoring services. This service monitors the Azure virtual machine hosting Jenkins. This deployment monitors the virtual machine status and CPU utilization and sends alerts.


The following recommendations apply to most scenarios. Follow them unless you have a specific requirement that overrides them.

Scalability considerations

Jenkins can dynamically scale to support workloads as needed. For elastic builds, do not run builds on the Jenkins primary server. Instead, offload build tasks to Jenkins agents, which can be elastically scaled in and out as need. Consider two options for scaling agents:

Virtual machines generally cost more to scale than containers. To use containers for scaling, however, your build process must run with containers.

Also, use Azure Storage to share build artifacts that may be used in the next stage of the pipeline by other build agents.

Scaling the Jenkins server

When you create a VM and install Jenkins, you can specify the size of the VM. Selecting the correct VM server size depends on the size of the expected workload. The Jenkins community maintains a selection guide to help identify the configuration that best meets your requirements. Azure offers many sizes for Linux VMs to meet any requirements. For more information about scaling the Jenkins primary, see the Jenkins community of best practices, which also includes details about scaling Jenkins.

Availability considerations

Availability in the context of a Jenkins server means recovering any state information associated with your workflow, such as test results, libraries you have created, or other artifacts. Critical workflow state or artifacts must be maintained to recover the workflow if the Jenkins server fails. To assess your availability requirements, consider two common metrics:

  • The Recovery Time Objective (RTO) specifies how long you can go without Jenkins.

  • Recovery Point Objective (RPO) indicates how much data you can afford to lose if a disruption in service affects Jenkins.

In practice, RTO and RPO imply redundancy and backup. Availability is not a question of hardware recovery - part of Azure - but rather ensuring you maintain the state of your Jenkins server. Microsoft offers a service level agreement (SLA) for single VM instances. If this SLA doesn't meet your uptime requirements, make sure you have a plan for disaster recovery, or consider using a multi-primary Jenkins server deployment (not covered in this document).

Security considerations

Use the following approaches to help lock down security on a basic Jenkins server, since in its basic state, it is not secure.

  • Set up a secure way to log into the Jenkins server. This architecture uses HTTP and has a public IP, but HTTP is not secure by default. Consider setting up HTTPS on the Nginx server for a secure logon.

  • Ensure the Jenkins configuration prevents cross-site request forgery (Manage Jenkins > Configure Global Security). This option is the default for Microsoft Jenkins Server.

  • Configure read-only access to the Jenkins dashboard using the Matrix Authorization Strategy Plugin.

  • Use Azure RBAC to restrict the service principal's access to the minimum required to run the jobs. This level of security helps limit the scope of damage from a rogue job.

  • Jenkins jobs often require secrets to access Azure services that require authorization, such as Azure Container Service. Use Key Vault to manage these secrets securely and store service principal credentials, passwords, tokens, and other secrets.

To get a central view of the security state of your Azure resources, use Microsoft Defender for Cloud. Defender for Cloud monitors potential security issues and provides a comprehensive picture of the security health of your deployment. Defender for Cloud is configured per Azure subscription. Enable security data collection as described in the Microsoft Defender for Cloud quick start guide. When data collection is enabled, Defender for Cloud automatically scans any virtual machines created under that subscription.

Manageability considerations

Use resource groups to organize the Azure resources that are deployed. Deploy production environments and development/test environments in separate resource groups so that you can monitor each environment's resources and roll up billing costs by resource group. You can also delete resources as a set, which is useful for test deployments.

Azure provides several features for monitoring and diagnostics of the overall infrastructure. To monitor CPU usage, this architecture deploys Azure Monitor. For example, you can use Azure Monitor to monitor CPU utilization and send a notification if CPU usage exceeds 80 percent. (High CPU usage indicates that you might want to scale up the Jenkins server VM.) You can also notify a designated user if the VM fails or becomes unavailable.

53 views0 comments


bottom of page