Menu
Apr 18, 2017 - TL;DR; This post focuses on the usage of Docker for Mac 17.04 (edge. There are everything from full fledged alternative docker-machine. Also, unlike Docker for Mac, you cannot run any version of VirtualBox, VMWare or any other Type 2 hypervisor along with Docker for Windows. That’s because Docker for Windows uses Hyper-V under the hood which is a Type 1 hypervisor.
“But it works on my machine!” That is an excuse too often overheard in conversations between developers and operations teams. Even with sophisticated tooling, virtually unlimited computing capacity in the cloud, and advanced continuous integration workflows, the differences between developing applications locally and running them in production remains a persistent source of bugs and other problems. Dev and ops teams often turn to virtual machines, pre-built images, and/or configuration management systems like and to achieve better parity with Linux-based production environments and Mac or Windows development environments. All those approaches can help, but the problems can still persist. Fortunately, the new offers an opportunity to create a more resilient local environment that better mirrors production. MacOS and Windows have traditionally not supported the Linux-based container technology that powers Docker, but the latest release of Docker for Mac and Windows now makes it easier to get started creating and running containers in those environments with less overhead.
Let’s put a simple Node.js application in a Docker container as an example. Less fragile developer environments with Docker containers Developer workstations are fragile. Upgrading the operating system, botched package installs, conflicting dependencies, and the need to use multiple programming language runtimes remains a persistent source of frustration for developers.
Many language-specific tools have been built to manage this complexity, including for Python, for Ruby, and for Java. Docker, however, presents an elegant new alternative. Containers, like virtual machines, offer a way to isolate the complex dependencies applications require from the host operating system and other applications. Unlike VMs, containers are less resource intensive and usually take only seconds to start. Docker became a developer darling by combining Linux container technology with a specialized file system and command-line interface that also runs on Mac and Windows with the help of a Linux virtual machine. The additional requirements needed to run Docker on non-Linux environments have been simplified in the latest beta release of Docker’s software, making it easier to work with. Once installed, Docker images, often available for popular open-source projects from the, are used to instantiate running containers that execute application code.
(Understanding the difference between a container and image is particularly important—more information is available on the.).
For about two years, I’ve wanted to use for local development. Hypothetically, it offers all the benefits of virtualized development environments like (stable, re-creatable, isolated, etc.) but requires fewer resources. Working at a consultancy, sometimes I need to switch back and forth between multiple projects in a day. Spinning a full VM up and down can take a while. Alternatively, running two or more virtual machines at once can eat up all of my computer’s resources.
While I’d been interested in Docker for a while, I hadn’t had the time and energy to really dive into it. Then I went to DockerCon this April, which finally gave me enough momentum to figure out how to integrate it into my development workflow. Sharing is Caring (About File IO Speed) I suspected—correctly—that Docker would fall prey to some of the same shortcomings as Vagrant. Specifically, I am thinking of the speed of shared volumes.
Generally speaking, sharing files between MacOS and a virtual OS on a hypervisor breaks down when too many reads or writes are required in a short amount of time. This may be due to running asset pipelines like those of or that generate tons of temporary files. Most sharing systems (, NFS) do not support ignoring subdirectories. That wouldn’t be so bad, except that many framework tools do not let you configure the location of dependencies and temp directories. I’m looking at you, Ember. What’s a Developer to Do?
Hi Lucas, Thanks for the links. Those seem like good options for many use cases. If I recall correctly, nfs sharing had decent performance for the Rails pipeline but choked on Ember’s build pipeline. It’s possible the second option you presented would fix this, though, since the files “live” on the docker machine / VirtualBox VM. That said, one of my other goals was to (semi)-seamlessly transition back to standard Docker for Mac volumes, if and when they fix their speed issues. My assumption is that Docker will prioritize Docker For Mac as the preferred/default way to develop on a Mac, versus using a standalone VM as your docker machine. So I’m betting on Docker for Mac long-term.
Consequently, I like docker-sync in that getting back to “vanilla” Docker for Mac is as simple as tweaking the volumes in docker-compose.yml and dropping docker-sync.yml. And I do pretty much use docker-compose for everything, though I can see how docker-sync would be much less nice to use without it.