The last 4-5 years have seen the debut of many new software products specifically targeting both infrastructure services and IT automation. The consumerization of IT has caused its architects to take a fresh look at their existing, often times monolithic apps and IT infrastructure and asking: Can we do better? How do I keep IT relevant? How do I keep track of all these VMs and data? How do I scale out my IT environment without a huge budget increase or physical buildout? How do I develop and get bits to production faster and with higher quality?
These organizations are looking to evolve their development and deployment processes to be more agile and accelerate time-to-market. They are trying to embrace things like DevOps and Continuous Deployment to do that. They are breaking monolithic apps out into microservices that can be independently updated, with a focus on speed and agility, so their apps can be more reactive to changes in their business. They are evolving from traditional virtualization to public and private cloud deployments.
There are strong parallels between the way open source communities produce great software and how IT orgs build and deliver great software and services. Red Hat, a recognized pioneer in open source, is using its deep experience in open source to build products that support microservice-oriented, DevOps-embracing, container and cloud-centric IT shops.
Jenkins
During my discussions these types of Red Hat customers, the average time it takes from the first mention of CI/CD or DevOps to the first mention of Jenkins is around 5 seconds. And it's no surprise -- this evolution to modern app dev means that the best supporting tools - the preferred axes and grindstones of dev - consistently rise to the top in terms of usage. And the clear leader in this particular space is Jenkins.
Many Red Hat products and projects support, complement, or implement CI/CD/DevOps initiatives, and we'll be at JenkinsWorld this week in Santa Clara to talk about how Red Hat can help companies innovate faster with our DevOps-native products. Let's look at some of those those use cases:
Jenkins Plugins
If you're a Jenkins user already, you're undoubtedly familiar with the huge number of official Jenkins plugins within its ecosystem. Some of these plugins are actively maintained by Red Hat, and some maintained by others in the Jenkins community. They provide a clean integration between Jenkins and Red Hat products and projects that are typically used in the context of DevOps:
WildFly / JBoss EAP plugin - Enables Jenkins to automatically deploy apps to local or remote, standalone or domain WildFly and/or JBoss EAP (including EAP 7!). Can be used as Build Step. More examples in Deon's excellent blog on EAP 7 deployment with Jenkins.
Ansible plugin - This plugin lets you invoke Ansible playbooks using Jenkins and Ansible Core. You can also use Dynamic Inventories from places like Cobbler, OpenShift, OpenStack, Amazon EC2 and more.
Kubernetes plugin - The base Kubernetes plugin primarily exists to allow you to dynamically provision Jenkins slaves within a Kubernetes cluster, for scalability as well as providing pods with specific runtimes for specific jobs. It supports several different authentication schemes (service accounts, OAuth tokens, and more). And while it is very useful for the average Jenkins user, if you are using this chances are you are using Kubernetes and/or OpenShift for more than just hosting Jenkins slaves - see below for the other use case for Jenkins+Kubernetes/OpenShift!
OpenShift Sync plugin - Specific to the OpenShift PaaS use case are two plugins - the first is the OpenShift Sync plugin. As its name suggests, this plugin synchronizes the state of OpenShift Builds and BuildConfigs with the state of Jenkins and Jenkins Jobs. Useful when you use Jenkins as a CI/CD component of a much larger developer integration/build/test/deploy/manage platform (which is exactly what fabric8 does, and is where the source code to this plugin resides - see below for details!).
OpenShift Pipeline plugin - Jenkins provides support for defining jobs as a pipeline of steps which can be repeatedly executed, and whose state can be visualized within Jenkins or rendered elsewhere by monitoring through the Jenkins API. Plugins can provide components that can be used within the definition of pipelines, which is what this plugin does. It exposes much of OpenShift's functionality (such as triggering builds/deployments, promoting images from dev to test to production, or scaling deployed apps). It makes it easy to define new jobs (either using Build steps or as a pipeline, using the DSL support provided by the plugin).
Jenkins support/integration in Red Hat
Red Hat has several products and projects that are often involved in one way or another in CI/CD/DevOps initiatives. The uses cases are many (it's lifecycle infrastructure for any kind of app, after all!) so I won't go into those here. But suffice it to say, you'll find JBoss Middleware, OpenShift, fabric8 and Ansible at the heart of many a Red Hat customers' programs. Those same programs integrate with Jenkins in several different ways described below:
Jenkins with OpenShift
Jenkins is a first-class citizen of the OpenShift ecosystem, and there are several aspects that make them a great combination:
- Official S2I images - OpenShift Origin provides a Docker image for running Jenkins. This image provides a Jenkins server instance which can be used to set up a basic flow for continuous testing, integration, and delivery. You can create a custom version of this (for example, to include custom Job descriptions, Jenkins configuration, credentials, plugins, etc).
- Label-based slave deployment - when using the official Jenkins images (or a derivative that you've created), OpenShift will configure Jenkins to use it as a slave deployment platform, and deploy slaves dynamically from image streams labelled with
role=jenkins-slave.
Using these features, along with the previously mentioned features from plugins means that you can implement your own deployment pipeline automated with the Pipeline plugin for deploying to OpenShift, complete with source to image creation, advanced test phases, gated approvals, and deployments, using the best of OpenShift and Jenkins.
OpenShift 3.3 will go even further and bake in much of the above feature set directly into OpenShift (powered by Jenkins!). Check out Steve's Early Look at OpenShift 3.3 for more details.
Jenkins with Ansible Tower
Jenkins and Ansible are often used together to handle various aspects of a CI/CD solution. As we all know, before CD can be achieved, the first step is to achieve CI. CI systems are build systems that watch various source control repositories for changes, run any applicable tests, and automatically build (and ideally test) the latest version of the application from each source control change, such as Jenkins.
The key handoff for CD is that the build system can invoke Ansible upon a successful build. Users who also run unit or integration tests on code as a result of the build will also be one step ahead of the game. Jenkins can use Ansible Tower to deploy the build artifacts into dev, test, prod, or some combination. The data provided back by Ansible can then be referenced, and directly correlated to a Tower job in the Build Systems job.
If you're attending JenkinsWorld this week, don't miss Dylan's talk on Jenkins with Ansible Tower, which includes a sneak peak at an even deeper integration between the two very popular products in the near future.
Jenkins with fabric8
fabric8 describes itself as "an opinionated open source microservices platform based on Docker, Kubernetes and Jenkins." Red Hat has enthusiastically sponsored and participated in the fabric8 community, which selected Jenkins as the default and recommended implementation for CI/CD. Specific Jenkins-related features include:
- A reusable pipeline library such that projects no longer have to maintain their own pipeline definition when in most cases, projects will use the same pipeline (build; test; stage; wait for approval; promote).
- The fabric8 Maven plugin can connect to various DevOps services provided through fabric8 like git hosting, chat, issue tracking and CI/CD builds in jenkins.
- Teams often have many git repositories with many artifacts and docker container builds. Manually maintaining individual Jenkins build configurations for each git repository can be time consuming and error prone, so fabric8 provides a way to use the Jenkins Job DSL to generate job definitions for your projects. This is one of the coolest and most DRY-ish solution I've ever seen for automating Jenkins config.
Jenkins on Red Hat OpenStack Platform
All of the components and frameworks and integrations above must run somewhere, and that somewhere is increasingly found on public, private or hybrid clouds. For large deployments that need enterprise-grade cloud infrastructure for their DevOps initiatives, consider the combination of Red Hat OpenStack Platform and CloudBees Jenkins Platform. It's a great combination of rockstar solutions that use familiar technology you're already using, supported by companies that are also significant open source contributors to the respective upstreams.
If you're at JenkinsWorld this week, be sure to visit the Red Hat booth, and don't miss these sessions:
DevOps Native (BoF)
David Codelli, Red Hat
Wednesday 5:00pm Exhibit Hall A-2
CI/CD with Jenkins and Ansible Tower
Dylan Silva (@Thaumos),Red Hat
Thursday 1:30pm Exhibit Hall A-3
How to do continuous delivery with Jenkins Pipeline, Docker and Kubernetes
James Strachan (@jstrachan), Red Hat
Thursday 2:30PM Great America J