An Introduction to Docker for Mac

Recently out of private beta, Docker's new native applications aim to replace the current methods for running Docker on Windows and Mac, creating a better experience for developers using those platforms.

For the previous solution, Docker Toolbox used VirtualBox to create a small Linux virtual machine that hosted your images and containers. It worked pretty well but could be unreliable at times and required workarounds that sometimes resulted in unexpected outcomes or not working at all.

Docker for Mac removes the dependency on VirtualBox and instead uses virtualization technology that is already part of Mac OS X, HyperVisor. Docker for Windows uses Microsoft's virtualization technology, Hyper-V. These changes aim to make your Docker containers run faster than before, take up less disk space, and fit better into your operating system.

I am a Mac user, so I'll be focusing on the Mac version of Docker's new application, but I'll highlight any significant differences with the Windows version.

Download the native application for your platform here.

Successive updates to the application have made the installation process and the resulting application increasingly "more native" and better integrated with the operating system. Because the application uses newer technologies only available in newer machines and OS versions, it has minimum requirements, which are:

• A 2010 or newer model, with Intel's hardware support for memory management unit (MMU) virtualization

• OS X 10.10.3 Yosemite or newer, as the Hypervisor framework used is available in Yosemite onwards

• At least 4GB of RAM

• VirtualBox prior to version 4.3.30 must not be installed as it will cause issues with Docker for Mac

• 64bit Windows 10

If you are using Docker Toolbox, your images and containers can typically coexist together. This is thanks to Docker Toolbox using VirtualBox to host images and containers, and installing command line tools to more "Linux" path locations. Both Docker for Mac and Windows are fully native to the host platform and install everything into locations you would expect (e.g., The Applications folder), only using symlinks to make certain tools accessible on the command line.

When you first run the Docker application, it will check your system for compatibility and requirements, show a welcome screen, and then start the Docker process. Your main interaction with the Docker application will be via a menu bar item: to stop and start the Docker process, open Kitematic for GUI access to your containers, find documentation, and access preferences.

The General pane has settings for configuring the specs of the virtual machine, updates, and excluding the virtual machine from backups (Mac only). This is a simple but useful feature to have, as it can end up being a large file.

Many enterprise users of Docker use their own registries for custom images. The advanced settings pane lets you define custom registries to search for images that you trust.

The application should automatically detect any HTTP(s) proxy settings you have at an operating system level, but you can check them here. While not a part of this preference pane, it will also automatically detect any VPN settings you have, allowing access to any containers running within it.

While sharing volumes between Docker containers and the host operating system was possible with Docker Toolbox, it could be slow and suffer permissions issues. Docker for Mac uses a new file system created by Docker called "osxfs." I can't find much detail on the new file system, but there is some information here.

You can add or remove share local paths to share with containers using the + and - buttons, but these paths shouldn't overlap (e.g., not Users and Users/homefolder).

Little of the process for using Docker has changed, except that it requires fewer steps. For example, with the application running, you can use Kitematic or the command line to download and start images as containers. Here's the "Hello World" image running in Kitematic:

Notice something else cool there? No more custom IP addresses to remember! All your Docker containers now run on localhost and will be port mapped to the address.

Other Docker commands such as docker-compose and docker-machine work, but for Machine (and thus Swarm) you will need to define a non-native driver. This means you can manage Docker Machine from your Mac, but the machines will still be hosted elsewhere and still need to be managed by the traditional eval $(docker-machine env default) commands.

I personally use Docker for rapid testing and prototyping ideas, and so rarely take my containers off my Mac. Of course, few people will use Docker with Mac or Windows in production, so many might ask if there is much point in the Docker team making native applications for these platforms.

Still, a lot of developers will be using these platforms during development, and I for one thank the Docker team for making my experience feel much more friendly and accessible. The applications are still considered betas, and the team welcomes any feedback you have to help them improve, so if you also appreciate the effort made, then help them out.