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.
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.
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).
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.
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.
4. Once inside, install the jq tool, intended to process the JSON files’ format, which will be used by our automatization scripts:
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.)
For this example, let’s store the scripts within the dedicated /opt/demo folder.
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.
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 (i.e. Create Environment):
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.
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.