Add all Windows OS variants to better support process isolation on Windows

[StefanScherer]

Hey Phil,

what do you think about this idea. I would love to make the mquery tool available for all Windows OS variants. Only the Windows Server 2016 variant is listed in the manifest list of the mplatform/mquery image:

$ alias mq
alias mq='docker run --rm mplatform/mquery'

$ mq mplatform/mquery
Image: mplatform/mquery
 * Manifest List: Yes
 * Supported platforms:
   - linux/amd64
   - linux/arm
   - linux/arm64
   - linux/ppc64le
   - linux/s390x
   - windows/amd64:10.0.14393.1593

Well, I normally work on my MBP, but as Windows 10 now has process isolation to run Windows containers without the Hyper-V isolation it makes sense to have Windows images for the current Windows kernel version. Only then process isolation will work and people could use the mquery tool.

The golang image is an excellent example with all four Windows variants for 2016, 1709, 1803 and now 1809.

$ mq golang
Image: golang
 * Manifest List: Yes
 * Supported platforms:
   - linux/amd64
   - linux/arm/v7
   - linux/arm64
   - linux/386
   - linux/ppc64le
   - linux/s390x
   - windows/amd64:10.0.14393.2724
   - windows/amd64:10.0.16299.904
   - windows/amd64:10.0.17134.523
   - windows/amd64:10.0.17763.253

The technical challenge is that you normally need a Windows Docker host with the same or newer kernel than the Windows base image version. TL/DR you need a Windows Server 2019 or Windows 10, version 1809 to build for the latest 1809 nanoserver image. Older versions can be built in hyperv isolation mode.

I remember we have added an AppVeyor build some time ago, at the moment AppVeyor still only has Windows Server 2016 - the oldest variant.

But as a Captain this is not an impossible way. I wrote about a tool I use to create Windows images for all four variants with just AppVeyor. https://stefanscherer.github.io/poc-build-images-for-1709-without-1709/ This would work fine for this mquery tool. mquery is just a Golang binary in a nanoserver image. In this case I found out that it's fine to "rebase" the application layer on top of different Windows nanoserver images.

I do this with a multi-arch whoami service

$ mq stefanscherer/whoami
Image: stefanscherer/whoami
 * Manifest List: Yes
 * Supported platforms:
   - linux/amd64
   - linux/arm/v6
   - linux/arm64
   - windows/amd64:10.0.14393.2551
   - windows/amd64:10.0.16299.904
   - windows/amd64:10.0.17134.523
   - windows/amd64:10.0.17763.253

The complete AppVeyor build pipeline is available in https://github.com/StefanScherer/whoami

WDYT?

[estesp]

That seems totally reasonable. Let me see about getting the pipeline updated in mquery for that

[StefanScherer]

I played with Azure Pipelines over the last days. It seems they have Windows build agents for free for 2016, 1803 and 2019.

https://stefanscherer.visualstudio.com/azurepipelinetest/_build/results?buildId=79 shows the build for three Linux (amd64, arm, arm64) and three Windows (2016, 1803, 2019) images and then use docker manifest to push the manifest list

Sourcecode https://github.com/StefanScherer/azurepipelinetest, most relevant part is the azure-pipelines.yml file.

But AppVeyor plans to provide a 2019 machine end of this month, so maybe we can use them to build with --isolation=hyperv for all older Windows versions.

(Of course you can cross build mquery from linux/amd64, in Azure Pipelines I tried if it's possible to run arm Docker images with QEMU which works.)

[estesp]

@StefanScherer I'm curious now that we are in 2021 if I can get something assembled with GH Actions (Windows runners) to have an easier way to do this in context of GitHub packaging/push actions? I have a fairly large update (moved the backend to Lambda 😇 ) and a test image for Linux (mplatform/mquery:v0.3) pushed to DockerHub, but want to see if I can get the Windows side right before making this officially the "latest" image.

[StefanScherer]

@estesp Sure we should do some GitHub action magic here. I'll try something tomorrow.

[estesp]

I now have these 2 covered:

  - windows/amd64:10.0.17763.1817
  - windows/amd64:10.0.14393.4283

in the v0.4.0 release which is built from this github release action. The Dockerfiles for Windows are here in the packaging/ directory. Do you know what the proper FROM is to cover more Windows releases?

[estesp]

I should also mention I have not tested those images on any Windows system, although they were built with Docker on a Windows 2019 node in GitHub Actions. :)

[TBBle]

The current supported-version tags of the Nano Server base image are:

• 20H2
• 2004
• 1909
• 1809

So you could just have this for Dockerfile.windows:

ARG BASETAG=1809
FROM mcr.microsoft.com/windows/nanoserver:$BASETAG
COPY mquery.exe mquery.exe
ENTRYPOINT [ "mquery.exe" ]

and just call docker build three more times with the --build-arg parameter for the other three versions.

The only older still-supported Windows version is LTSC 2016, which you already have covered with Windows Server Core, as the nanoserver for that release was not an LTSC release and has terminated support already.

[StefanScherer]

Correct! The only problem is that you cannot build images that are based on a newer OS version than the host. So, you already have covered all up to 2019/1809.

But it would be possible to rebase them. The COPY and ENTRYPOINT are fine to be independent from the base image. I used my https://www.npmjs.com/package/rebase-docker-image in the past for that.

I saw that crane has a rebase option too, but I haven‘t used it for windows images yet. I don’t know if it is handling the foreign layers.