5 Useful Docker Tips and Tricks on Windows 18


UPDATED: Docker deprecates the Boot2Docker command line in favor of Docker Machine. All Tips and Tricks were updated to reflect this change.

1. Edit etc/hosts

Your Docker host on Windows is usually accessible either on the IP address 192.168.59.103 (older Docker versions) or 192.168.99.101 (newer Docker versions). As you can see, not so easy to remember.

You can add a new record to your etc/hosts file (in Windows) to create a local DNS name for your Docker VM (Boot2Docker), e.g.:

192.168.59.103 docker
192.168.99.101 docker

which makes your life easier, see Figure 1.

2015-07-10 14_17_18-GlassFish Server - Server Running

Figure 1: Example of a new record in etc/hosts

NOTE: If you do not know, how to add a new record to your etc/hosts file, check this tutorial.

2. Configure your Docker Machine (old Boot2Docker) inside Virtual Box

The installation process of Docker on Windows automatically creates a new lightweight virtual machine (VM of Boot2Docker) inside VirtualBox. If you do not know what I mean, visit my another post about Docker architecture on Windows first.

The used VirtualBox is completely hidden behind Docker Machine API and you usually do not need to know anymore.

Sometimes you need more e.g.:

  • Allocate more memory or CPUs to your VM,
  • change a network connectivity either to your Windows or to the internet,
  • raw backup your containers,
  • or simply know where all data related to containers are saved.

Basically, you have two options.

  1. You can use the boot2docker config command to generate a configuration file which you can edit and set a lot of parameters related to the VM with Boot2Docker – no more available via Docker Machine.
  2. The Docker VM is a normal VM created inside VirtualBox and you are able to change all its settings in the Oracle VM VirtualBox Manager (as I said, memory, CPUs, Network, Storages etc.), see Figure 2.
2015-07-10 13_33_12-Oracle VM VirtualBox Správce

Figure 2: VirtualBox interface

3. Access Windows directories directly from any Docker container

Users on Windows have one more virtualization layer (VirtualBox) between their running containers inside Docker VM (Boot2Docker) and Windows. So you cannot simply mount your Windows directory to your container inside Docker.

The required setting consists of two steps:

  • Mount a Windows directory as a folder inside Docker VM
  • Mount that folder to any container

Mount a Windows directory as a folder inside Docker VM

At first you need to create a new Shared Folder in the Virtual Box setting. See Figure 3.

2015-07-10 14_38_38-boot2docker-vm - Settings

Figure 3: Shared Folders setting in Virtual Box

Then you need to mount this folder inside Docker VM with this command:

$ mount -t vboxsf -o uid=1000,gid=50 your-shared-folder-name /existing/location/in/docker/VM

In our case, the command looks like this:

$ mount -t vboxsf -o uid=1000,gid=50 docker /home/docker/data

NOTE: The data folder needs to exist before any mounting, i.e. call before: mkdir -p /home/docker/data.

TIP: If you add this mount command to a profile file (see the following trick), your Windows directories will be accessible automatically after startup inside of your Docker VM.

Mount that folder to any container

This task could be done with a standard volume parameter -v from the docker run command.

docker run -it -v /home/docker/data:/data ubuntu bash

Now my Windows directory (D:\development\docker) is accessible directly inside a new ubuntu container.

4. Permanent changes inside Docker VM

The Docker VM itself is a read-only image used to boot your VM. All permanent data are stored in a Virtual Machine Disk connected and mounted to your VM (see Figure 1 and the yellow box).

Basically, there are two main folders:

/mnt/sda1/var/lib/boot2docker
/mnt/sda1/var/lib/docker

The first one contains permanent data related to Docker VM (e.g. a configuration of docker’s profile, ssh setting etc.)

The second one is related to your downloaded/created images, containers etc.

The boot2docker folder contains a specific file with name profile where you can add new entries to be run immediately after any system boot before the daemon starts, e.g.:

export HTTP_PROXY=http://ip:port
export HTTPS_PROXY=http://ip:port
mkdir -p /home/docker/data
mount -t vboxsf -o uid=1000,gid=50 docker /home/docker/data

5. Connect to Docker VM via SSH

You have two options how to control your Docker on Windows:

  • Using a Windows Docker client, i.e. using a Windows Command Line Prompt (cmd.exe) or using PowerShell (powershell.exe),
  • using a native Docker client inside your Docker VM.

I prefer the second option because I used to use a Linux shell.

How to connect to your Docker VM with SSH?

Your Docker VM is listening on port 22, so you can directly connect to your running VM via SSH (using username: docker, password: tcuser).

If you want to use your public key without any password entry, add your public key to .ssh/authorized_keys.

NOTE: You should not edit directly this file inside docker’s home folder (/home/docker/.ssh/authorized_keys). The whole docker’s home folder is not saved on the permanent storage and will be deleted during a next restart.

Instead of that, edit authorized_keys file inside an existing archive userdata.tar (located in /mnt/sda1/var/lib/boot2docker/) which will be automatically untared into docker’s home directory during each startup.

Share this:
  • J R

    This virtual machine hackery for docker on Windows needs to be flushed down the toilet. When the hell are they going to port it natively? Since you can’t really run a virtual machine on a virtual machine, this “solution” they’ve come up with only works on physical hardware, which NOBODY has access to any more. This whole approach is a stupid hack.

    • I had been really amazed by the Docker engine until I installed it on Windows.
      I don’t like any hidden layers which may cause some unpredictable behaviour and problems.
      On the other hand, Docker on Windows is not for a production launch (according to Docker’s authors) and it is suitable for application development only.

    • Jasmine Hegman

      The hackery is boot2docker in general, and it is how Mac users have to user Docker too. Please note that containers are more lightweight than VMs themselves.

      Using this technique, you can totally run your own Linux VM and install Docker on it and connect manually, on Windows or Mac, and it works pretty much as described in this article.

      Eventually, all three will have the client and engine runtimes natively but until then this stupid hack is at the same time a really cool way to have the tech now. The whole point of this article is how to make it feel a little more native and less hacky now. I’m honestly not sure there is any other way. Also to be clear, this is primarily to be able to use and work with it, not to deploy production servers with.. in those cases you are better off using a thin OS that is designed to launch and run containers like any of the public cloud providers do anyway – whether on raw metal or in a virtualized machines. And that’s what containers are for, run on your machine even behind a vm and it will run the same way on those cloud machines. 🙂

      • J R

        I don’t disagree with anything you said, just the fact that it completely ignores “boots on the ground reality” for a HUGE chunk of the industry. Any shop that standardized on Microsoft is effectively without Docker capability, and boot2docker is a POS hack that gives you *the illusion* of hope, effectively wasting a TON of your time only to find that it’s basically useless on anything other than physical hardware. Who the heck runs Windows Server on real hardware in 2015??? The Docker team needs to port the container management to Windows natively, or stop talking about it like containerization is cross platform. It’s not. I don’t get to say “Windows runs on z/OS (mainframe)” just because it’s technically possible to bring up SUSE on z/OS and then run Windows apps on Wine. That’s effectively what boot2docker is, and it’s a complete waste of someone’s time and talent (including those who try it out).

        • Jasmine Hegman

          You are right, what the hype suggests is not here yet. The Docker project itself I don’t think claims much of the hype, just that it is possible and they are indeed working towards it (see issue trackers for the diff projects on github, e.g. docker/docker and docker/machine) while the business side of things and journalists just hear buzzwords, money, promises and over-selling. [1]

          It’s definitely frustrating to hear things about how it’s run anywhere only to find it’s run anywhere under these conditions. I ran into this with the 32bit situation. Although many don’t think so, Docker supports it just fine, but 32bit containers aren’t compatible with 64bit ones so most of the registry is rendered useless, and to make matters worse the registry wasnt really designed to distinguish the two anyway. We have labels now, which could help, but overall 32-bit docker users are part of a small and dwindling sub-community of docker users supporting 32 bit images. There’s just not enough demand, esp. considering how simple things are if we just pretend everyone is 64 bit, and for the majority that works (and will probably work going forward). [2] if you are interested at all in 32bit.

          On the plus side though, any technology that goes this deep into the stack is going to take time to roll out to lots of O/Ss, even with vendor assistance, so it can be argued it is a matter of time and effort. It’s not like they aren’t working towards full native client and engine, but it’s definitely not here yet. The hacks do let us experience what it will be like at least to some extent though, so I don’t think it’s a waste of time or talent, at the very least it’s what’s convincing people and causing all the hysteria to begin with! But it’s also not what the hooplah suggests.

          I really don’t know anything good to say to help you other than keep an eye on things but wait until after the native Windows Docker Engine is released (I say after so there’s a bit of time to let others kink the bugs out). Until then, whatever setup you have, if working, will likely keep working until that day.

          I think the people who gain the most benefit now are those that are deploying using cloud services that already have propertiary image formats like Amazon or DigitalOcean or Linode where it’s generally linux based and already native docker engine friendly. For those users, boot2docker’s approach actually works great because it lets them develop anywhere and things DO stay consistent. When they launch, it performs well as there is no virtualization on the remote servers. Now the idea is docker machine will let you work on those remote servers’ docker engines as if they were locally. In that sense the boot2docker approach is very elegant as it fits that scheme.

          For you I am thinking there’s few merits in adopting Docker right now and Hyper-V or something will be more advantageous for you in the short term.

          [1] https://docs.docker.com/installation/windows/ – Note the first paragraph in docs: “The Docker Engine uses Linux-specific kernel features, so to run it on Windows we need to use a lightweight virtual machine (VM).” I think it’s dumb that no link to the progress of the Windows Docker Engine is there, but articles like these imply that it is and is in development: http://www.techradar.com/us/news/software/operating-systems/docker-on-windows-server-how-will-it-work–1275009 http://www.infoworld.com/article/2907642/application-virtualization/microsoft-docker-for-windows-server-is-right-around-the-corner.html – maybe the Azure blog is the better place to watch.
          [2] https://github.com/docker-32bit/ubuntu

    • Ron

      JR, give it a rest. This is great info for people who want to start playing around with Docker on Windows. I found it very helpful.

  • Pingback: 5 Useful Docker Tip and Tricks on Windows | Doc...()

  • For the point 5. Isn’t it enough to run “boot2docker ssh” command to simply connect to Boot2docker VM?

    • Yes, you can but still be using a Linux shell inside the Windows cmd.exe, which has actually very limited functionality. I prefer and daily use the Putty SSH client (not only for Docker).
      All points in this post are about the fact, that the Docker on Windows is actually a running Linux machine and you are not limited to boot2docker commands inside your cmd.exe/powershell.exe.

      • Good point. Thank you for the great article by the way!

  • The issue with VMs will go away once we can run Docker natively on Windows. WinDocks recently announced Docker Engine support on Windows Server 2012, which includes the ability to run the docker client and Docker engine without messing with VMs, and some coolness with SQL Server running in a container. Check it out at http://www.windocks.com
    windocks.com

  • Pingback: Docker for Windows安装与Linux PHP开发环境搭建(二)-IT大道()

  • Guilherme Ando

    that’s a great article!
    I’m having some problems to setup the shared folder in the docker machine. I’m using Windows and when I tried run the mount command in the Docker Quickstart Terminal I’ve got this error:
    mount: unknown option — t
    Try `mount –help’ for more information.
    I also don’t have permissions to create folders or to run sudo

    By using Putty, I have managed to run the command but now I have another problem: I’m using docker-compose to build and run my containers but docker-compose is available when connecting using Putty only when using Docker Quickstart Terminal.
    Do you have a idea to solve this problem?

    • Hi Guilherme,
      I do not use the docker compose command on Windows, but the last status I have found, that the docker compose is not avaiable inside boot2docker. You have to use your Windows docker compose client, which runs only inside your Docker Quick Start terminal and connects to boot2docker.
      I have found some tutorials how to install docker compose inside boot2docker, but is it not clear whether it runs it properly, so I cannot recommend it to you.

  • denofgeek@docbill.info

    There are several tricks in Linux, I would love to figure out how to do from Windows. One is of course –net=host . This is very useful to run services on the containers and not have them hidden by the NAT. There is also just simple port redirecting. Yet another is hosting X11 applications. I think all of these can be done, I just haven’t had a chance to play around to find out how to do so. Ultimately the goal is to be able to run any container on any of my machines regardless of hosting OS.

    As it is, docker pretty obsoletes everything I used to use colinux for. Sadly, it does not also obsolete cygwin, but it compliments it.

  • Fabien

    Thanks for the volume tips…. Strange i don’t need to do that on my mac…. but on windows.. i need too…. Anther question, as i am using docker-compose file to do so thing automatically, i don’t find if they are a way to don”t do the same action depending the os host…. For example on my mac os x : “volumes : ./src:/usr/django/app” is ok. But on windows i need to do “volumes : /home/docker/src:/usr/djago/app”…. A ifdef of somethin like that is available from doccker compose file ?

  • Pingback: Development version of WordPress on Windows 10 | drkane.co.uk()