5 ways you can optimize your Sitecore Docker builds
With newer versions of Sitecore Docker becoming more and more adopted as for local development, but also for hosting (with Kubernetes).
And with that comes one of the disadvantages of Docker — slow Docker builds.
So how can we speed our Sitecore Dockerfile?
I. Keep your artifacts in solution image to leverage Docker multi-layer build cache
This might be especially important if you have CM/CD setup (XM/XP topology).
Instead of copying artifacts separately each time to CM/CD you can create a solution image with artifacts which would have the build output.
It’s also important that your solution build is role-agnostic and doesn’t have any configs specific to CM/CD role.
For this you can employ Sitecore role:required attributes in config files, and if web.config is different you can transform it with XDT transformations on startup in entry point.
II. Group RUN and ENV command together
Every command in your Dockerfile means adding another layer to your Docker image, increasing it’s size and build complexity.
So instead of having multiple RUN commands in a row — why not group them together in one?
Lesser commands in your Dockerfile — faster the build.
III. Order build layers
Every time something changes in your Dockerfile build commands it would invalidate the build cache for subsequent Dockerfile commands.
Therefore the recommendation is to keep the commands that are least likely to change on TOP of the Dockerfile.
In Sitecore context it might mean moving any Sitecore OOTB module (like SXA, DEF, Headless Services, etc.) COPY commands, or ENV variables to the top, while keeping your artifacts copy at the bottom to be run as late as it possible could be.
IV. Consider using link parameter for COPY command
If you do COPY command in your Dockerfile you might find them to be quite expensive and time consuming.
However you can speedup the copy process by using --link parameter which would create link instead of copying the files.
Docker however has limitations on this by asking to make sure that there is no use of the copied files in subsequent Docker commands.
This parameter might be helpful to speed the build if you are copying some assets to the CM/CD image that you might use after container startup.
V. Use .dockerignore file
Copying files to Docker context is one of the most time-consuming steps of the build.
If you want to speed up the build — ensure that you copy ONLY the files that are needed to build the image.
If your artifacts/solution have some files that you want to exclude from being copied to container — you can add them to .dockerignore file.
