At Flux7 we are very interested in Docker as a technology and the new capabilities it can add to the DevOps world. To further explore what Docker can do in the hands of brilliant programmers we started a Meetup in Austin to discuss Docker.
March 13th, 2014 was the second Docker Meetup we’ve had, where we discussed how Docker can be used to improve developer productivity flows. Our CEO Aater Suleman opened the talk with a Docker tutorial. Followed by Ken Demarest the CTO and cofounder of AppSoma who provided an architecture level discussion on how Docker works in their flow. Finally, Aater presented on our own implementation of developer workflows using Docker in conjunction with Chef.
The tutorial started with the explanation of Docker architecture as a low-overhead process isolation mechanism mimicking a VM. Aater explained how a Dockerfile works and some of the most common commands including diff’ing two containers and versioning of containers. He also mentioned some cool tricks one of which was to debug in Docker first and then move to the actual environment, when debugging a Chef recipe,
Ken’s presentation pointed out that the ability to have a reproducible environment is not limited to the world of programming. In fact it is one of the biggest issues with the scientific method. While the scientific method depends on peer review of data and experimental methodology, the truth is many scientific results are never validated because the experiments cannot be reproduced by other researchers. So the ideas behind Docker, of creating reproducible environments, will be the cornerstone of human knowledge.
He delved into the ‘Why Docker should not be thought of as a VM’ point. It is too light-weight to be considered a VM. It should just be considered as an abstraction layer that would be added to our current layer of operating systems, libraries, compilers, etc. He also went over workarounds for some of the issues currently faced while using Docker.
Aater presented Flux7’s reference architecture that we have implemented for several clients and also used for our internal purposes. When setting up a productive developer environment, we have two goals. The first is to make the write, build, test loop for the developer as short as possible. The second is to make sure we catch as many issues in this fast loop by ensuring the environment is as close to production as possible. We want the developer’s run loop to be as fast as possible because developer productivity is extremely sensitive to even the smallest interruptions and directly translates into loss in productivity. This loss in productivity costs a company money and increases time to market.
Figure 1: An example developer workflow with continuous integration and Jenkins showing the various loops in the development process
We have already setup configuration management for our clients using Chef and Puppet. When creating the developer environment we use these Chef/Puppet scripts to create separate containers for each service in the system. This way we can emulate the distributed nature of the application in the developer’s local machine. In addition we reduce the bring up of a new employee to run a single script that checks out the repository, checks out a VM using Vagrant for the developer and launches the Docker containers.
Figure 2: Docker running the different tiers of the application in separate containers
If you are intrigued by Docker and want to find out more about it please contact us at firstname.lastname@example.org. We are also open to discussions on a dev workflow similar to what is presented in this article using Jenkins, Vagrant, Chef, Puppet and Docker.