The biggest ones were the new container tools (Podman, Buildah, and skopeo) and the new Red Hat Universal Base Images. When Red Hat Enterprise Linux (RHEL) 8 was released almost a year ago, and it came with lots of new features related to containers.
This article demonstrates how to use Red Hat Universal Base Images with Docker from a non-Red Hat system, such as a Windows or Mac workstation.
First it gets the current version of our own code by looking at the Git tag (line 24).Red Hat Universal Base Images (UBIs) allow developers using Docker on Windows and Mac platforms to tap into the benefits of the large Red Hat ecosystem. Invoke-WebRequest -Uri ((Invoke-WebRequest -Uri '' -UseBasicParsing | ConvertFrom-Json).runtimeDependencies | Where-Object Īfter making sure that this runs when a Git tag with a specific pattern is created (lines 3-6), getting the sources (line 15) and logging in to the Docker hub using configured secrets (lines 17-20), you can see a big step (lines 22-63) which only creates the commands for later steps. RUN dotnet publish "core.csproj" -c Release -o /app/publishįROM /powershell:lts-nanoserver-$BASE as vsdbg WORKDIR /vsdbg RUN pwsh -Command " ` core/ core/ WORKDIR "/src/core" USER ContainerAdministrator RUN dotnet build "core.csproj" -c Release -o /app/build
shared/ shared/ COPY RUN dotnet restore "core/core.csproj" COPY. # escape=` ARG BASE FROM /dotnet/core/sdk:3.1-nanoserver-$BASE AS build WORKDIR /src COPY RUN dotnet restore "shared/shared.csproj" COPY. As an example, let’s take the following Dockerfile which is actually one that we use for one of our services: 1 The trick here are build arguments: You have variables in your Dockerfile and let the docker build call know, how to substitute them. But you can connect your own runners, so I created a container image for that ( sources and Docker hub) to make deployment easier and with that setup, we can now build all our images for all needed Windows Server versions and still reference them with the same name! The details: Creating multiple Docker images from the same Dockerfile and combining them with a manifestĪs we have already seen, it is possible, to reference multiple different images 1 with the same name, but of course we also want to make producing them as easy as possible as well by only using one Dockerfile. However the problem is, that GitHub currently only offers Windows Server 1809 based runners and while you can build 1809 images on a 2004 host using hyperv isolation, the other way doesn’t work. NET Core based services, we are using GitHub for version control and also GitHub actions. Some info on that can be found in my old blog post here.
linux/amd64, linux/arm64 and windows/amd64. On a side note, the same works for different architectures as well, e.g. If you want to use those images, you can just doĭocker run tobiasfenster/my-fantastic-image:1.0.0Īnd Docker will automatically decide, which one is the right image for you. The TL DRĪssuming that we have an image tobiasfenster/my-fantastic-image with two tags, 1.0.0-1809 (for Windows Server 1809) and 1.0.0-2004 (for Windows Server 2004), we can do something likeĭocker manifest create tobiasfenster/my-fantastic-image:1.0.0 tobiasfenster/my-fantastic-image:1.0.0-1809 tobiasfenster/my-fantastic-image:1.0.0-2004ĭocker manifest push tobiasfenster/my-fantastic-image:1.0.0 Fortunately, Docker has an (experimental) concept called manifests, that allows you to “hide” multiple tags behind one and let Docker decide, which is the right one. The easy approach is one image with “-1809” and one with “-2004” as suffix for the tag, but that is not exactly an elegant solution which has a couple of drawbacks. But if we want to start new instances on 2004 while keeping the older ones supported on 1809, that means that we have to create Docker images for our service tier on both versions. And while that works well, we also decided to take a look at newer Windows Server versions, namely Windows Server 2004. In our Azure DevOps & Docker Self-Service offering, we already have a couple of instances up and running, based on Windows Server 1809.