Setting up a SQL Server Development Environment with Docker Containers - Part 1

Published on Thursday, April 16, 2020

Part 1 - Introduction

Prologue

I recently received a new work machine and decided that I no longer wanted any bare metal database installs on my system. I'd prefer not to even have any local VMs. My new approach will be purely Azure VMs, plus local containers.

What are Docker Containers anyway?

From the Docker website:

A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings.

ContainerImage

So about those 5 VMs on your machine that are taking a giant amount of space?

  • Do you really need 5 OS installations for that?
  • How much RAM are we wasting on OS overhead?
  • Wouldn't it be great if all 5 could share the same resources for the OS?

Docker Model vs VM Model ContainerAndVM

In short, VMs virtualize hardware, and then we can install our software and dependencies on those VMs. Docker uses a difference approach. It virualizes software. Specifically, it virtualizes the OS. Docker Container images then define instructions for loading dependencies and software for a container. Those images can be instantiated at runtime to create immutable container instance.

Not only are containers very lightweight compared to VMs, but a container also contains its dependencies, eliminating the common problem of software having different runtime experiences on different machines. "It worked on my machine?" - no more. When moving a container from one container host to another of the same OS kernel, it should always work because all dependencies are contained within the container.

Continue this series in Part 2 - The Basics