The Jenkins Operator v0.7.0 on Openshift 4

Operator managed Jenkins on Kubernetes

Vibhav Bobade
5 min readDec 18, 2020
Photo by tian kuan on Unsplash

Introduction

Jenkins has been the CI/CD tool used by most companies out there big and small. Before there was DevOps, there was Jenkins and Jenkins ushered the DevOps revolution by helping abstract and automate processes which were too cumbersome to be done manually all the time.

Administration of Jenkins has thus become a real responsibility and with the increasing infrastructure needs of individuals, managing Jenkins can become tough and at times frustrating. While we understand this, Jenkins itself has tried to keep up with the times by being extensible with a massive plugin support and increasing improvements in performance especially with the onset of increased need for containerization. With that in mind, The Jenkins Operator was created to help better manage and automate the Jenkins lifecycle in Kubernetes.

We’ve come a long way

Since the last blog post on Jenkins Operator 0.4.0, we have been working on the Operator here with having a better code quality, architecture and user experience in mind. We have moved the Jenkins Operator from its previously monolith design to a more distributed design, which allows for increased performance and better code readability which makes it easier for contributors in the open source community to contribute.

Working with the Jenkins Operator on Openshift

The Jenkins Operator has been released as a Tech preview on Openshift now which can be consumed by users. In the following examples we will look at how to use the Jenkins Operator on Openshift.

Deploying the Jenkins Operator

Login to the Openshift Console and create a new project.

Install the Operator in the newly created project

Once the Operator has successfully installed please follow the documentation here to perform any of the following tasks.

Building a custom Jenkins Image

The Jenkins Operator provides the ability for the users to create their own Jenkins images which can be used in a reproducible way without having to install their plugins at runtime. This sees to it that the user has a definitive workflow and a good idea of what plugins they need to use and keep documented to have their Jenkins run in a stable manner in Kubernetes.

To be able to use ConfigurationAsCode for Jenkins you would also have to include the plugin in the Jenkins Image you are using.

You can follow the documentation provided here to create your Jenkins Image via the Operator and push it to your repository.

Configuring the Jenkins instance

As you have your Jenkins image ready , you would need to deploy it with the right configuration which fits your needs. You can follow the documentation to understand how to enable configuration as code for your jenkins instance and follow the steps to move your CasC configs from your legacy Jenkins instances to Kubernetes.

If you would like to use Backup and Restore for your Jenkins instances you would also need to enable it as given here.

Deploying Jenkins

Once you have completed the configuration you can deploy the Jenkins by creating an instance of the Jenkins Custom Resource which has been configured above.

After creating the Jenkins instance with Backup enabled you can see that the default BackupConfig as well as the example Jenkins is up.

Backup and Restore for our Jenkins instance

As we now have enabled Backup for this Jenkins instance, we can now use Backup and Restore operations using the respective Custom Resources to secure important data you don’t want to lose.

You can follow the documentation given here to understand how to configure and use the Backup and Restore operations.

Jenkins “example” was created with backupEnabled set to True and “default” BackupConfig was created for “example”.
Click on Create Instance to trigger Backup.
The BackupConfig points to the Jenkins instance so provide the reference in the Config Ref.
After Backup is completed the Condition is updated in Backup.
Click on Create Instance to trigger Restore.
Mention which Backup needs to be restored.

Running the Jenkins Operator locally

You can run the Jenkins Operator locally for development purposes. The documentation for the same is provided.

This would be very good for running locally and testing the Operator before deployment.

What’s Next ?

With the current update we have added features and updated the architecture and as we move forward we would be working on improving it further. Our focus currently is for the user to be able to automate their Jenkins lifecycle. So we would be working on fixes and features to make the Operator more robust and have a better automation lifecycle.

We would be focusing on the following:

  • BackupSchedule for scheduling backups at regular intervals
  • Persistence Support for Jenkins and Backups

--

--

Vibhav Bobade
Vibhav Bobade

No responses yet