Building up some Microservices, Breaking up the Monolith #2 – Dockerising the Monolith

By | 2 March, 2019

Docker as a technology seems to divide the community, some say its a good solution to the problem of packaging up your software that collects all of your dependencies and then stamps them into a repeatable deployable package….others say its been done before with other technologies or that its a security problem waiting to happen since all of the dependencies you’ve placed in the container are locked at a particular version and not updatable.

If you’ve got a pipeline around it thet can regenerate your deployable package in a repeatable and testable way (which is what we’re aiming to do with this series), then my opinion tends to be with the former. We can use these repeatable blocks to create something complex yet easy to support. *BUT* we do have to make sure its automated and repeatable…..

Lets make our first immutable building block.

Here are the basics of Docker (and yes, there are books and books more on this topic alone, however I’m purely going for the minimum here…)

Docker Images are like Templates. We can use any templates stored in a Docker Registry and use that as a basis to create a new Image. (If you want to have a look at what images you can build on top of, search google for docker hub). To create a new Image, stored locally, we’ll use the “docker build” command in combination with a “DockerFile”

Docker Containers are the running version of an Image. They are an “instance” of that image that can run. To execute a container we’ll use “docker container run”

We’ll get to registries, and docker pulls in another article.

We’re going to use my example hosted at https://github.com/r3adm3/monolithsvc (commit: 4d9481801d9ed7b45f380ecb6b3ab6187fcd3fed) to save you (for now) from doing some coding. 

If you look at the docker file in the monolithsvc/monolithsvc folder you’ll find a docker file which we can use to build a new image.

For now the aim is to build a docker image using a base image, and add our code to it. Lets go through my docker file one line at a time. Each of these lines, becomes a layer in our docker “onion”, this leads to the ability to reuse layers and speed up successive builds.

 FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS builder

This instructs docker to use the mcr.microsoft.com/dotnet/core/sdk:3.1 image (pull it from docker hub or mcr.microsoft.com if necessary, or if its already in the local library just use that).

 WORKDIR /source

Docker build working inside the container, then sets the working directory to “source”

 COPY *.csproj .
 RUN dotnet restore

…this copies our project file from our Docker host into our image, and pulls down all of our Nuget dependencies.

 COPY . .
 RUN dotnet publish --output /app/ --configuration Release

copies the rest of our source into place, from Docker host into the SDK image, and creates a binary in the app folder.

FROM mcr.microsoft.com/dotnet/core/aspnet:3.1
WORKDIR /app
COPY --from=builder /app .
ENTRYPOINT ["dotnet", "monolithsvc.dll"]

and now the magic. Create another new image from the “mcr.microsoft.com/dotnet/core/aspnet:3.1

” image, set the working directory to “app” and copy the contents of the app folder on the builder image to this one. “Entrypoint” defines the command that will run on invocation.

Here’s the whole file:

 # Sample contents of Dockerfile (another test)
# Stage 1
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS builder
WORKDIR /source

# caches restore result by copying csproj file separately
COPY *.csproj .
RUN dotnet restore

# copies the rest of your code
COPY . .
RUN find -type d -name bin -prune -exec rm -rf {} \; && find -type d -name obj -prune -exec rm -rf {} \;
RUN dotnet publish --output /app/ --configuration Release

# Stage 2
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1
WORKDIR /app
COPY --from=builder /app .
ENTRYPOINT ["dotnet", "monolithsvc.dll"]

So how do we now build the image? Do this by:

docker build -t monolithsvc .
Sending build context to Docker daemon  123.9MB

Step 1/11 : FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS builder

 ---> 9ab567a29502

Step 2/11 : WORKDIR /source

 ---> Using cache

 ---> a3865660feec

Step 3/11 : COPY *.csproj .

 ---> f288604a05eb

Step 4/11 : RUN dotnet restore

 ---> Running in 470e94685a37

  Determining projects to restore...

  Restored /source/monolithsvc.csproj (in 29.18 sec).

Removing intermediate container 470e94685a37

 ---> cb8af44c9f96

Step 5/11 : COPY . .

 ---> 68b936eaea5d

Step 6/11 : RUN find -type d -name bin -prune -exec rm -rf {} \; && find -type d -name obj -prune -exec rm -rf {} \;

 ---> Running in 27b126eb6c2b

Removing intermediate container 27b126eb6c2b

 ---> d7ac0ef9c649

Step 7/11 : RUN dotnet publish --output /app/ --configuration Release

 ---> Running in 8bdc5eb89d55

Microsoft (R) Build Engine version 16.7.0-preview-20360-03+188921e2f for .NET

Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...

  Restored /source/monolithsvc.csproj (in 866 ms).

  monolithsvc -> /source/bin/Release/netcoreapp3.1/monolithsvc.dll

  monolithsvc -> /source/bin/Release/netcoreapp3.1/monolithsvc.Views.dll

  monolithsvc -> /app/

Removing intermediate container 8bdc5eb89d55

 ---> f728dea1188c

Step 8/11 : FROM mcr.microsoft.com/dotnet/core/aspnet:3.1

 ---> bdca989bc8d3

Step 9/11 : WORKDIR /app

 ---> Using cache

 ---> bf0c00033f92

Step 10/11 : COPY --from=builder /app .

 ---> a471287b9c9d

Step 11/11 : ENTRYPOINT ["dotnet", "monolithsvc.dll"]

 ---> Running in 94044c2fd3ef

Removing intermediate container 94044c2fd3ef

 ---> 218bd7169dbb

Successfully built 218bd7169dbb

Successfully tagged monolithsvc:latest
 

We should have a successful image in the local docker repo now, do a

docker image ls

REPOSITORY                                  TAG                      IMAGE ID            CREATED             SIZE
monolithsvc                                 latest                   ecc207b7e994        5 minutes ago       256MB

as you can see the image id matches with the hash at the final step of the docker build. Cool.

Last but not least we should try and make it run:

docker container run --name testdoodad -p 8080:80 monolithsvc

warn: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[35]
      No XML encryptor configured. Key {20f00e1c-b3c9-4b3a-b1e8-b36e7bbc73eb} may be persisted to storage in unencrypted form.
Hosting environment: Production
Content root path: /app
Now listening on: http://[::]:80
Application started. Press Ctrl+C to shut down.

…and test using a browser http://localhost:8080

Hopefully should all be nice and happy!

Source code at this point is here:

https://github.com/r3adm3/monolithsvc/commit/4d9481801d9ed7b45f380ecb6b3ab6187fcd3fed

Links to other articles in the series:
1. First a Monolith

…and a quick thx to SamM for going through this today 9/3/2021.