Best Practices, Use Cases, Tutorials
We had a very interesting discussion with a client yesterday about the use of Docker and where it fits within their environment. The client’s representative was pushing back on us for using Docker and, as always, I enjoyed the constructive argument. As it turned out, we pretty much fought to a conclusion that Docker does have some clear advantages in an Dev environment. Our debate challenged me to crystallize my thoughts and to clearly articulate why we use Docker at Flux7, hence, this article.
The app under consideration includes Ruby on Rails with a large code base, as well as Nginx, Apache, MySQL, Memcached and Redis. The site is entirely AWS based with VPCs and subnets. For our client, we used Chef to set up DevOps, Zabbix for monitoring, and LogStash for logging. So the question was how exactly to best optimize developer flow? Not surprisingly, the solution I proposed was Docker. What follows are the results of our discussion.
[Tweet “The Great Debate: Should you use #Docker or not?”]
1. Developer set up as identically to production as possible.
2. A complete flow from developer laptop to staging and production.
The Question At Hand
Is it best to use Docker to develop complex websites?
That question led to a very fruitful discussion with Steven and I thank him for the excellent push back that led me to crystallize four reasons for using Docker in a developer environment:
1. Performance Overhead
It’s difficult to run more Docker containers on my laptop than VMs. Steven and I agreed that a local setup needs to behave like one entity-per-tier, similar to production, instead of having all laptop software installed under one IP. So the question was whether to use 6 VMs or 6 containers. The downside to using 6 VMs was that my laptop would tank. Steven rightly stated that VirtualBox, which I use, is not the best VM manager, so I needed VMWare or Parallels. I admitted that I need to do more research. It may not be deal breaker argument in this case but it was nuetral between Docker and VMs.
2. Fast Boot
Docker provides ability to create/delete a clean environment quickly. In our experience, using Docker makes a big difference when developing Chef recipes in which a clean environment must be started for every failure. However, in regular Ror development, a clean slate is not mandatory hence Fast boot is convenient but not a must-have for this scenario. I did make a strong case though that DevOps and cookbooks can be debugged a lot more efficiently with Docker and Steven agreed.
3. Small Container Sizes and ability to diff containers
This reason did strike a chord with Steven immediately. While it’s nearly impossible to share a VM with a remote teammate, it’s entirely possible to share a container due to the Docker registry. Docker scored this point due to its ability to pull only incremental changes. The ability to diff two containers is indeed a big selling point and the argument completely turned at this point. (Update: Fyi, we have finally decided to use Docker for this project!).
Why is this ability to move containers and diff them so crucial: see our blog post on Docker’s use at Flux to host this website you are on. Having learned even more since I wrote this post, I would call this a deal-breaker argument all by itself.
4. Ability to run a container in AWS, As Well As Cross Cloud.
You can’t run VMware in AWS, but Docker offers the ability to use the same container in AWS. Furthermore, Docker can use the same container cross cloud, which is indeed a win. This is inarguably a huge plus for any project and there was not even an argument against it.
The Result of Our Discussion
We are using Docker!
For those considering Docker, here are three arguments for Docker that are clear benefits and cannot be argued against:
A) Ability to easily diff containers. It improves debugging, allows faster sharing of the environment, and quicker deployments. This is a big plus and there aren’t any competing solutions.
B) Ability to debug DevOps (like chef recipes) locally without having to pay the penalty of the slow boot of a VM or AWS instance.
C) Ability to put the containers directly from Dev or QA on to AWS.