Docker-based Integration in Jelastic

today, after a short break that we’ve taken for the joker 4.x release , comes the continuation of our devops guides series you’ve been so eagerly waiting for. its fourth part is devoted to the continuous integration of dockerized applications. we’ll consider how to evolve the already known ci/cd scenario, leveraging tight integration of docker containers technology at jelastic paas.

just as in the previous articles of the series, the goal we are pursuing is to create a fully automated devops workflow, intended to manage application’s lifecycle during all its stages, from creation (update) to the production-ready release. for that, we’ll reveal the implementation of a rather complicated ci/cd pipeline, that implies involvement of different team departments, each of which works with its own isolated hardware region:

still being based on jenkins as a continuous integration server, today’s scenario has some specifics, as containers brought new approach for implementation of devops workflow. namely, both integrator and example project will be delivered within the appropriate docker containers:

such an arrangement allows to simplify the preparation of stage-devoted environments (due to the standardized containers’ delivering format) and perform instant integration of new product versions. in such a way, you’ll get the result faster with less efforts, while all the spared time can be forwarded to the development, increasing your general productivity and competitive capabilities.

as this article is tightly connected with the previous parts of the ” devops tools for continuous delivery in jelastic private cloud ” series, we will periodically refer to them in order not to repeat describing the same steps. that’s why we recommend you get acquainted with these guides firstly before proceeding further:

• part 1: workloads distribution and jenkins installation
• part 2: configure jenkins for app life сycle automation
• part 3: automated jenkins configuration via cloud scripting add-on (describes how to automate the previously considered manual operations)

platform preparation

we’ll use the same platform configurations as in the previous examples of devops pipeline usage, i.e. separate hardware sets allocated for all of your project teams (one per each development phase) with the appropriate access permissions adjusted:

such multi-region structure ensures the proper isolation so that different departments won’t interfere in others’ processes.

according to the above-considered pipeline, it is implied that the delivered application undergoes a set of initial tests at the dev stage. however, if your project is less complicated and all the development-related operations are performed locally, you can follow the simplified workflow:

in this case, the separate dev region is not required, as your project can be transferred directly to the qa team for comprehensive testing just after the appropriate changes are committed to a registry.

throughout the instruction below, we’ll also draw your attention to the steps that can be skipped while building such simplified solution.

jelastic paas is supplied with a convenient administration panel (jca) for cluster management, so you can build the desired region structure in no time. in our example, it’s three different user groups (representing dev , qa and ops departments) with the dedicated sets of hardware each:

in such a way, users from the appropriate groups can use the specified sets of hardware only, but at the same time – they have a possibility to transfer their environments throughout the whole platform (i.e. between different teams’ accounts).

jenkins configuration

now, let’s create our orchestrator, i.e. jenkins server, within a new environment – we’ll use its official docker template for that.

1. so, call the environment wizard with the new environment button, switch to the docker tab and add the jenkins image. finish the rest of the configurations (resource limits, desired name, etc) on your own.

tip: find out more details on docker containers management at jelastic.

2. the creation may take a few minutes in order to be completed, after which you’ll get the similar environment at your dashboard:

3. next, you need to define the appropriate structure for the environment with your application and set up its proper transferring workflow between lifecycle stages. as previously, we’ll use the special dedicated scripts for that (the process is considered in details within the management scripts for jenkins document). in order to proceed further, you need to connect to your jenkins container under the ssh protocol first.

in case you haven’t performed similar operations before, you need to:

• generate an ssh keypair
• add your public ssh key to the dashboard
• access your account via ssh protocol

4. once inside, install the jq tool, intended to process the json files’ format, which will be used by our automatization scripts:

apt-get install jq

5. now, you need to add the required scripts to the container. for this tutorial, we’ve slightly adjusted the previously used script templates due to the dockerized apps’ delivery specifics, so please use the following ones as examples:

• install.sh – creates a new environment via the jelastic api according to the specified manifest file
• transfer.sh – changes the environment ownership based on the jelastic environment transferring feature
• migrate.sh – physically moves an environment to another hardware set (hardnode group)
• runtest.sh – runs the required set of tests (in our example, it just simulates the testing activities for demonstration purposes, so the exact code is not provided). thus, create your own check up script according to the specifics of your application (or several ones, if such are needed for different stages, e.g. dev-tests, qa-tests, etc.)

note :

• do not forget to modify the presented templates according to the used platform’s parameters (see the list of required adjustments ).
• the manifest file, which sets the environment topology to be created by the install script, was also completely rebuilt – for now, it consists of two jelastic/tomcat8 docker containers (with our default hello world app deployed) and the jelastic/haproxy image as a load-balancer:

in case you need assistance on a proper manifest creation, refer to our documentation .

for this example, let’s store the scripts within the dedicated /opt/demo folder.

tip: starting with the 4.0 platform version, the same operations can be performed through the embedded dashboard containers’ file manager :

setting jenkins jobs

once the general jenkins preparations are finished, we can proceed to creation of jobs for our integrator (you are probably already familiar with this process due to the previous guides, thus we’ll highlight only the main steps):

1. the intended flow we are going to establish looks like the following:

create environment > dev tests > migrate to qa > qa tests > migrate to production

you can also notice, that comparing with the previously considered implementation, the build and deploy step is missed here – since your application is delivered within a docker container, it doesn’t require to be separately deployed.

note:

• if building the simplified pipeline, the dev tests and migrate to qa jobs can be skipped, while the create environment one should point to the qa team account
• while adding jobs, please pay attention on stating proper path to the directory with your project (we’ve set it in the previous section, i.e. /opt/demo one in our case), as it differs from the one we had used previously (i.e. in the linked instruction, when handling jenkins via tomcat)

2. before proceeding further, check if your jobs work as intended. for that, run them manually one-by-one and review all the intermediate results to ensure everything is fine.

3. if there are no any problems, connect your jobs into a single flow (i.e. create environment > dev tests > migrate to qa > qa tests > migrate to production ) using the post-build actions section.

4. now, you need to add a webhook, which will automatically initiate this cycle’s running. for that, copy the scheduling link of the first job in the chain:

5. next, log in to your docker hub account and move to the repository with your application image ( jelastic/tomcat8 in our case).

switch to the webhooks tab and click the add webhook button.

6. within the opened frame, set any desired name to the first field and paste the url you’ve just copied to the second one.

click create to add your webhook.

note: in case your environment consists of a bundle of different images, that are developed and are meant to be changed, webhook should be added to each of them.

that’s it! now, as everything is set up, all of the jobs will be consequently run each time you update your application’s image with the docker push command. as a result, you’ll automatically receive the latest project version at production without any manual actions required.

try this out! integrate your own solution into the jelastic cloud or, at least, test the ours’ one by yourself – just request us for a free cloud evaluation or start with a trial account at one of our hosting partners. also, subscribe to our blog to not miss the upcoming article, where we’ll reveal how to easily swap the development and production versions’ of your dockerized application without any maintenance and downtime using the in-built jelastic paas functionality.

related articles:

part 1: workloads distribution and jenkins installation

part 2: configure jenkins for app life сycle automation

part 3: automated jenkins configuration via cloud scripting add-on