CI/CD automation (Part II)
In CI/CD automation (Part I), we discussed about basics of CI and CD. This blog depicts the practical representation of continuous integration of micro services based projects like Docker.
Therefore mentioned configuration involves continuous integration of docker using CI server Jenkins. It automatically fetchs the repository from bitbucket server, builds the image using Dockerfile and uploads it to the Dockerhub. In short this whole process can be named as “Automated Docker Deployment using Jenkins”
Before we start with the automation process, allow me to familiarize you with following terms
1. Jenkins
Jenkins is a Continuous Integration server. It is an agent which co-ordinates between user’s code repository and build server. It regularly checks for changes on user’s server. In case of any changes, it gathers and sends them to build server
2. Docker
Docker is a tool designed to make an application creation, deployment, and execution easier by usage of containers. It is designed to benefit both developers and system administrators, making it a part of many DevOps toolchains
3. Dockerfile
A Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image
4. Bitbucket
Bitbucket is a web-based hosting service for projects that use either the Mercurial or Git revision control systems.
As you are now familiar with important terms let’s get started with the automation
Let’s consider a scenario of automatic process of
- Getting source code from Bitbucket repository
- Building image from Dockerfile
- Pushing it on DockerHub
Prerequisite:
- Sample Application (for demo purpose we have taken “Django-Sample-App” from “www.github.com”)
- Bitbucket Access
- DockerHub account
- Jenkins
- Docker Build and Publish plugin
- Bitbucket plugin (Optional)
STEP 1 : Configuring the application
Clone GitHub project from this link (https://github.com/kirpit/django-sample-app)
To setup the application on a local machine follow all the instructions provided in the link description. If you have your own application on machine then do configure it according to your need.
STEP 2 : Writing a Dockerfile
Write a Dockerfile for the project to build the image of that application.
Here’s the Dockerfile for “Django-sample-app”,
STEP 3 : Add current project to bitbucket repository
After creating Dockerfile for that application, add entire project it to the Bitbucket repository with Dockerfile by using the commands given below:
#cd
#git init
This command creates an empty Git repository which will have an extension of “.git”
# git add .
This command adds a change in the working directory. It tells Git that you want to include updates to a particular file in the next commit.
#git commit –m “Initial commit of Django-sample-app”
It stores the current contents of the index in a new commit along with a log message from the user describing the changes.
#git push origin master
Use this command to push commits made on your local branch to a remote repository.
The git push command takes two arguments:
- Origin (is an alias on your system for a particular remote repository.)
- Master (is just the name of the default branch)
We usually run “git push origin master” to push our local changes to our online repository.
After completion of this process you should see your application on Bitbucket Repository
STEP 4 : Configuring Jenkins for CI
After successfully adding project to the Bitbucket its time to setup Jenkins for CI
Install and configure Jenkins with below plugins,
1. Docker build and publish plugin
2. Bitbucket plugin (Optional)
You can download and install plugins from Jenkins using the below mentioned path,
Manage Jenkins –> Manage Plugins –> Available –> Filter. Search for the name of the plugin
STEP 5 : Configure Source Code Management in Jenkins job
After successfully installation of these plugins, create a Jenkins job to fetch repository from Bitbucket, build application image using Dockerfile and then push it to the DockerHub.
- In Jenkins Job, first configure “Source Code Management” to fetch repository from Bitbucket server
Provide your repository URL of Bitbucket server with appropriate credentials
STEP 6 : Configuring Build Triggers
Now, bitbucket plugin can be seen under “Build Trigger”. The phrase “Build when change is pushed to Bitbucket” implies that whenever any user commits to Bitbucket or new files get added to repository, this plugin will do its job by triggering a build by activating it by selecting the check box.
Set Poll SCM to “15 * * * *”, This will set the frequency of Jenkins to a gap of 15 min so that it will regularly keep track of any new changes. This will help the user to stay up-to-date with the builds
STEP 7 : Configuring “Docker Build and Publish” plugin
Once you go to “Build” section, you should configure the “Docker Build and Publish” plugin as follows
Various fields in the above image are explained below:
- Repository Name : Name of your repository according to your DockerHub account
- Tag : To identify the latest image that we have created, give tag to each docker image. It will create a new image with new tag keeping old one as it is.
- Docker Host URI: In this case, Docker host is on the same machine where Jenkins is installed, hence Docker host URI field is empty
- Server credentials: Provide user’s credentials who has permission to run Docker commands and have permission to use Docker’s socket “/var/run/docker.sock”. We have provided permission to Jenkins’ user.
- Docker registry URL: Docker provide its registry URL as https://index.docker.io/v1/
- Registry credentials: Click “Add” to add the DockerHub account credentials.
STEP 8 : Jenkins job result
Build a project.
STEP 9 : Check Dockerhub account
Check your DockerHub account for new image
Conclusion
This configuration allows an user to create a jenkins Build for uploading a docker image on Dockerhub automatically. Using this methodology, a new image can be created from a Dockerfile and pushed to Dockerhub.
The post CI/CD Automation (part II) appeared first on DevOpsTech Solutions.
This post first appeared on Migrating XEN Virtual Machines To The AWS Cloud, please read the originial post: here