Sitecore Development with Docker Containers in 2023

This is my forward-looking view on the current state of developing on the Sitecore platform with containers. I will be considering XM/XP/XM Cloud.

Credit to Vitalii Tylyk for this fun image :)

Back Story

I first looked at Docker based development back in 2019 when the Sitecore community-based and community-led effort of doing Sitecore in Docker was starting to really gain traction.

At the time, Sitecore XP was the common mainstay and Sitecore XC (Commerce) was also not unusual to see at various customer implementations. Companies were excited with the Sitecore 9 XP feature set and were ready to try and use these features to grow their businesses. However, a common complaint was how difficult it was to get Sitecore XP running on local dev machines.

To those that knew about Containers, it probably would have seemed that the reasonable solution was to reduce the developer pain by running Sitecore on Docker. The benefits are now well-documented:

The key benefits of containerization include the following:

Lightweight — small size on disk and very low overhead.

Isolation — containers keep applications isolated not only from each other, but also from the underlying system. Inherent constraints mean containers are secure by default.

Portability — a container runs on any machine that supports the runtime environment of the container. You can build locally, then easily move to on-premise or cloud environments.

Loose coupling — containers are highly self-sufficient and encapsulated, so you can replace or upgrade one container without disrupting other containers.

Scalability — because containers are lightweight and are loosely coupled, you can scale quickly by creating new containers.

I was quick to check out the community docker GitHub repo and try and run it on my own. I soon ran into many roadblocks, some of which were a real pain for me to solve at the time such as not enough disk space to build the images. At the time there were no public Sitecore images available, you had to build your own. If you wanted to share them with your team, you needed to provision an Azure Container Registry. These things are not easy for someone new to the process.

So I requested a new External SSD for my work laptop and tried in vain to get the community images built and running. It turns out it is not possible to run Sitecore on Docker on any drive other than your system drive.

I then painstakingly managed to find a spare few GB to clean up on the system drive and managed to finally get it running. Success! But how do I actually deploy the customer’s solution? I couldn’t find much information on this at all at the time outside of building custom images, which I didn’t see the point of at all. At this point I gave up and from then until recently held the opinion that Sitecore development on Docker was just not for me.

XM Cloud changed my mind

With the release of XM Cloud, I realised my previous opinion needed to be revisited when I found out that you do need to be using Docker for the XM Cloud development workflow.

Over the years I had been following the Sitecore Slack #docker channel and watching many people try containers and have varying degrees of success.

I saw that starting in Sitecore 10, Docker images were officially built and supported and you could raise Sitecore support tickets if required.

I saw that the Sitecore team themselves had been reporting the occasional bug to Docker and these getting resolved.

I saw the with Sitecore 10.3 release, Windows 11 / LTSC2022 images were finally pushed.

I saw the XM Cloud starter repository had a decent example of an XM Cloud on Docker solution.

I saw that the Docker Examples repo was getting some love from the community and Sitecore.

A roadmap for a customer to migrate from XP to XM Cloud

So, when I was tasked with creating a roadmap for a customer to migrate from XP 10.1 to XM Cloud, I came up with the following.

1. Upgrade to the latest Sitecore XP/XM version.
2. Migrate from XP to XM. Replace any required XP functionality with appropriate SaaS equivalent.
3. Migrate from TDS/Unicorn to SCS.
4. Implement Docker into developer workflow.
5. Incrementally rewrite parts of the site onto Headless (Next.JS).
6. Migrate all content to XM Cloud (and publish to Experience Edge).
7. Change rendering hosts to XM Cloud (and Experience Edge).

Upgrading to XM latest and migrating to Docker for local development gets you well on your way.

Building custom container images

Something I noticed quickly on my journey to Dockerizing an existing solution was that the step to build a custom image with the solution was one of the slowest operations in the whole process.

I did some research and found that optimizing your .dockerignore file and what path is included in the build can help a lot. In particular you want to be excluding any serialized content item yml files. But if you’re migrating an existing solution there’s no doubt a lot of small changes that need to be done during the process and sitting there twiddling your thumbs for 5 minutes while Docker does a glorified msbuild call is not my idea of fun.

So I took a step back, did I actually need the solution in an image? The default docker-examples configures a symlink to the website root so you can easily build your solution and have it publish to that directory, so for local develpment, its not needed. What about when promoting your code to test / prod environments? Well, unless you are intending to run your solution containerized in test or prod environments (e.g. in AKS), then there’s no need to have an image of it.

Even then, you could actually have two different docker-compose overrides, one that does have the solution image and one that does not. Day-to-day dev could use the one that does not, and only use the one that does on your CI/build pipeline.

With this change I saw a great increase in change turnaround time. I also am using Helix Publishing Pipeline and have configured it to delete the files in App_Config automatically on build of the solution, and it’s easy to add other file cleanup paths too.

I can have totally cold (but cached) images, run up.ps1 and be running the solution within 2 minutes. Once everything is up and warm, I can make a change, hit build, and Sitecore recycles and comes back within 30 seconds.

Next upgrade will be a comparative breeze

Once you’re upgraded and Dockerized, the upgrade process to the next release becomes something like this:

1. Update solution nuget packages and fix any build issues
2. Update the .env file with the latest image tags
3. Check the Sitecore Upgrade Guide for any SQL DB upgrade scripts you need to run
4. Run the containers
5. Run any post upgrade steps such as the SXA site upgrade scripts
6. Code and content upgrade complete!

Of course you then have worry about the infrastructure side but hopefully you have that easily sorted too 😂

Save even more time for your team by having your solution in an Azure VM

If you have others on your team and already have a process in place for creating Azure VM’s for the team, great! If not, then it’s worth discussing with the team. Once one person has set up the solution, it’s easy to clone the VM in Azure.

Just make sure to pick a VM SKU that supports Nested Virtualization. As of time of writing this, I found that E4bs_v5 suits Sitecore really well. 4 cores, 32GB RAM, SSD support, recent gen CPU. You’ll need at least 250GB premium SSD.

Conclusion / tl;dr:

I’ve been cautiously reserved about Sitecore on Docker for a long-time, but I think it’s definitely a mature technology now, with far more benefits than down sides, and encourage anyone planning an upgrade to consider Dockerizing.