OpenShift and Jenkins Integration
OpenShift provides a lot of useful functionality within its intetegrated Jenkins funcitionality that allows developers to rapidly get started with their CI & CD pipelines. In OpenShift, Jenkins offers:
- Containerized deployments (fully kubernetes integrated with containerized slave/agent pods)
- Integration with the OpenShift OAuth server
- Pipeline synchronization
- Automated Jenkins instansiation or catalog based deployment options
- Ephemeral or persistent deployment options
If you were following along in our Slack Notifications in your OpenShift Pipeline blog, there were a couple of presumptions made:
- Your Jenkins instance is persistent (to support installation of plugins)
- You manually installed the Slack plugin
Both of the above presumptions aren’t ideal when you have many plugins that you like to use and/or you leverage the same set of plugins and configurations across varying projects. Fotunately, there are two simple (lightly documented) approaches towards adding plugins to your Jenkins instances with less manual interaction.
Installing Plugins during a Jenkins Deployment
For those that have a Jenkins instance that is as unique as your Grande, 3 Pump, Skim Milk, Lite Water, No Foam, Extra Hot, Chai Tea Latte, any new empheral or persistent Jenkins instance can be extended by adding the INSTALL_PLUGINS variable to the deployment configuration as follows: <img src="https://res.cloudinary.com/arctiq/image/upload/q_auto/posts/jenkins_plugins_001.png" %}
With the above variable added, a new deployment will start, and the appropriate plugins will be installed at deployment time. <img src="https://res.cloudinary.com/arctiq/image/upload/q_auto/posts/jenkins_plugins_002.png" %}
Once logged in, each plugin is ready for customization. <img src="https://res.cloudinary.com/arctiq/image/upload/q_auto/posts/jenkins_plugins_003.png" %}
Note: any futher configuration of a plugin would still require persistent storage if it cannot be configured through code
Extending the Base Jenkins Image for Everyone
For those those cases where:
- Every team requires access to the same set of plugins
- Teams do not want to add their own plugins
- Time should be reduced for each Jenkins deployment Then the team responsible for managing base images can extend the base Jenkins image by creating a new Dockerfile and adding a list of plugins to be installed. The following example outlines a sample Dockerfile:
FROM openshift/jenkins-2-centos7 COPY plugins.txt /plugins.txt USER 0 RUN /usr/local/bin/install-plugins.sh /plugins.txt
Alongside the Dockerfile, the plugins.txt file would be located in the repository with some content as follows:
slack nodejs pipeline-npm
With the above code in place, the new Jenkins image can be built and pushed into the OpenShift repository for all to share. Additional details can be found here.
While Jenkins and OpenShift work very well together, these tips can help you extend this functionality to customize the needs of yourself or your teams.
//take the first step and we can schedule some time to chat.