Presented by Jenkins X for CI / CD cloud applications at Kubernetes

Last week, the authors of the Jenkins Open Source project presented their new offspring, “expanding the Jenkins ecosystem” and designed specifically for continuous integration / delivery of applications within Kubernetes clusters. The decision was called Jenkins X. What does it do?

Background and Essence

The appearance of Jenkins X was promoted by the growing needs of developers in a convenient solution of CI / CD issues - one that would be initially oriented towards cloud applications, automation, and the best DevOps practices. This, in turn, contributed to changes in the IT industry, which include the active use of unchangeable container images for software distribution, the massive choice of Kubernetes for container management in public and hybrid cloud environments, the growing popularity of microservices and cloud native applications (where CI / The CD is needed by a large number of components and with a high frequency of releases), improvements in the DevOps practices (the latter is confirmed by the results of the 2017 study of the State of DevOps Report from Puppet). Development Jenkins X (at least, public ) is 2.5 months.
')
The main idea behind Jenkins X is not globally new and is to maximally automate everything “third-party” than in this case packaging applications in Docker images, creating basic YAML configurations for Kubernetes, preparing additional environments (contours, pads ... - called simply Environments ), setting up typical pipelines for CI / CD. In general, as the authors themselves say, “focus on creating value” [instead of the necessary routine]. What is offered for this?

Jenkins X features

The conceptual Jenkins X model is represented as follows:



The main work with occurs through the console utility jx , a list of available commands which is described in the documentation . The work itself essentially begins with the creation of the CI / CD pipelines , for which special kits are prepared from previously described simple applications, from which it would be easier to start your project. They are called quickstarts , are placed in separate Git repositories ( an example for Go ) and, of course, can be created independently.

Particular attention is paid to projects on Spring Boot, for which a separate import (for existing ones) and a simplified creation procedure (for new ones) are implemented. Finally, there is a general import of existing source code that uses technologies other than Spring Boot.

The “magic” is that for any of these options, Jenkins X will create a Jenkinsfile (for defining the pipelines), a Dockerfile (for packaging the application in a container image) and a Helm chart (for deploying and running the application in Kubernetes), and also integrates everything this is with Git : will check the availability of webhooks for triggering the pipeline during push events, provide warm pull requests (with application building and running tests) on the demo site, and when merge with the master it will create new releases and launch them on the right platforms.

Note : The authors themselves explain the choice of Helm (and Draft) as the method of interaction with Kubernetes with their desire to follow the principle of “configuration as code”. Helm - charts packages are based on templates and look more preferable (more logical) than the “classical” method (ie, manual work with YAML documents and their transfer to kubectl).

By default, there are two sites : Staging and Production - but this is easy to change for your tasks. Each of them is given a separate namespace in Kubernetes, so that they function and are managed separately. Rolling out releases on the pads can be manual or automatic.

Demonstration sites (Preview Environments) are put into a separate category, the idea of ​​which is to automatically trigger pull requests (which, however, does not exclude manual launch), in order to quickly show colleagues a link with the application where the changes are applied.

And the important promise made by the authors: “Jenkins X does not hide anything; you can always manually change the Jenkinsfile or Helm charts for your applications and their environments - all of them are versioned to Git with the rest of the source code and full CI / CD. ”

In general, the life cycle of code served by Jenkins X looks like this:



Finally, support is provided for add-ons that extend the capabilities of Jenkins X (for example, to get support for Gite-server Gitea, just run the jx create addon gitea ).

Jenkins X is built on the basis of Jenkins and is supposed to be included as a subproject (already created by JEP - Jenkins Enhancement Proposals - number 400 ), which expands the capabilities of Jenkins itself using the selected Git development model, infrastructure from Kubernetes and helper Open Source tools (Helm , Nexus / Artifactory and others).

Acquaintance

For a visual demonstration of the main features of Jenkins X, a 10-minute video was prepared, the author of which executes the main commands in the console and checks the result in Git-repositories and a web browser.

The code of the main utility Jenkins X - jx - is written in the Go language (distributed under the free Apache License v2 license). So its installation is trivial - in the case of Linux it comes down to:

 curl -L https://github.com/jenkins-x/jx/releases/download/v1.1.10/jx-linux-amd64.tar.gz | tar xzv sudo mv jx /usr/local/bin 

A further step to enable its use is to create a Kubernetes cluster (or use an existing one). K8s versions 1.8 and higher are supported, and configuration requirements are included in the enabled RBAC and support for insecure Docker registries. The necessary operations for this are also very simple and are described here . The officially supported Kubernetes environments today are AWS (AWS EKS support is expected soon), Google (GKE), Azure AKS and Minikube.

When Jenkins X is deployed in a cluster, all that remains is to add applications (one of the following methods: quickstarts, commands for Spring Boot, general code import) - after that the tool is ready for use. You can look at it in action with the help of the jx get pipelines , jx get activities , jx get applications and similar commands, and after the first trial releases - and through the Git-repositories web management interface (GitHub):

Development plans

Jenkins X releases are collected every day (and sometimes even more often), however, announcing this product, the authors remind that the project is still "very young."

There is a table with a roadmap of its development, from which you can see, for example, that right now we are working on support for OpenShift, Skaffold, Gitea and BitBucket, while support for GitLab is only “planned”.

PS

Read also in our blog:

• " Officially present dapp - DevOps utility to maintain the CI / CD ";
• “ Build and heat applications in Kubernetes using dapp and GitLab CI ”;
• “ Best CI / CD practices with Kubernetes and GitLab (review and video of the report) ”;
• “ We assemble Docker images for CI / CD quickly and conveniently along with dapp (review and video of the report) ”;
• " CNCF Guide to Open Source Solutions (and more) for cloud native ";
• “ How many developers think Continuous Integration is not needed? ".