Docker Basics: C#
Continuing the exploration of Microservices Demo in this Docker Basics series, we’re approaching C#.
The C#/.NET platform has existed since 2002, and it’s being continuously developed by Microsoft and the open-source community nowadays.
In the old days, it could run on Windows only. But for a while, it’s not the case anymore!
This led to not that big of adoption in the early days compared to Java for example.
In contrast with Go and NodeJS, C# is compilable but requires a runtime actually to run.
Also, the C# ecosystem is heavily influenced by Visual Studio, an IDE developed by Microsoft. Thus, there’s a typical project structure.
Today’s service is a Cart service. Let’s navigate to ./src/cartservice and explore.
Exploring the code
Firstly, you see cartservice.sln file. This is typical Visual Studio. In a nutshell, you create a “solution,” and it can have multiple “projects.” This solution has 2 projects: cartservice and cartservice.test.
We need only the cartservice for dockerization, so we’ll put our Dockerfile in there to avoid Docker context problems.
If you search for a port, there’s really nothing that indicates the port number. This is also typical. You can influence ports using a predefined environment variable. ASPNETCORE_HTTP_PORTS with the default value being 8080
What’s ASPNETCORE?
It’s a standard open-source modular web app framework in the dotnet ecosystem. It’s developed and maintained by Microsoft and the open-source community.
Let’s continue exploration and go to Startup.cs which has the following:
string redisAddress = Configuration["REDIS_ADDR"];
string spannerProjectId = Configuration["SPANNER_PROJECT"];
string spannerConnectionString = Configuration["SPANNER_CONNECTION_STRING"];
string alloyDBConnectionString = Configuration["ALLOYDB_PRIMARY_IP"];
...
else
{
Console.WriteLine("Redis cache host(hostname+port) was not specified. Starting a cart service using in memory store");
services.AddDistributedMemoryCache();
services.AddSingleton<ICartStore, RedisCartStore>();
}
So, there’s no need to set any environment variables.
Plus, no environment variables are needed for tracing and observability, like in the previous examples.
Dockerfile
In the cartservice.csproj you can see
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
</PropertyGroup>
This tells us what version of the .NET platform we are creating this project for. The list of platforms is here
You can build the project using .NET SDK. You can find Microsoft-dotnet-sdk docker images on DockerHub. We’re safe with mcr.microsoft.com/dotnet/sdk:8.0 (there’s an alpine version, but I don’t care much). We can avoid using Alpine because we’re building for a dotnet runtime instead of building for a specific Linux distribution.
Dependencies are specified cartservice.csproj and they have to be cached.
Then we do the actual build and use another runtime image to run the project (meaning multistage builds).
For the runtime, we’ll use mcr.microsoft.com/dotnet/aspnet:8.0-alpine
Smaller images are available for the runtime, but this one has dependencies plus dotnet CLI.
These are official images supported by Microsoft.
To install the dependencies, we’re using dotnet restore
To run the actual build, we do dotnet publish --no-restore
--no-restore a flag, which means we won’t install dependencies because we already cached them. By default dotnet publish without this flag will update the dependencies
What are we building
So, with Go it was a single file. Here it could be the same, but by default it’s not. By default, we get a folder with *.dll files and some static content. We could make it a single file, but I don’t really see a point. This will add unnecessary flags, which will be hard to understand for those who aren’t familiar with the dotnet ecosystem.
It’s time to put the actual dockerfile together and try the build.
FROM mcr.microsoft.com/dotnet/sdk:8.0 as build
WORKDIR /app
COPY *.csproj ./
RUN dotnet restore
COPY . .
RUN dotnet publish --no-restore
Why not multistage? We’re not sure what files got produced :)
So let’s do the following with this dockerfile:
docker build -t cartservice .
After it’s completed, let’s get into the image through a dummy container and see what’s going on
docker run --rm -it cartservice bash
Then let’s do this inside a container:
cd bin/Release/net8.0/publish && ls -al
This has to produce something like
root@9d13f28c1b6e:/app# cd bin/Release/net8.0/publish/
root@9d13f28c1b6e:/app/bin/Release/net8.0/publish# ls -al
total 6644
drwxr-xr-x 2 root root 4096 Feb 6 20:10 .
drwxr-xr-x 3 root root 4096 Feb 6 20:10 ..
-rwxr--r-- 1 root root 417280 May 17 2023 Google.Api.CommonProtos.dll
-rwxr--r-- 1 root root 192512 May 17 2023 Google.Api.Gax.Grpc.dll
-rwxr--r-- 1 root root 78848 May 17 2023 Google.Api.Gax.dll
-rwxr--r-- 1 root root 5120 Feb 20 2023 Google.Apis.Auth.PlatformServices.dll
-rwxr--r-- 1 root root 209408 Feb 20 2023 Google.Apis.Auth.dll
-rwxr--r-- 1 root root 78848 Feb 20 2023 Google.Apis.Core.dll
-rwxr--r-- 1 root root 81920 Feb 20 2023 Google.Apis.dll
-rwxr--r-- 1 root root 62976 Jun 7 2022 Google.Cloud.Iam.V1.dll
-rwxr--r-- 1 root root 151040 Jan 11 2023 Google.Cloud.SecretManager.V1.dll
-rwxr--r-- 1 root root 248832 Jun 26 2023 Google.Cloud.Spanner.Admin.Database.V1.dll
-rwxr--r-- 1 root root 151552 Jun 26 2023 Google.Cloud.Spanner.Admin.Instance.V1.dll
-rwxr--r-- 1 root root 9728 Jun 26 2023 Google.Cloud.Spanner.Common.V1.dll
-rwxr--r-- 1 root root 200704 Jun 26 2023 Google.Cloud.Spanner.Data.dll
-rwxr--r-- 1 root root 318464 Jun 26 2023 Google.Cloud.Spanner.V1.dll
-rwxr--r-- 1 root root 62464 Jun 7 2022 Google.LongRunning.dll
-rwxr--r-- 1 root root 443672 May 16 2023 Google.Protobuf.dll
-rwxr--r-- 1 root root 28448 Nov 7 21:40 Grpc.AspNetCore.Server.ClientFactory.dll
-rwxr--r-- 1 root root 147232 Nov 7 21:40 Grpc.AspNetCore.Server.dll
-rwxr--r-- 1 root root 21784 May 5 2023 Grpc.Auth.dll
-rwxr--r-- 1 root root 70432 Nov 7 21:40 Grpc.Core.Api.dll
-rwxr--r-- 1 root root 33568 Nov 7 21:40 Grpc.HealthCheck.dll
-rwxr--r-- 1 root root 295200 Nov 7 21:40 Grpc.Net.Client.dll
-rwxr--r-- 1 root root 50464 Nov 7 21:40 Grpc.Net.ClientFactory.dll
-rwxr--r-- 1 root root 22304 Nov 7 21:40 Grpc.Net.Common.dll
-rwxr--r-- 1 root root 16000 Oct 22 2021 Microsoft.Bcl.AsyncInterfaces.dll
-rwxr--r-- 1 root root 40096 Nov 1 01:06 Microsoft.Extensions.Caching.StackExchangeRedis.dll
-rwxr--r-- 1 root root 712464 Mar 8 2023 Newtonsoft.Json.dll
-rwxr--r-- 1 root root 1401344 Dec 4 19:08 Npgsql.dll
-rwxr--r-- 1 root root 167424 May 4 2023 Pipelines.Sockets.Unofficial.dll
-rwxr--r-- 1 root root 819200 Jul 7 2023 StackExchange.Redis.dll
-rw-r--r-- 1 root root 288 Nov 18 16:30 appsettings.json
-rwxr-xr-x 1 root root 72544 Feb 6 20:10 cartservice
-rw-r--r-- 1 root root 27817 Feb 6 20:10 cartservice.deps.json
-rw-r--r-- 1 root root 51200 Feb 6 20:10 cartservice.dll
-rw-r--r-- 1 root root 33800 Feb 6 20:10 cartservice.pdb
-rw-r--r-- 1 root root 469 Feb 6 20:10 cartservice.runtimeconfig.json
-rw-r--r-- 1 root root 487 Feb 6 20:10 web.config
A bunch of files. You can see that there’s cartservice.dll a file. This is our main file. Everything else is dependencies. Why did we choose bin/Release/net8.0/publish?
So, we’re building for net8.0 version (we got it earlier), ./bin which is a default output folder, ./Release is a default non-development configuration name, and ./Publish is a folder where the published artifacts are.
So, it’s a convention thing. You can overwrite everything, but it will complicate our dotnet publish --no-restore command.
Let’s do the multistage, then.
FROM mcr.microsoft.com/dotnet/sdk:8.0 as build
WORKDIR /app
COPY *.csproj ./
RUN dotnet restore
COPY . .
RUN dotnet publish --no-restore
FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine
EXPOSE 8080
WORKDIR /app
COPY --from=build /app/bin/Release/net8.0/publish ./
ENTRYPOINT [ "dotnet", "./cartservice.dll" ]
If we want to build for Windows or MacOS, we need to specify the flags, but since it’s Docker, we don’t need to do anything.
If we do a quick inspect on a docker image, we’d see that it’s roughly 122 MBs, which isn’t the smallest option available, but I can leave with that!
You can test it like we did with the Go example in the last article!
Optimizations & dotnet specifics
Simplicity is the key!
Instead of dotnet publish --no-restore you can do
dotnet publish --no-restore \
--self-contained true \
-r linux-musl-x64 \
-p:PublishSingleFile=true \
-p:PublishTrimmed=True \
-p:TrimMode=Full
This will force you to do
dotnet restore -r linux-musl-x64
# instead of
dotnet restore
Here’s what we’ve done.
--self-containedmeans that MSBuild will publish .NET runtime (in our case, 8.0) together with our app so that we can use a lightweight runtime-deps image instead of aspnet that has the required runtime.-r linux-musl-x64means a targeted runtime (we’re targeting musl linux, so it’s Alpine-specific specific and we talked about it in the Python article); other runtimes could belinux-x64orosx-arm64, etc. Here’s the list of runtimes-p:PublishSingleFile=truemeans exactly what it says - publish a single file instead of a bunch of*.dll-p:PublishTrimmed=Truemeans reducing the artifact size and sacrificing debug capabilities-p:TrimMode=Fullmeans trimming granularity (if you sayPartial, you can exclude certain assemblies from from trimming)
This will lead to the following files structure in your /app/bin/Release/net8.0/linux-musl-x64/publish
-rw-r--r-- 1 root root 288 Nov 18 16:30 appsettings.json
-rwxr-xr-x 1 root root 98807780 Feb 6 20:25 cartservice
-rw-r--r-- 1 root root 33820 Feb 6 20:25 cartservice.pdb
Reason why we have linux-musl-x64 in a path is because we specified it earlier in dotnet publish
Because we’re using linux-musl-x64 build, we cannot select just any base image. Someone could build this from MacOS with an M1 processor, and the build won’t work. So, we need to set an x64-specific base image, which is mcr.microsoft.com/dotnet/runtime-deps:8.0-alpine-amd64
And eventually, you could have your Dockerfile look like:
FROM mcr.microsoft.com/dotnet/sdk:8.0 as build
WORKDIR /app
COPY *.csproj ./
RUN dotnet restore -r linux-musl-x64
COPY . .
RUN dotnet publish --no-restore \
--self-contained true \
-r linux-musl-x64 \
-p:PublishSingleFile=true \
-p:PublishTrimmed=True \
-p:TrimMode=Full
FROM mcr.microsoft.com/dotnet/runtime-deps:8.0-alpine-amd64
EXPOSE 8080
WORKDIR /app
COPY --from=build /app/bin/Release/net8.0/linux-musl-x64/publish ./
ENTRYPOINT [ "./cartservice" ]
This build produces a Docker image with a size of roughly 108 MBs.
It’s not a bad improvement. However, it isn’t worth the trouble in my opinion.
Conclusion
As you see, dotnet provides unique challenges that we haven’t seen so far (if you follow the series from the beginning). W hat’s good, on the other hand, is the fact that there’s a strict structure involved and a unified configuration format.
See you in the next one!