dvm is Docker 1.0 Ready
Back to the Blog Page

dvm is Docker 1.0 Ready

by Fletcher Nichol | Thursday, June 12, 2014

Earlier this week the first Docker conference was held in San Francisco where the big 1.0 Production Ready version of Docker was announced. As Heavy Water wasn’t able to make it out this time I thought a bit of good old fashioned hacking would be in order instead. Today I’m happy to announce the 0.6.0 release of dvm which runs boot2docker and Docker 1.0.0.

I thought I’d highlight a few of the changes and improvements that went into this release, so here we go. For a full change log, visit dvm’s release page. Installation and upgrade instructions can be found on dvm’s project site.

Docker 1.0

As previously mentioned, dvm is running boot2docker 1.0.0 which uses Docker 1.0.0 internally. This should give you access to the TLS auth API, new COPY Dockerfile instruction, new pause/unpause commands, and more. Oh right, and the shiny new official Docker IANA TCP port of 2375. If you haven’t been keeping up with Docker releases the past few months check out the Docker blog for the release notes.

Parallels Desktop 9 For Mac Support

Recently there has been increased interest in running dvm on Parallels Desktop and thanks to the generous help of the Parallels team this was an easy addition. To make this work, you’ll need to install Parallels Desktop 9 for Mac (license required) and the corresponding Vagrant plugin:

vagrant plugin install vagrant-parallels

And now run dvm with the appropriate Vagrant flag:

dvm up --provider=parallels

or export VAGRANT_DEFAULT_PROVIDER=parallels to make this your default.

Disabling Local Docker Port Forward

Previous versions of dvm forwarded the old Docker port (4243) to your local workstation but never directly used it which was due to behavior in the underlying boot2docker-vagrant-box project. This exposed a needless port, was bound to all interfaces by default, didn’t have autocorrect Vagrant logic enabled, and tended to collide with other Vagrant Docker virtual machines or even the CrashPlan software agent. Now this port forward is bound only to localhost and is disabled in dvm by default. In dvm’s world, you use the private network IP address for your DOCKER_HOST environment variable.

Vagrant 1.6.0+/VMware Fusion Gotcha

If you are running Vagrant 1.6.0 and up with the VMware Fusion provider, there is a good chance that dvm won’t boot properly. There is a configuration merging issue that is still outstanding and being tracked in mitchellh/boot2docker-vagrant-box#48 and mitchellh/vagrant#3996. My recommended workaround (sadly) is to downgrade to Vagrant 1.5.4 or use the Parallels or VirtualBox provider until this is resolved.

Again, Why dvm?

Lastly, you might be asking yourself, why keep dvm going as a project with boot2docker installation packages for the Mac and Windows platforms? There are 3 main reasons remaining:

  • dvm uses Vagrant which allows support for other virtualization solutions such as VMware Fusion/Workstation and Parallels in addition to VirtualBox. If using vanilla VirtualBox works for you and you’re running on the Mac or Windows, try the boot2docker installers.
  • dvm should work with non-Linux Unix distributions that support Vagrant, so you have an option if you’re using an Illumos-based distribution, FreeBSD, etc.
  • dvm relies on an internal private networked IP address for Docker communication which gives you access to all dynamic Docker port bindings. This feature is what makes working with the Test Kitchen Docker driver possible and easy to use.

Go Forth and Docker!

This has been a very inspiring week in the Docker community and I encourage everyone who has been waiting on a production ready Docker release to put some time aside and give it a spin. If dvm helps you in your journey, let me know!