There are already numerous, excellent resources out there that cover the concepts of containers and Docker thoroughly. You can find recommendations under further reading. As such, this document will only cover a brief overview of the topic. More importantly, we'll then see how container technology fits in with Sitecore development.
Introduction to containers and Docker
By now, you've likely heard the buzz surrounding containers in the software development world, and how Sitecore now provides images. This isn't something new, but it is relatively new to Windows, and certainly new to Sitecore.
What are containers?
Containers are an executable unit of software in which code is packaged (see image), along with its libraries and dependencies, in common ways so that it can be run anywhere - whether it be on a developers' workstation, on-prem servers, or the cloud - and deployed easily and consistently, regardless of the target environment.
Containerization of an application provides a clean separation of concerns, as developers focus on their application logic and dependencies, while IT operations teams can focus on deployment and management.
Some of the key benefits of containerization:
Lightweight - Small size on disk and very low overhead.
Isolation - Containers keep apps isolated not only from each other, but from the underlying system. Inherent constraints mean containers are secure by default.
Portability - A container runs on any machine that supports the container's runtime environment. You can build locally, then easily move to on-premise or cloud environments.
Loose coupling - Containers are highly self-sufficient and encapsulated, allowing you to replace or upgrade one without disrupting others.
Scalability - Because containers are lightweight with loose coupling, you can scale out quickly by creating new containers.
In short, containers make apps easier to develop, deploy, and manage.
How is this different from a virtual machine?
The immediate comparison that comes to mind is to a virtual machine (VM), which is why the easiest way to understand a container might be to understand how it differs from a traditional VM.
Instead of virtualizing the hardware stack, containers virtualize at the operating system (OS) level, with multiple containers running atop the OS kernel directly. This means that containers are far more lightweight: they share the OS kernel, start much faster, and use a fraction of the memory compared to booting an entire OS.
For a more in-depth comparison, see Containers vs. virtual machines.
What is Docker?
Containers first appeared decades ago, but modern container development really took off with the introduction of Docker in 2013.
Docker is both an open source project for building applications on containers, and also a company that promotes and evolves the technology. They also own Docker Hub, which is Docker's official registry. Docker has become synonymous with containers because it has been the most successful at popularizing it. Originally built for Linux, Docker now runs on Windows and MacOS as well.
When we speak of containers and Sitecore, the container technology will always be Docker.
These are some of the terms you'll want to familiarize yourself with.
A package with all code and dependencies which serves as the blueprint for creating a container. Often, an image is based on another image, with some additional customization. An image is immutable once it has been created.
A repository is a collection of images with the same name, labeled with tags to indicate the version or variant. In an image reference, the repository is the part before the final colon. For example, "mcr.microsoft.com/windows/servercore" in mcr.microsoft.com/windows/servercore:ltsc2019.
A tag is a reference to a specific image within a repository. In an image reference, this is the part after the final colon, and is often used for a version number or architecture variant. For example, "ltsc2019" in mcr.microsoft.com/windows/servercore:ltsc2019. If you do not specify a tag, Docker will default to the tag name "latest".
A container is an instance of an image. It consists of the contents of a Docker image, an execution environment, and a standard set of instructions.
A CLI tool and (YAML based) text document format from Docker for defining how multi-container applications run. After you have created the definitions, you can deploy the entire multi-container application with a single command (
docker-compose up), which creates a container per image.
A container orchestrator is a management tool for containers. It helps you deploy and manage containers in production. Kubernetes is the most popular today, and is well supported by Microsoft via Azure Kubernetes Service (AKS).
Introduction to container-based Sitecore development
So now that you have a basic understanding of the concepts, what does this all mean for Sitecore development?
Why Sitecore and containers?
There are a number of reasons that make this a natural progression for Sitecore development. Not least of which is the move Sitecore has taken over the years towards a microservices-based architecture.
Without containers, this can be a cumbersome experience as an increasing number of services are involved. Containers, on the other hand, lend themselves very well to this architecture (and in fact encourage it). Spinning up a fully scaled XP1 topology on a developer's environment is no longer a challenge.
Here are the other reasons:
No install - No more installation using SIF (Sitecore Install Framework), SIM (Sitecore Instance Manager), etc. Sitecore provides container images ready to use. Get an instance up and running easily with
docker-compose up. Any container images will download automatically.
Multi-project efficiencies - The promise of VM-based isolation, realized. Run multiple Sitecore instances simultaneously without worrying about things like conflicting versions of SQL and Solr. Start and stop entire instances quickly when jumping between projects, making better use of your machine's resources.
Simplified onboarding - The onboarding process can now be as simple as: install prerequisites, clone your code repository, run
Environment consistency - Eliminate issues due to environment inconsistencies. No more "works on my machine". Containerize your build to have complete control of the build environment through DevOps / continuous integration (CI).
Environment stability - Due to the immutable nature of containers, no worries if you botch your local Sitecore instance, simply
Is it right for my team?
You can start to see the many benefits containers provide for Sitecore developers. However, for an organization, there are likely other considerations that will need to be factored in. To help you decide whether containers and Docker are right for your team, have a look at this article on the Sitecore Knowledge Center.
Starting with Sitecore version 10.0, container images for all roles and topologies are available at scr.sitecore.com, the Sitecore Container Registry (SCR).
For information about using the Sitecore Container Registry, see the Sitecore image reference.
For previous versions of Sitecore, you can use the docker-images community repository. This requires a bit more work as you need to first build the images, but the process is scripted and very well documented. Please refer to this knowledge base article for information about Sitecore's support for containers prior to version 10.0.
Sitecore Docker resources
In addition to the Sitecore images, you'll want to become familiar with the following resources. If you're following the documentation, these will be referenced along the way.
Docker Examples - Repository containing an example Visual Studio solution with recommended structure for container development, and Docker compose files for building Sitecore instances in various topologies.
Now that you've had an introduction, follow the link to get your environment set up for container-based Sitecore development.
Sitecore Knowledge Center
Other learning resources
In-depth labs from Docker:
Pluralsight has a great deal of Docker content: