We decided that since we are attempting to make waves internally we should also use a product that is currently making waves throughout the industry: so we chose Docker.
Why Docker?
Aside from the 1000s of use cases, we discovered our own specific use cases for Docker.
- A Clean Environment
- Using a clean environment, each deployment allowed for us to ensure all components installed cleanly and that all expected pieces were in place. Early on in our Docker deployment, we discovered a conflict when installing the RPMs for our workers(irc-notify, email notify, func) that they were all attempting to overwrite a file that was created by the re-worker(library) RPM. The clean environment also helped us QA the re-rest component which required an expected playbook schema file. Without a clean environment, an engineer would be required to manually delete the file, install the rpm, and test for successful placement.
- Portability
- The initial docker deployment was actually created on my laptop inside a RHEL7 VM. I was then able to copy the Dockerfile and configuration directories straight to AWS, which created our QA Environment.
- Using git, anyone on our team can pull down the exact copy of a container and perform testing or work on any potential enhancements.
- Disaster Recovery
- We have stored all configurations and Dockerfiles in git. We have dramatically reduced the amount of time required to re-deploy our environment because the entire setup is defined within the Dockerfile.
- Quick Deployment
- A deployment of our re-rest(API) component using Docker takes 1 minute and 5 seconds. We had 11 bug fixes or enhancements that required a rebuild and an average of 20 re-deployments per component that ranged from configuring volumes for logging and configurations to creating a fix to the irc-notify component.
- A re-design of our Development Environment was performed in less than a day. Since it is a recommended practice to have all environments as similar as possible, we were able to take our QA deployment and re-factor the configurations files which created our development docker environment. We will be able to follow the same exact steps on stage and prod which will allow us to have two new environments in less than a day.
It would have been much more time-consuming to perform some of the actions listed above without the ability to use containers. We look forward to future iterations of the Release Engine product and to utilize a container management product to scale out our deployment.
Not only did the Inception team meet the Proof of Concept date, we accomplished it using RHEL7 and Docker.