Dotnet Containers - now and when

.Net has evolved over the years from being exclusively for windows then through the work of the mono project its become multi platform. Mono has now evolved into .net core which has now become just standard .net . Developing .net on a Mac or linux machine is now normal. With the multi platform capabilities of .net, running it in container images using docker has become common practice for hosting .net applications.

Lets take a look at how we can use containers in .net now (.net6) and how this changes when .net7 is released.

Currently in .Net6?

to containerise a web application or service you create a docker file at the base of your project. Here is my Dockerfile: (no extension just Dockerfile)

#Build
FROM?mcr.microsoft.com/dotnet/sdk:6.0-focal?AS build?
WORKDIR /source
COPY . .
RUN dotnet restore "./minimal.csproj" --disable-parallel
RUN dotnet publish "./minimal.csproj" -c release -o /app --no-restore

#serve
FROM?mcr.microsoft.com/dotnet/sdk:6.0-focal
WORKDIR /app
COPY --from=build /app ./
EXPOSE 5000
ENTRYPOINT ["dotnet", "minimal.dll"]d        

The above contains instructions for docker in two parts first to build and then to host an application. First lets go through the build side of the file from above example above a line at a time

1. A base docker image is specified?as a?starting point to build upon, in this example it's "mcr.microsoft.com/dotnet/sdk:6.0-focal?" which contains a .net sdk to run our app with.
2. Set a working directory, all other commands will be run as from within this directory
3. Copy all the files in the base of the project over to the docker image "COPY . ." This is my super simple project, it could be that these files are all held within a src folder for example that might be specified here instead of the base directory.
4. We restore the project, where the dependancies required to compile our application are downloaded "RUN dotnet restore "./minimal.csproj" --disable-parallel"
5. Compile the application into a state for release and output the code in the app folder, This will produce a minimal.dll file sitting within an app folder.

The above docker file so far gets a base image required to compile our code, copies the source code into the container and then restores the dependancies and complies the code into a release. Next our Dockerfile will instruct docker into how to host it. We will again examine these lines on at a time

1. Again the hosting part of docker we specify the base container, this might be different from the build container if for example we produce a self contained executable instead of a dll file we would have no dependancy on the .net sdk and so could use a standard Linux base image instead.?In the above example though we produce a dll file which is platform independent but requires a .net sdk to be present, hence using the dotnet docker image.
2. We set a new working directory which is the app folder
3. We copy the dll file produced in the build phase out of the app folder into the working directory (also app) of our hosting image
4. The port that we want exposed by docker is specified
5. The entrypoint instruction is the command that gets executed when the docker container is started. So we are telling docker to run our minimal api?

Now that we have setup the dockerfile we can build an image with the following command:?

docker build --rm -t?miniapp .        

This produces?a docker image that is based on linux which includes the .net6 sdk and our minimal.dll file?for running our minimal api. The above command will look for a docker file in the current directory and build an image called miniapp

To run this image run the following command:

?
docker run -d -p 80:5000 miniapp        

This runs the docker image and port maps between the docker images internal port of 5000 and exposes that to our machine on port 80. If we goto localhost:80 we will see our hi in the browser.

When .net 7 is released?

How has the above changed with .Net7?

.Net7 has built in Docker support with no need for docker files. Docker is still used its just that .Net assumes certain things and uses sensible defaults to avoid the need for a docker file. It assumes you need a?standard .net base image that matches the .net version of your project and using the project name as the image name. It knows that .net?projects need to be restored and compiled. It knows how to run a .net program so the commands in the docker file can all be inferred without us needing to specify anything. In the preview version we do have to include an extra package for this to work through 'Microsoft.NET.Build.Containers ', add this is with the following command:

dotnet add package Microsoft.NET.Build.Containers?        

Now to build the image we run the following command:

dotnet publish --os linux --arch x64 -c Release -p:PublishProfile=DefaultContainer        

This build a container with the same name as the project. Initially it will have a build number of 1.0.0? .net has published a docker container which can be run with docker with the below command:

?
docker run --rm -p 80:80 miniapp:1.0.0        

Here the app will run under port 80 of the local computer since its mapped to port 80 of the docker image.

Something I find interesting here is that the docker image is build using linux and at the moment a windows image is not even supported when being run as a docker image. So .net has changed from being a windows only framework through to linux only when run through docker.?This to me shows how Microsoft has changed from being a windows centred company through to a service provider that also builds an operating system.