A Tale of Triumph and Tears
Have you ever had a time when you wrote some code on your developer machine and it ran perfectly fine. However, after a colleague pulled your changes and ran them locally on their machine they blew up in spectacular fashion?
While the dust of your shattered dreams gracefully descended from the mushroom cloud that bloomed before your very eyes you wondered: why me?
Well dear reader, it wasn’t you at all. Well maybe it was, the facts are yet to be corroborated. However! Equally likely is that it could have been your colleague’s Operating System, environment variables, installed (or not for that matter) dependencies, or more. Who knows?
The moral of this story, though, is that with the help of containerisation, mushrooms are off the menu; officially.
What is a Container?
A container is basically a self-contained application that can be run reliably on different environments. Containers run at the application level (like Visual studio, or notepad) and bundle your application (be it your own compiled source code or otherwise), its dependencies, environment settings and more into a single deployable/executable unit.
Instead of hosting its own instance of an operating system as a Virtual Machine would, a container functions as an abstraction over the operating system; sharing the operating system kernel with other running applications and containers on the machine.
This abstraction is the reason that containers are fast to start and are relatively small in size (in the tens of MBs), especially when compared to bulky and slow virtual machines (in the tens of GBs).
What is Docker Desktop?
Docker Desktop is an application that you install on your computer. It runs in the background (is visible in the system tray) and allows you to build and consume containerized applications. Docker takes a container image and runs it; the container-world equivalent of doubling click the .exe of your compiled source code. The detail of this process will be explored over the coming articles.
If you’d like to see the different pieces that are installed with Docker Desktop, follow this link for a great overview of the Docker Architecture from Docker themself! As is often the case with learning new things though, this theory isn’t critical for getting up and running with Docker containers. Therefore in Code Sloth style, so feel free to come back to it later, once you have a practical understanding of the technology!
Installing Docker Desktop
Installing Docker Desktop is really quite basic:
- Follow this link to head over to the Docker website and hit the download button.
- Follow the installation instructions for installing Docker Desktop on Windows, choosing your preferred method.
- After the install is complete, run Docker Desktop using the steps in the article. Docker should startup automatically when your machine boots up.
Running Containers on Windows
There are a couple of different flavours of containers to choose from.
Originally Docker containers were created to interface with Linux kernels. This causes a problem when trying to run them on a Windows machine, which has a Windows kernel that is architected in a fundamentally different way to Linux.
Linux Containers on Windows
In order to run a Linux container on windows you have two options:
- Hyper-V. This is a highly optimized version of a virtual machine. Each container has their own virtual machine and as a result has their own kernel. Given that virtual machines provide an abstraction over hardware, this means that Hyper-V gives containers hardware level isolation from other containers, as well as the hosting machine.
- WSL2. This allows you to run a Linux file system, command line, GUI apps etc directly alongside your Windows apps. While it uses the hyper-v architecture, WSL2 requires less resources to run than a virtual machine. Microsoft recommend using WSL2 over WSL1, except in these cases.
Why would a Windows user build Linux containers? To put it simply, it’s cheaper. When running a production workload in the cloud, it is almost always the case that Linux based hosting solutions are cheaper than Windows. Given that .Net Core, .Net6 and PowerShell all have multi-platform support, there’s really no reason not to go down this path.
Windows Server Containers on Windows
As the name suggests, Windows Server containers run on Windows require no virtualization. These should not be your go-to choice unless your legacy applications run .Net Framework.
Additional Considerations
While .Net Core code can be written to target a Linux environment, you must be careful. There are some things, such as time zone detection, that vary between operating systems. This is why having a standardised engineering workflow is important, otherwise you may find yourself programming environment specific checks into your solutions, which are less than ideal. Albeit these would likely be rare.
Where to From Here: A Fork in the Road
There are two ways that you can use the posts in this series.
Take a Journey on the Scenic Route
Follow along with each post in the Docker category series as you progressively understand the ins and outs of Docker and containers.
Sloth out a Solution
The second is to use these posts as a Code Sloth’s Docker cheat sheet for problem solving. Got a specific problem? Find a specific article to shortcut your way to success!
I hope you have a whale of a time! (Get it? It’s a pun on the Docker logo).
