Build Sitecore solutions

You write a Dockerfile as the first step in containerizing your application. A Dockerfile contains instructions that Docker uses to assemble a Docker image and run it. The Dockerfile commands are a step-by-step recipe for how to build up your image.

The following is a Dockerfile example for a simple (non-Sitecore) ASP.NET MVC app:

FROM mcr.microsoft.com/dotnet/framework/sdk:4.8 AS build
WORKDIR /app

COPY *.sln .
COPY aspnetmvcapp/*.csproj ./aspnetmvcapp/
RUN nuget restore

COPY aspnetmvcapp/. ./aspnetmvcapp/
WORKDIR /app/aspnetmvcapp
RUN msbuild /p:Configuration=Release

FROM mcr.microsoft.com/dotnet/framework/aspnet:4.8 AS runtime
WORKDIR /inetpub/wwwroot
COPY --from=build /app/aspnetmvcapp/. ./

This example uses a multi-stage build: first the code is built with the mcr.microsoft.com/dotnet/framework/sdk image (the build stage), and then the output is copied to the mcr.microsoft.com/dotnet/framework/aspnet image (the runtime stage).

The Dockerfile is then used by the Docker build command and this command builds and creates the image.

An optional .dockerignore can be used to exclude files and folders from the build context, reducing the size or skipping sensitive data in COPY and ADD commands.

The example shows that code compilation and build are part of a Dockerfile's instructions. In .NET, this could include a NuGet restore, followed by invoking MSBuild. Building your application directly in a Dockerfile like this has advantages over a more traditional build, including:

With a typical Sitecore implementation, a single Visual Studio solution usually creates build artifacts for multiple roles, for example, Website and XConnect assemblies, and some artifacts must be deployed to multiple roles (for example CM/CD). For containers, this means that the same build output must be layered on top of multiple base Sitecore runtime images. You could instead duplicate the build instructions for each Sitecore image, but this would be very inefficient.

What you need is a Dockerfile that is focused solely on building your solution and storing the output as structured build artifacts on the resulting image.

You must send a Dockerfile through the Docker build command to produce an image. You can certainly use build command directly, but it is mostly configured with Docker Compose.

The custom-images folder contains the following files:

These are all types of Docker Compose files.

solution:
  image: ${REGISTRY}${COMPOSE_PROJECT_NAME}-solution:${VERSION:-latest}
  build:
    context: .
    args:
      BASE_IMAGE: ${SOLUTION_BASE_IMAGE}
      BUILD_IMAGE: ${SOLUTION_BUILD_IMAGE}
      BUILD_CONFIGURATION: ${BUILD_CONFIGURATION}
  scale: 0

To build the solution image:

Start by looking at the troubleshooting guide.

One common troubleshooting problem unique to the solution image (or any asset image) is that because it is never run as a container, it might not be obvious how you can explore the resulting file system. You can do this by running the image with an interactive shell.

For example, to open up an interactive command prompt (Nano Server does not have PowerShell) to the solution image example given previously:

docker run -it --rm docker-examples-solution:latest

Type exit to remove the temporary container and return to your previous PowerShell session.