Jenkins X Brings Automated Pipelines to Kubernetes
The Jenkins continuous integration server has long been a staple of the DevOps revolution. As the central coordination server for automating tasks in a continuous integration and continuous deployment environment, development and operations teams all over the world have embraced and built expansions and build packs for Jenkins. The move to container-based environments, however, isn’t exactly the space for which Jenkins was built.
James Strachan, senior architect at Cloudbees, is the project lead on Jenkins X, and he’s been thinking about what this migration means for Jenkins users for some time now. He said that moving your CI/CD pipelines to container-based cloud hosting environments that utilize containers and container orchestrators such as Kubernetes pushes the need for even more automation in the build, test, and deploy process. For that to happen, said Strachan, Jenkins X needs to be easier to understand and work with than regular Jenkins.
“What we’re trying to do is break that barrier between the one or two people who know Jenkins well, and everyone else on the team who might want to do things. The big difference in this age of microservices is that we need developers to be able to spin up new projects whenever they wish. We want to make Jenkins self-service like the cloud is,” said Strachan.
“The aim of Jenkins X is to turn Jenkins into a self-service appliance, so any developer can spin up a new project and all the pipelines and everything just happen. We’re not saying you shouldn’t have people on your teams who know Jenkins, it’s more that we’re trying to make CI/CD more of an appliance like the rest of the cloud,” he said.
Strachan detailed the nitty-gritty technical bits of Jenkins X in a blog post in mid-March when the project was first announced to the public. In it he explains that Jenkins X can be used to set up a Jenkins Pipeline, automatically generating a Jenkinsfile and Dockerfile to define the pipeline and packaging steps for applications.
Because Docker and Kubernetes behave differently than some of the environments Jenkins grew up in, Strachan said Jenkins X is all about bringing security into the somewhat complex container image construction process. Strachan said users can use their own Dockerfiles or pop in a pipeline to their preferred container construction tool. Strachan points out Skaffold as a tool for building and tagging Docker images, which he says is a big deal despite sounding simple.
“[Skaffold] manages the complexity of Docker and the security models. If you’re using Google Cloud, you might want to use Google’s container builder. You might want to use a SaaS CI, or a local Docker socket in your Kubernetes cluster. This has security implications because it kind of gives you root on the box, so you’d never let someone have access to the Docker socket in the production cluster, for example,” said Strachan. “By default, Jenkins S assumes you’re on a development cluster and will have access to the Docker socket, but we understand there are alternatives.”
Strachan sees this as a major issue for building Docker images, in the future. “We need a tool like Skaffold to hide that mess from users. I am hoping that can be fixed soon,” he said. He had heard murmurs that Skaffold might address this issue in a few months.
“On the development cluster, you let people use Docker to build images. You’re trusting your developers to not mine bitcoins. On the production cluster, you never build images, you just use them. It’s a simple approach which is easy to do and not too scary,” said Strachan. “I think longer term it would be better to pull Docker building out of the Kubernetes cluster by being able to build Docker images without the Docker daemon, or root, or special privileges.”
Stability and Compatibility
For the future, Strachan said the Jenkins X team has a lot of goals around stability and compatibility. “The main thing is checking everything works for everybody. It’s quite challenging supporting lots of clouds at the same time. Trying to get a rock-solid system of clusters is the first focus. Another focus is supporting more git providers and issue trackers. We’re adding Jira support, and a bunch of people in the community are extending to other git providers, like GitLab and BitBucket,” said Strachan.
“Our more longer-term work is based around improving feedback, and integration, and so forth. We have a large roadmap, mostly around increasing the number of build packs. There’s a bunch more languages missing that we need to add,” said Strachan.
Another thing the core development team is mulling is an integration with the Anchore CI/CD security scanning software. Anchore analyzes code and Docker images against a database of vulnerabilities.
Yet in among all these complex goals is one piece of code that Strachan says has saved the Jenkins X team a great deal of time: UpdateBot. This little tool runs across the repositories updating library dependencies in other projects, automatically submitted pull requests to utilize the new dependency.
“Sometimes you have someone working on an upstream library,” said Strachan, “And other teams are building downstream. What often happens, if there’s no information exchange, is that library rarely gets updated. If you’re updating the library, you want CD for your libraries. What UpdateBot is doing is applying principles of CD for libraries. Libraries don’t get deployed as Docker images, but they do get deployed as a version change, or an updated XML file, or a base Docker image file.”
Strachan said the simple act of pushing a pull request to all downstream consumers of the library being updated can keep bugs from becoming hidden behind large update cycles.
“The thing I particularly like is that if the upstream developer breaks something, they know because in the release that goes out, all these pull request will start failing. You avoid the friction and frustration when one team breaks something for another team. The team that breaks it today is often unaware they broke anything. Because it often takes a long time for changes to proliferate through an organization, by the time you realize something is broken, you’ve done 700 changes and you have no idea which one broke it,” said Strachan.
