Extending Jenkins X for Traditional Deployments with CloudBees Flow

Editor's Note: This blog post was originally published on CloudBees Technologists .

Jenkins X is quickly becoming the de facto standard for high performing teams wanting to do CI/CD in a highly scalable, cloud native and fault tolerant environment. For those who haven’t gotten the opportunity to try out Jenkins X, it will allow teams to run CI/CD workloads natively in a Kubernetes environment in an opinionated fashion while taking advantage of modern operating patterns like GitOps and serverless architectures. For teams wanting to modernize their continuous integration and continuous deployment capabilities, Jenkins X is the go to solution.

In today’s heterogenous technology environment, most organizations tend to have a mix of modern cloud native architectures as well as more traditional workloads which get deployed either on-premise or to the cloud. CD for traditional workloads is something in the future plans of Jenkins X. Today you can use a combination of Jenkins X (performing CI steps) and CloudBees Flow (handling the deployment) to add a huge amount of flexibility and power to a continuous delivery process. The combination of Jenkins X and CloudBees Flow also brings improved visibility and traceability across the application landscape.

Jenkins X can be easily extended to accommodate any type of workload required - it can be a full end to end CI/CD tool for building, deploying, and running applications all within a Kubernetes cluster, or it can handle CI while offloading other release and deployment tasks to another solution. In this blog post we’re going to cover how Jenkins X can be extended to offload release/deployment tasks to CloudBees Flow . We will accomplish this by extending the maven Jenkins X build pack in order to call the CloudBees Flow REST API as part of the Jenkins X pipeline execution.

Extending Jenkins X

For the purposes of this blog, we’re going to be focusing on the Jenkins X serverless pipeline execution engine with Tekton (See https://jenkins-x.io/architecture/jenkins-x-pipelines/ ). There are two main ways to customize a Jenkins X pipeline in order to integrate with CloudBees Flow. The first and simplest would be to modify the jenkins-x.yml (more information on Jenkins X pipelines: https://jenkins-x.io/architecture/jenkins-x-pipelines/#differences-to-jenkins-pipelines and the jenkins-x.yml file) pipeline file in the source code repo for the project we’re going to build. The other way is to extend the Jenkins X build packs and modify the build pack for the language/build tool you want to use. Both will work, but by forking the build packs you can get reuse across multiple projects using the build pack you extend. In this example, we’ll walk through how to extend the Jenkins X build packs.

Creating your cluster and installing Jenkins X

To start, we’ll fork the Jenkins X Kubernetes build packs into our own repository: https://github.com/jenkins-x-buildpacks/jenkins-x-kubernetes . Later we’ll be extending the maven build pack to support a REST API call into CloudBees Flow.

Now it’s time to create a Kubernetes cluster on GKE using Jenkins X and Tekton . In this case, we’re starting by creating a cluster from scratch, but Jenkins X can also be installed into an existing Kubernetes cluster if you already have one available by using the jx install command:

Fill out the options. For example:

Create an ingress controller if one doesn’t exist and setup the domain or use the default *.nip.io address if you don’t have one. Go through the prompts and then configure your GitHub credentials. Create an API token using the URL provided if you don’t have one:

In the setup we’re going to choose the Kubernetes workloads option and later modify the kubernetes workload build packs to include the CloudBees Flow specific steps:

Editing the Build Packs

You can use your favorite IDE but in this case, we’ll modify the Jenkins X build packs in VS Code with the YAML Language extension installed (https://jenkins-x.io/architecture/jenkins-x-pipelines/#editing-in-vs-code ) for validation as recommended by the Jenkins X team.

This example is going to focus on a sample Spring Boot application using Maven. To start we’ll modify the maven build pack in our forked build pack repo

Compare the original build pack for maven found here: https://github.com/jenkins-x-buildpacks/jenkins-x-kubernetes/tree/controller/packs/maven vs. our forked build pack. We’ve removed all the references to skaffold, watch, and helm since we’re no longer having Jenkin’s X handle the deployment to our Kubernetes cluster. We’ve also updated the pipeline file to make an API call into our CloudBees Flow server using cURL :

The above API call into CloudBees Flow tells Flow to run a pipeline called my_pipeline within a project called my_project .

You’ll also notice that we’re using a Jenkins X feature (jx step credential) to get our secret, flow-token , which we created previously so that we can authenticate to the Flow Rest API. Note that there are many other possible ways to call into the CloudBees Flow API’s besides cURL such as the command line tool ectool as well as perl or groovy libraries . Also note that for a production environment we would want to setup the proper certificates rather than using the --insecure parameter .

Next, we need to tell Jenkins X to use our new build pack:

Since we have to authenticate when calling the Flow REST API , we’ll create a Kubernetes secret to store our username/password basic authentication token:

Note: In this case, the <Basic Auth Token> will take the form of username:passwordbase64 encoded. Take note that we’ll actually need to base64 encode our username:password token twice as it will get base64 decoded automatically when we access it later.

To apply the secret in our Kubernetes cluster, we can save our secret to a file called flow-token-secret.yaml and run the command:

Creating a sample Spring Boot project

To test out our new build pack, we’ll use Jenkins X’s capability to create a quick start project for a Spring Boot microservice:

Once created, the project should build and run automatically. If everything worked, we should see our Spring Boot project built with Maven, artifacts uploaded automatically to our Nexus repository and then our CloudBees Flow pipeline executed within our CloudBees Flow server.

If for some reason, we made a mistake, the pipeline can be re-run by using:

To debug, build logs can be checked with:

Or more specifically with our project name:

We can get build activity with:

Or more specifically:

In conclusion

In the above example we were able to use Jenkins X to build our application as well as store the built artifacts, and then utilize CloudBees Flow to handle execution of our release pipeline. This allows us to take advantage of the scalability and efficiency of Jenkins X while leveraging the power and control of CloudBees Flow for managing the release.

For organizations who want to take advantage of modern CI/CD on Jenkins X but are not yet “all in” on Kubernetes and still deploying traditional applications, this provides a very solid approach to achieving continuous delivery.

Try Jenkins X and support for Jenkins X from CloudBees.

Additional resources

• Download the eBook on building cloud native applications

• Watch the video on Jenkins X providing continuous delivery for Kubernetes

• Subscribe to the biweekly Jenkins X newsletter