March 27, 2018 at 10:26

Introduced Jenkins X for CI / CD Cloud Applications in Kubernetes



    Last week, the authors of the Jenkins Open Source project unveiled their new brainchild, “Expanding the Jenkins Ecosystem,” designed specifically for continuous integration / delivery of applications within Kubernetes clusters. The solution was named Jenkins the X . What does it do?

    Background and essence


    The emergence of Jenkins X was promoted by the growing needs of developers in a convenient solution to CI / CD issues - one that would initially be focused on applications in cloud environments, automation, and best DevOps practices. This, in turn, was facilitated by changes in the IT industry, which include the active use of immutable container images for distributing software, 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 great regularity of releases), improvements in DevOps practices (the latter is confirmed by the results of the 2017 State of DevOps Report study from Puppet). Jenkins X development (at least public) 2.5 months are spent.

    The main idea behind Jenkins X is not globally new and is to automate everything “third-party” as much as possible , which in this case is packing applications in Docker images, creating basic YAML configurations for Kubernetes, preparing additional environments (paths, sites ... - simply called 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 being proposed for this?

    Features Jenkins X


    The Jenkins X conceptual model is presented as follows:



    The main work with occurs through the jx console utility , the list of available commands in which is described in the documentation . But the work itself essentially begins with the creation of CI / CD pipelines , for which special kits have been prepared from previously described simple applications, with which it would be easier to start your project. They are called quickstarts , 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 is implemented (for existing ones) and a simplified creation procedure (for new ones). Finally, there is a general import of existing source code using technologies other than Spring Boot.

    The “magic” is that for any of these options, Jenkins X will create Jenkinsfile (for determining pipelines), Dockerfile (for packing the application in a container image) and Helm chart (for deploying and launching the application in Kubernetes), and also integrates everything this is with git: checks the availability of webhooks for triggering a pipeline during push events, provides a pull request deployment (with building the application and running tests) on the demo site, and with merges with the wizard it will create new releases and launch them on the necessary sites.

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

    By default, two sites are provided : 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 in isolation. Rolling out releases to the sites can be manual or automatic. Demonstration platforms (Preview Environments) are

    put in a separate category , the idea of ​​which is to automatically trigger pull requests (however, it doesn’t exclude manual start) to quickly show colleagues a link with an application where the changes are applied. And the important promise that the authors make: “Jenkins X does not hide anything; you can always manually change Jenkinsfile or Helm charts for your applications and their environments - they are all versioned in Git with the rest of the source code and full CI / CD. "



    In general, the life cycle of the 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 the Gita Git server, just run the command jx create addon gitea).

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

    Acquaintance


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

    The code of the main Jenkins X utility - jx - is written in Go (distributed under the free Apache License v2). 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

    The next step to be able to use it is to create a Kubernetes cluster (or use an existing one). K8s version 1.8 and above are supported, and configuration requirements are enabled RBAC and support for unsafe Docker registries. The necessary operations for this are also quite simple and are described here . Kubernetes' officially supported environments today are AWS (AWS EKS support is expected soon), Google (GKE), Azure AKS, and Minikube.

    When Jenkins X is deployed in a cluster, it remains only to add applications (in one of the described ways: quickstarts, commands for Spring Boot, general import of code) - after that the tool is ready to use. See it in action, you can use commands jx get pipelines, jx get activities, jx get applicationsand similar, and after the first trial releases - and through the web interface for managing Git repositories (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 for its development, from which you can see, for example, that work is currently underway on support for OpenShift, Skaffold, Gitea and BitBucket, and support for GitLab is only “planned” so far.

    PS


    Read also in our blog:

    Tags:

    Also popular now: