Well, the above-mentioned anecdote is nothing but a summary of another day of the life of a developer of any organization using monolithic DevOps techniques and architecture. Here comes, docker/containerization to the rescue. In laymen terms, docker/containerization can be defined as a technique through which we bundle the application and its configuration in a closed box(images) such that the box has predefined ways in which it takes input, gives output and communicates to other containers(bundled applications). If you want to go into details about the core architecture and other advantages of docker here’s a good read.

THE PROBLEM

With evolving microservices architecture and different kinds of technology stacks and different kinds of the environment, there arose a few problems which needed to be solved.

1. Independent and faster build cycles for all the microservices.
2. Easy setup and replication of the production environment at the development stage.
3. Making the application and its configuration independent of the environment.
4. Easy Monitoring and independent scalability for different microservices.
5. Zero downtime deployment with continuous integration and continuous delivery.

THE APPROACH/SOLUTION

Upon exploring different tools like Travis CI, Code pipeline & Code Deploy ( AWS ), Jenkins, Docker swarm, Docker compose, Kubernetes, Amazon ECR and comparing on the basis of pricing, flexibility, Ease-to-setup, and popularity, we decided to go ahead with a stack involving docker, docker-compose, Jenkins and Amazon ECR.

STEP 1: Configuration

The first and foremost task was to configure how the applications and their configurations can be packaged, so as to make them independent of build or run environment. To achieve so, a Dockerfile was made which involved the commands to build a particular type of application and run them. Some of the typical examples of writing a dockerfile are provided here.

STEP 2: Packaging and CI/CD Pipeline

Using the Blue Ocean Jenkins plugin, CI/CD pipelines were made for different microservices which involved GitHub repositories as the source. This pipeline would involve 3 steps :

i. Pull: Trigger the pulling of new code from the Github repository.

ii. Build: Build the project according to the configurations of Dockerfile and pushing to Amazon ECR.

iii. Deploy: Pull the Docker Image from ECR on the server and deploy it using Docker Compose.

STEP 3: Zero downtime deployment by using Docker compose

Docker-compose is a tool for defining multiple Docker containers, their environment and there interaction with each other and the outer world and running them. The configurations are provided using a YAML file. It is used to pull the image from the ECR Repository and run them. The same Docker-compose file is used to deploy the entire set of applications as two different projects.

At the time of deployment, the last deployed project is identified and a new project is deployed using the newly pulled images on different ports and traffic is routed to new ports using Nginx reverse proxy. Through this process, the new application/image is deployed without having any downtime.

Conclusion/Future Prospects

As Mark Twain said, “Continuous improvement is better than delayed perfection”, and hence We tried to focus on the bare minimum of the problem.

Through containerizing the applications, using CI/CD pipeline and docker-compose we were able to achieve 60% faster (due to optimal use of docker caching mechanism) and independent builds, Fast and Easy replication of production environment, and zero downtime deployment. The future beholds the use of Kubernetes for easy orchestration and monitoring of containers and deploying the images on clusters. Stay tuned for the next dose of DevOps at townscript. Have a good day!