Late last year, I had the priviledge of working with Brian Myburgh on some DevOps automation for ClubSpark. He set up a toolchain for us built upon Docker, which was able to quickly provide any Linux or Mac developer in the company with a full suite of tools for managing our infrastructure. Unfortunately for me, I’m primarily a Windows developer!

I recently spent some time setting up a new Windows development environment, and wanted to be able to utilize the same toolchain without requiring any massive changes to the supplied scripts. What follows is my journey on building a Windows development environment that was able to work with our toolchain without locking it to any single operating system.

In the end, there were 5 main hurdles to overcome:

1. Docker inside Hyper-V
2. Volume Mounts in Docker for Windows
3. Lack of native Makefile support on Windows
4. MinGW path mangling on Windows
5. Windows line endings

Docker inside Hyper-V

To simplify and isolate my development environment, I have often worked inside a VM which I configure with all the tools I need for development. This confers me a few advantages over installing all the tools directly onto my primary installation:

• It enables me to instantly “pause” my work when I’m done and resume later
• In the case of hardware failure, I can instantly move my development environment to a new machine
• It reduces the number of background services running when using the machine for other tasks, like gaming

Docker on windows leverages Microsoft’s Hyper-V hypervisor as the core virtualization platform. By default, Hyper-V is not configured to allow nested virtualization, as it can interfere with some of the features of Hyper-V.

Luckily, it’s fairly easy to enable nested virtualization. To do so, you first need to shut down the virtual machine on the physical host. You then need to run a single powershell command to enable nested virtualization.

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

When nested virtualization is enabled, you will be able to install Hyper-V on a guest operating system. It’s important to note, however, that while Hyper-V is running in the guest, the Dynamic Memory and Runtime Memory Resize features of Hyper-V are disabled, and your guest will use the full amount of memory available to it at all times.

There are also some networking implications to consider, but for the most part these can be ignored. To read more, you can check the Microsoft Article.

Volume Mounts in Docker on Windows

Once we’ve enabled Hyper-V inside our VM, we now need to install Docker. Docker for Windows provides a really easy to use installer that supports Docker, Kubernetes, and has a bunch of neat features. Unfortunately, volume mounts in the stable branch were not working correctly when operating in the context of an Azure AD user at the time of writing. After much searching, I managed to come across a github issue which outlined the error, and revealed that the latest Docker for Windows Edge Release has resolved the issue in version 2.1.7.0

Add Makefile Support

When looking to add Makefile support to my environment, I wanted to avoid any large installations. Ideally I wanted a single make.exe binary that could be bundled or quickly downloaded by a powershell script or similar. The easy-path was to install a full linux/windows subsystem, like Cygwin, or Microsoft’s WSL solutions, but I didn’t like how heavy those solutions were.

Eventually I found GnuWin32 which had the binaries I wanted, with minimal dependencies. I already had git for windows installed, which I thought was a common enough dependency given that our solutions were all stored in GitHub. This ended up being important, as it was reduced the number of additional dependencies needed. The steps I followed to get make working were:

1. Browse to GnuWin32 Make for Windows
2. Download the GnuWin32 Make Binaries
3. Download the GnuWin32 Make Dependencies
4. Extract all of these into a tools folder, e.g. c:\Tools\make
5. Add the Tools\make to my PATH
6. Add the Git\usr\bin directory to my PATH

At this stage, I was able to run the simple Makefile in our toolchain and correctly receive the help output.

Managing MinGW Path Mangling

Once I had make running, I immediately ran into hurdles as the volume mounts used in our toolchain were failing in Windows. Initial investigation revealed that this wasn’t as simple as a straight difference between Unix and Windows file pathing. Running the docker commands manually worked fine, but placing those same commands inside a Makefile saw the paths mangled without warning.

It turns out that this was an edgecase with the way the MinGW MYSYS system does Posix path conversions. When used as part of a docker command, the syntax of the commands triggered different heuristics, resulting in mangled paths.

In the end, I found the fix on StackOverflow, and it only required me to set an additional set of environment variables to ensure the MYSYS system didn’t mangle my docker paths.

MSYS_NO_PATHCONV=1
MSYS2_ARG_CONV_EXC="*"

Windows Line Endings

Most Windows-based git clients offer the ability to automatically translate line endings upon checkout and checkin. This helps reduce unnecessary merge commits when people from different platforms work on the same files. Unfortunately, the Linux containers that we use in our toolchains don’t like Windows-style line endings in the shell scripts that we run.

To resolve this, initially I tried adding a dos2unix step into our Dockerfile, but this only worked in some scenarios, as one of the advantages of the toolchain we had set up was the ability to actively work on our files from both the Windows system, and the Linux containers.

Instead, I resorted to simply adding a .gitattributes file which explicitly tells git to make sure that all shell scripts in the solution are checked out with Linux line endings.

# Prevent bash files from getting broken by windows checkout
*.sh text eol=lf 
*.env text eol=lf 

Results

When all this is put together, we can run our Makefiles natively on Windows