Is Your Sitecore Docker Environment Sluggish to Get Going?

Introduction

Most mornings, I’m up before the sun as I’m most productive early on when both my family is still sleeping, and even my coworkers haven’t rolled on into Slack. Most of my projects I’ve got lately are running in Docker on an Azure VM. So once I’ve fired up the VM and started up Docker, I run that super simple ./up command, and away I go. That is at least most mornings. On one of my projects, which is not an XM Cloud setup, just an XP0, I started noticing it getting slower… and slower to get to the point it was asking me to log in.

I didn’t think too much of it until the other day when, while it normally took 5 - 10 min, it was taking upwards of 30. Got me thinking, what in the world has changed???

So, How Did I Solve It?

Well, naturally, the first thing I did was check recent commits to see if there were any Dockerfile changes or anything that sticks out like a sore thumb that might signal a problem. Nothing.

Next, I did some Googling, Why is my docker slow to start? While this ultimately did point in the right direction, I didn’t clue in at first. I mean, we had basically used an XP0 docker build from one of the custom demos. Which is why I reached out on the #docker channel on Sitecore’s Community Slack forum and inquired. I knew two points of interest that were the bottle next. This was the first, directly after the build context was set up.

I underlined in red the part which seemed off. Considerably. I didn’t remember this value ever being this large. It always stalled right at this line:

Step 5/20 : COPY src/ /temp/

And when I mean stall, it stalled upwards of 10-15min.

The second part was here at step 13/20.

Whatever was happening at this line was the culprit, and my only thinking is it went back to the size of that build context.

Step 13/20 : COPY src/ ./src/

After checking that Hyper-V was still enabled, no antivirus was running. I still had that annoying Anti-Malware Executable, which I can never get rid of; the question came back to the solution I had come across on Google. The .dockerignore file. So I opened it up. This is what mine looked like.

# folders
.git
.gitignore
.vs
.vscode
.config
.sitecore
build
docker
packages
**/bin/
**/obj/
**/out/

# files
*Dockerfile
docker-compose*
**/*.md
*.ps1
**/*.yml
**/*.module.json
sitecore.json

Looked pretty normal. But then I decided to compare it to what comes in an XM Cloud template. Here’s what’s in the same file but for that starter template.

# folders
.git
.gitignore
.vs
.config
.sitecore
build
docker
packages
**/bin/
**/obj/
**/out/
**/node_modules/
**/.generated/
**/.next*/
**/.vscode/
**/coverage/

# files
*Dockerfile
docker-compose*
**/*.md
*.ps1
scjssconfig.json
**/*.yml
**/*.module.json
sitecore.json

You’ll notice several noticeable differences. Namely these guys. the largest of which would be node_modules.

**/node_modules/
**/.generated/
**/.next*/
**/.vscode/
**/coverage/

This made perfect sense because right around this time, we setup the SXA Theme and started using Tailwind, amongst other packages, to build our site. And that did it. Those 5 lines took 20 minutes off my startup time. And reduced my build context to a minuscule 10 MB in comparison to the original 390MB, which it had ballooned into.

I was now able to kick off an ./up, go brew a coffee, and be back in time to log in before it timed out. So if you all of a sudden notice your docker taking way longer to get going, double check your .dockerignore file FIRST. Big thanks to Steve McGill and Jeff L'Heureux for helping me solve it.

---