What's interested me in Sitecore's use of Docker

Now that Sitecore 10 is out, I've been having a dig into the new Docker approach that's been released. There are some interesting differences here between Sitecore's official approach and the way the community scripts I'd experimented with worked – and I've learned a few interesting new things as a result of having a read of the examples provided. Here are the things that caught my attention:

Base images come from the official feed now: url copied!

The first important new thing is that we no longer have to build the all base images ourselves. For licensing reasons the community images project could not maintain a public image repository, but with the release of v10 there is now an official Sitecore feed. This includes standard images that can be used for XP and XM type deployments using the `1909` and `ltsc2019` releases of Windows. And hopefully newer versions will follow...

There is a list of the official images available, but you can see what gets used when you read the compose scripts that Sitecore provide:

The theory is that we take these base images and then build anything different we need on top of them, using Docker's "layered" approach to image creation. Need a CM instance with a particular tool installed? Then you extend Sitecore's image, by adding the tool's files on top. That way build times are reduced, and adopting new releases from Sitecore is easier when they appear.

(Though remember that you still can't push these to a public registry)

Need to tweak a container? Overrides are your friend: url copied!

This is a whole feature of Docker that I wasn't aware of until now: When you have a compose file, you can make modifications to it without changing the original. You can provide an "override" file that is applied on top of your standard compose file, a bit like a Sitecore config patch. You can see an example of this in the custom images github repository Sitecore have provided:

You can have both the default docker-compose.yml with its docker-compose.override.yml file, or give them whatever name you like and specify the files on the command line when you run compose.

In the override file you specify any of the containers in your main compose file, and change any subset of their properties. That makes it ideal for tweaks from the standard config. So for example, you might specify the Solr container as:

  solr:
    isolation: ${ISOLATION}
    ports:
      - "8984:8983"
    image: ${SITECORE_DOCKER_REGISTRY}sitecore-xp0-solr:${SITECORE_VERSION}
    volumes:
      - ${LOCAL_DATA_PATH}\solr:c:\data

					

and then apply an override to limit its memory use:

  solr:
    mem_limit: 1GB

					

And the two sets of config data will be merged together when you start your containers.

Need to disable a role? You don't need to delete it: url copied!

In the past, when I'd not wanted one of the roles from a default compose file (commonly not needing to start both a CD and a CM instance in development) I'd removed the relevant bits from the file entirely. But it turns out the "scale" property of the compose file for each container lets you tweak this without messing with the underlying file.

When you add the " scale " property to the definition of a container in your compose file, you're telling Docker how many instances of that need to be started. So you can specify zero if you don't want any of that container to come up.

Plus you can combine this with the override files above, so that the CD container doesn't get run just by adding "scale: 0" to the override definition of the content delivery role.

Though take care with the depends settings of other containers. You don't want to end up with a container that never starts because it depends on the startup of another container with scale:0...

Your compose file can specify the build process for an image: url copied!

Another interesting way of making better use of compose files is that they can include a "`build`" section. That can specify the `context` for building the image (ie where the `Dockerfile` is) and the arguments to be passed in when the `Dockerfile` runs.

That looks really helpful for simplifying the initial setup of a development environment under Docker. Running docker-compose up can create any images that are missing from the local machine as – which can take a step out of the process.

↑ Back to top