Nowadays CI or Conitnous Integration is being implemented in almost all IT companies. Many of the DevOps work’s are in related to the CI. The common scenario is, Developers push the codes to the GIT/SVN repo and triggers jenkins to perform tests and sometimes packaging, and if it’s a fuly automated system the new changes are deployed to the staging. And the QA team takes over the testing part. But when you are in small team, all these has to be achieved with the minimal team. So before the new change is completely pushed to staging, i decided to have a simple testing of all the components quickly. I read about blogs where many DevOps engineers spins up new instances like a full replica of their entire architecture and performs the new code deployment and load test on this new cluster and if all the components are behaving properly with the new code change, it’s then further deployed to Staging for next level of full scale QA.
Though the above step seems to be interesting, i didn’t want to waste up resources by spinnig up a new set of instances each time. Being a hardcore Docker fan, i decided to replace the instance lauch iwth Docker containers. So instead of launching ne instances, Jenkins will launch new Docker containers with SDN(Software Defined Network). Below is simple architecture diagram of my new design.
So the work flow goes like this,
1) Developers pushes the new code changes along with the new Tag to the corresponding Repositories.
2) Github webhook then triggers jenkins to start the Build jobs.
3) Jenkins performs the build and if the build succeeds, jenkins triggers Debian pacakging for the application.
4) Once the packaging is completed, Jenkins will trigger Docker image creation for the corresponding application using the newly build packages.
5) Once the image build is completed, Jenkins uses Docker Compose to build our Virtual clusters which is an exact replica of our Prod/Staging.
6) Once the cluster is up, we perform automated testing of all our components and makes sure that the components are behaving normally with the new code changes.
Now once the test results are normal, we can initiate the code deployment to staging and can start the full scale QA.
By using Docker, i was able to reduce the resource usage. All these containers are running on a Single M3.Medium box. Sice i’m concentrating more on the components working part and not on the load test side, with this smaller box i was able to achieve my results properly.
A bit about
docker-compose. I’m using
docker-compose for managing the docker cluster. Compose is a tool for defining and running complex applications with Docker. With Compose, we can define a multi-container application in a single file, then spin our applications up in a single command which does everything that needs to be done to get it running. Below is my docker-compose yml file content.
web: image: web:latest links: - redis ports: - "8080:80" environment: - ENV1 - ENV2 redis: image: my_redis:latest ports: - "172.16.16.17:6379:6379" backend: image: my_backend:latest net: "host"
From the initial test results, i was very much satisfied. Now i’m planning to extend this setup to next level including a fully automated load test.