Should You Use Docker for Your Local Sitecore Development?

Whether you end up deploying to an Azure Kubernetes Service (AKS) Cluster, PaaS, or VMs… using Docker for local Sitecore development could provide several benefits irrespective if you end up pushing images into AKS.

Benefits of Containers

Using containers can provide several benefits, especially around how portable and immutable images can be. Some top benefits are as follows:

• Speed: Seconds to start with no more dependency nightmares
• Efficiency: Do more with less overhead/lightweight
• Isolation: Secure and its own space
• Immutable: What you see is what you get
• Portable: Runs on any machine that supports the runtime environment of the container
• Scalable/Loose Coupling: Add more and upgrade without affecting other containers
• Developer advantages: Faster builds, modular, and better collaboration

The Docker Development Setup/Flow

When using Docker, the setup time is greatly reduced, which is a huge benefit for development. Even if you leverage XP1 in your Docker development environments, the setup process is largely the same as XP0 (and there are several reasons why you should use XP1 or XM1 as you will want to match the architectural integrity of your destination environment).

The flow when using Docker for development is based on the concept of image layers, where you obtain the base Sitecore runtime per Sitecore role and then add your solution (along with any modules and tools) to create a custom image that can be deployed locally via Docker Compose, or when ready, to the Azure Container Registry (ACR) if deploying to AKS (of note, you can leverage an Azure Container Registry as a great source to centralize and manage your images for sharing with other developers even if you are not using a containerized environment for hosting Sitecore visitors).

Sitecore has a great flow example for how custom images are created as follows:

The steps you would take to get setup, developing and deploying custom images are:

1. Setup Docker per developer: Set up the environment (sitecore.com)
2. Get Sitecore base images (Container Deployment Package): Sitecore Downloads: Sitecore Experience Platform 102
3. Create custom images: Building custom Sitecore images
4. Test locally in Docker (Docker Compose is critical): Run your first Sitecore instance
5. Push images to the Azure Container Registry if using AKS or deploy your solution to PaaS or VMs (no images but using the same code used to test your local images)
6. If deploying to AKS, make sure to leverage Sitecore Serialization to get the appropriate templates/items into the AKS environment

If you have multiple developers working on the solution, which is a common use case, it will be imperative to flush out your branching and DevOps strategy. If you are planning to deploy to AKS, you could always have a “super dev” that approves the pull requests be the one who creates the final image that gets pushed to the ACR… but you should also evaluate using an Azure DevOps Pipeline with an ACR Task to build your images from GitHub so you are not dependent on an individual.

If you are not pushing to an ACR/sharing images you would follow your normal deployment methodology using GitHub. Its also critical to note that with Sitecore images, you have an image per Sitecore role, so gone at the days of a base Sitecore installation that you then use transforms to make a CM or CD.

So Should You Use Docker for Local Sitecore Development?

The last point from the previous section is a critical one, as even if you are not deploying images to AKS, you can still use Docker to test your solution locally and then just deploy the solution files. If you only assume that Docker is for when you are using AKS, you may be missing on several benefits.

Bottom line is that Docker provides consistency (removes the OS layer), easier when setting up a local development environment, and enables more sharing with other developers (ex. share a custom image for review). For these 3 reasons, you should evaluate if Docker will work for your local development needs.