There are several Docker images of Jenkins available.

The recommended Docker image to use is the Official jenkins/jenkins image (from the Docker Hub repository). This image contains the current Long-Term Support (LTS) release of Jenkins (which is production-ready). However this image doesn’t have docker CLI inside it and is not bundled with frequently used Blue Ocean plugins and features. This means that if you want to use the full power of Jenkins and Docker you may want to go through described below installation process.

The Jenkins project provides a Linux container image, not a Windows container image. Be sure that your Docker for Windows installation is configured to run Linux Containers rather than Windows Containers . See the Docker documentation for instructions to switch to Linux containers. Once configured to run Linux Containers , the steps are:

When you first access a new Jenkins instance, you are asked to unlock it using an automatically-generated password.

After unlocking Jenkins, the Customize Jenkins page appears. Here you can install any number of useful plugins as part of your initial setup.

Click one of the two options shown:

The setup wizard shows the progression of Jenkins being configured and your chosen set of Jenkins plugins being installed. This process may take a few minutes.

Finally, after customizing Jenkins with plugins , Jenkins asks you to create your first administrator user.

Jenkins networking configuration is generally controlled by command line arguments. The networking configuration arguments are:

Other Jenkins initialization options are also controlled by command line arguments. The miscellaneous configuration arguments are:

Jenkins passes all command line parameters to the Winstone servlet container. More information about Jenkins Winstone command line parameters is available from the Winstone Command Line Parameter Reference.

Some Jenkins behaviors are configured with Java properties. Java properties are set from the command line that started Jenkins. Property assignments use the form -DsomeName=someValue to assign the value someValue to the property named someName . For example, to assign the value true to a property testName , the command line argument would be -DtestName=true .

Refer to the detailed list of Jenkins properties for more information.

If you’re setting up Jenkins using the built-in Winstone server and want to use an existing certificate for HTTPS:

The HTTP/2 protocol allows web servers to reduce latency over encrypted connections by pipelining requests, multiplexing requests, and allowing servers to push, in some cases, before receiving a client request for the data. The Jetty server used by Jenkins supports HTTP/2 with the addition of the Application-Layer Protocol Negotiation (ALPN) TLS extension.

These instructions use a stock Jenkins installation on Windows Server. The instructions assume a certificate signed by a Certificate Authority such as Digicert. If you are making your own certificate skip steps 3, 4, and 5.

This process utilizes Java’s keytool. Use the Java keytool included with your Java installation.

Step 1 : Create a new keystore on your server. This will place a 'keystore' file in your current directory.

Step 2 : Verify the keystore was created (your fingerprint will vary).

Step 3 : Create the certificate request. This will create a 'certreq.csr' file in your current directory.

Step 4 : Use the contents of the certreq.csr file to generate a certificate from your certificate provider. Request a SHA-1 certificate (SHA-2 is untested but will likely work). If using DigiCert, download the resulting certificate as Other format "a .p7b bundle of all the certs in a .p7b file".

Step 5 : Add the resulting .p7b into the keystore you created above.

Step 6 : Copy the 'keystore' file to your Jenkins secrets directory. On a stock installation, this will be at

Step 7 : Modify the <arguments> section of your C:\Program Files (x86)\Jenkins\jenkins.xml file to reflect the new certificate. NOTE: This example disables http via --httpPort=-1 and places the server on 8443 via --httpsPort=8443 .

Step 8 : Restart the jenkins service to initialize the new configuration.

Step 9 : After 30-60 seconds, Jenkins will have completed the startup process and you should be able to access the website at https://server.example.com:8443 . Verify the certificate looks good via your browser’s tools. If the service terminates immediately, there’s an error somewhere in your configuration. Useful error information can be found in:

All the Jenkins Kubernetes manifest files used here are hosted on GitHub. Please clone the repository if you have trouble copying the manifest from the document.

Use the GitHub files for reference and follow the steps in the next sections.

Let’s get started with deploying Jenkins on Kubernetes.

Step 1 : Create a Namespace for Jenkins. It is good to categorize all the DevOps tools as a separate namespace from other applications.

Step 2: Create a 'serviceAccount.yaml' file and copy the following admin service account manifest.

The 'serviceAccount.yaml' creates a 'jenkins-admin' clusterRole, 'jenkins-admin' ServiceAccount and binds the 'clusterRole' to the service account.

The 'jenkins-admin' cluster role has all the permissions to manage the cluster components. You can also restrict access by specifying individual resource actions.

Now create the service account using kubectl.

Step 3: Create 'volume.yaml' and copy the following persistent volume manifest.

Important Note: Replace 'worker-node01' with any one of your cluster worker nodes hostname.

You can get the worker node hostname using the kubectl.

For volume, we are using the 'local' storage class for the purpose of demonstration. Meaning, it creates a 'PersistentVolume' volume in a specific node under the '/mnt' location.

As the 'local' storage class requires the node selector, you need to specify the worker node name correctly for the Jenkins pod to get scheduled in the specific node.

If the pod gets deleted or restarted, the data will get persisted in the node volume. However, if the node gets deleted, you will lose all the data.

Ideally, you should use a persistent volume using the available storage class with the cloud provider, or the one provided by the cluster administrator to persist data on node failures.

Let’s create the volume using kubectl

Step 4: Create a Deployment file named 'deployment.yaml' and copy the following deployment manifest.

In this Jenkins Kubernetes deployment we have used the following:

If you don’t want the local storage persistent volume, you can replace the volume definition in the deployment with the host directory as shown below.

Create the deployment using kubectl.

Check the deployment status.

Now, you can get the deployment details using the following command.

We have now created a deployment. However, it is not accessible to the outside world. For accessing the Jenkins deployment from the outside world, we need to create a service and map it to the deployment.

Create 'service.yaml' and copy the following service manifest:

Create the Jenkins service using kubectl.

Now, when browsing to any one of the Node IPs on port 32000, you will be able to access the Jenkins dashboard.

Jenkins will ask for the initial Admin password when you access the dashboard for the first time.

You can get that from the pod logs either from the Kubernetes dashboard or CLI. You can get the pod details using the following CLI command.

With the pod name, you can get the logs as shown below. Replace the pod name with your pod name.

The password can be found at the end of the log.

Alternatively, you can run the exec command to get the password directly from the location as shown below.

Once you enter the password, proceed to install the suggested plugin and create an admin user. All of these steps are self-explanatory from the Jenkins dashboard.

To install Helm CLI, follow the instructions from the Installing Helm page.

Once Helm is installed and set up properly, add the Jenkins repo as follows:

The helm charts in the Jenkins repo can be listed with the command:

We want to create a persistent volume for our Jenkins controller pod. This will prevent us from losing our whole configuration of the Jenkins controller and our jobs when we reboot our minikube. This official minikube doc explains which directories we can use to mount or data. In a multi-node Kubernetes cluster, you’ll need some solution like NFS to make the mount directory available in the whole cluster. But because we use minikube which is a one-node cluster we don’t have to bother about it.

We choose to use the /data directory. This directory will contain our Jenkins controller configuration.

We will create a volume which is called jenkins-pv:

In Kubernetes, service accounts are used to provide an identity for pods. Pods that want to interact with the API server will authenticate with a particular service account. By default, applications will authenticate as the default service account in the namespace they are running in. This means, for example, that an application running in the test namespace will use the default service account of the test namespace.

We will create a service account called jenkins:

A ClusterRole is a set of permissions that can be assigned to resources within a given cluster. Kubernetes APIs are categorized into API groups, based on the API objects that they relate to. While creating a ClusterRole, you can specify the operations that can be performed by the ClusterRole on one or more API objects in one or more API groups, just as we have done above. ClusterRoles have several uses. You can use a ClusterRole to:

If you want to define a role cluster-wide, use a ClusterRole; if you want to define a role within a namespace, use a Role.

A role binding grants the permissions defined in a role to a user or set of users. It holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted.

A RoleBinding may reference any Role in the same namespace. Alternatively, a RoleBinding can reference a ClusterRole and bind that ClusterRole to the namespace of the RoleBinding. To bind a ClusterRole to all the namespaces in our cluster, we use a ClusterRoleBinding.

We will deploy Jenkins including the Jenkins Kubernetes plugin. See the official chart for more details.

Visit the Jenkins on Kubernetes solutions page for more information on running Jenkins on Kubernetes. Visit the Jenkins Configuration as Code project for more information on configuration as code. . Depending on your environment, it can take a bit of time for Jenkins to start up. Enter the following command to inspect the status of your Pod:

Once Jenkins is installed, the status should be set to Running as in the following output:

Visit 127.0.0.1:8080/ and log in using admin as the username and the password you retrieved earlier.

Copy the contents here into your preferred text editor and create a jenkins-deployment.yaml file in the “jenkins” namespace we created in this section above.

Exit and save the changes once you add the content to the Jenkins deployment file.

To create the deployment execute:

The command also instructs the system to install Jenkins within the jenkins namespace.

To validate that creating the deployment was successful you can invoke:

We have a Jenkins instance deployed but it is still not accessible. The Jenkins Pod has been assigned an IP address that is internal to the Kubernetes cluster. It’s possible to log into the Kubernetes Node and access Jenkins from there but that’s not a very useful way to access the service.

To make Jenkins accessible outside the Kubernetes cluster the Pod needs to be exposed as a Service. A Service is an abstraction that exposes Jenkins to the wider network. It allows us to maintain a persistent connection to the pod regardless of the changes in the cluster. With a local deployment, this means creating a NodePort service type. A NodePort service type exposes a service on a port on each node in the cluster. The service is accessed through the Node IP address and the service nodePort. A simple service is defined here:

To create the service execute:

To validate that creating the service was successful you can run:

So now we have created a deployment and service, how do we access Jenkins?

From the output above we can see that the service has been exposed on port 32664. We also know that because the service is of type NodeType the service will route requests made to any node on this port to the Jenkins pod. All that’s left for us is to determine the IP address of the minikube VM. Minikube have made this really simple by including a specific command that outputs the IP address of the running cluster:

Now we can access the Jenkins instance at 192.168.99.100:32664/

To access Jenkins, you initially need to enter your credentials. The default username for new installations is admin. The password can be obtained in several ways. This example uses the Jenkins deployment pod name.

To find the name of the pod, enter the following command:

Once you locate the name of the pod, use it to access the pod’s logs.

The password is at the end of the log formatted as a long alphanumeric string:

You have successfully installed Jenkins on your Kubernetes cluster and can use it to create new and efficient development pipelines.

When you first access a new Jenkins instance, you are asked to unlock it using an automatically-generated password.

After unlocking Jenkins, the Customize Jenkins page appears. Here you can install any number of useful plugins as part of your initial setup.

Click one of the two options shown:

The setup wizard shows the progression of Jenkins being configured and your chosen set of Jenkins plugins being installed. This process may take a few minutes.

Finally, after customizing Jenkins with plugins , Jenkins asks you to create your first administrator user.