Specialized Jenkins distribution masks some Kubernetes complications
So your development team has mastered continuous integration (CI) and continuous delivery (CD) to traditional environments. Is it ready to do the same for Kubernetes apps?
With the continued growth of containerization in general (and Kubernetes in particular), managers increasingly face this question. To their rescue comes Jenkins X, which bundles Jenkins‘ core with plug-ins to focus on “Kubernetes, CI/CD and Cloud Native use cases“. It aims to automate CI and CD by bridging the gap between the development tools of Jenkins and the delivery tools of Kubernetes.
At KubeCon + CloudNativeCon in Seattle this past December, TFIR’s Swapnil Bhartiya sat down with Jenkins X’s project leader James Strachan, who also holds the title of Distinguished Engineer at CloudBees.
From “roll your own” to rock ‘n’ roll
Strachan credits Kubernetes with making Jenkins X possible. “Kubernetes has changed everything,” he said. “Before Kubernetes, we had a whole plethora of different cloud providers with different APIs.” In such a diverse environment, he said, users are often saddled with repetitive manual tasks. “Normally people do the CD part themselves. They figure out how to make tarballs and copy apps around.”
“With Kubernetes we now have a single, standard way to package applications as Docker images and run them on any cloud infrastructure. Because Kubernetes defines a canonical standard way of packaging and distributing and deploying applications, we’ve been able to automate CI and CD for Kubernetes applications. So we can basically take your source code and automatically release it whenever you make a change — create Docker images, create Helm charts. And then we promote your application through your environment: development, testing, staging, and production.”
But while Kubernetes unified application delivery, Strachan warns that developers need to learn new skills to make the transition to containerization and cloud-native apps.
“As soon as you move to the cloud from traditional deploying — enterprise Java apps in a bunch of VMs, for example — you have to almost start from scratch because everything’s different. You’re building Docker containers, you’re building Helm charts. You do rolling upgrades, maybe ‘canarying’ with Istio, and so forth. There’s quite a learning curve to use the cloud well and use Kubernetes effectively.”
Kubernetes too hard? No problem.
This training barrier was one of Strachan’s inspirations for creating Jenkins X. “In many ways we’re trying hide the Kubernetes,” he said. “You don’t need to know what a Docker file is. You don’t need to know what a Jenkinsfile is. We automate it all. But when you’re ready to learn more about Kubernetes, you can peel back the curtain. We’re trying to get you going quickly; then slowly, over time, you can learn more about the details.”
As an example he cited the command, ‘jx create cluster gke‘. “It will spin up new cluster on Google Cloud using the ‘gcloud’ command-line tool from Google. It will install Jenkins X on it. And then after typing that one command you’re ready to go,” he said. “So we’ve automated all the common things you will need to do, whether that’s installing Jenkins X on an existing Kubernetes cluster, or that’s spinning up a brand new Kubernetes cluster on Amazon, Google, Microsoft, DigitalOcean, IBM, Oracle, or PKS from Pivotal. Whatever clouds you’re using, Jenkins X works there.”
“So developers don’t need to focus too much on the Kubernetes side. They focus more on the application code and using Git and doing pull requests and whatever. Kubernetes just happens in the background — it’s an implementation detail. You write some code, and it gets deployed to Kubernetes.”
“Kubernetes all the time”
Recent developments within the Kubernetes ecosystem also drove Jenkins X’s development. “Service mesh is the new hotness in the Kubernetes ecosystem,” said Strachan. “As we start to use more service mesh techniques — mutual TLS between all services for better security, chaos testing, automatic load balancing and retries, circuit breakers, all of this awesome stuff — it’s getting harder and harder and harder to run apps on your laptop as if they’re in Kubernetes.”
But with Jenkins X making service spin-up so easy, there’s less reason to develop on your laptop. “One of the things that we’ve been trying to do with Jenkins X is to encourage developers to always run their code in Kubernetes. So don’t run it on your laptop and then submit a pull request while you’re editing the code. Compile, run it in Kubernetes all the time.”
“We should always be as near to the production environment as we can, all the time. There’s literally no point running an app on a Windows machine if you’re deploying to a Linux container in Kubernetes.”