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.

Docker windows base image