EPIC: New Machine requirement: Windows dockerBuild containers

[sxa]

I need to request a new machine:

• New machine operating system (e.g. linux/windows/macos/solaris/aix): Windows
• New machine architecture (e.g. x64/aarch32/arm32/ppc64/ppc64le/sparc): x64
• Provider (leave blank if it does not matter): Docker :-)
• Desired usage: Build containers, similar to what we have for Linux
• Any unusual specification/setup required:
• How many of them are required: n/a - they should be created dynamically

Please explain what this machine is needed for:
Running builds in an isolated way where we can achieve SLSA build level 3 compliance on Windows along with the other primary platforms. Ideally we'll be able to create windows-on-windows container images which we share and then download and run the builds in.

As background info:

• https://learn.microsoft.com/en-us/virtualization/windowscontainers/quick-start/set-up-environment?tabs=dockerce#windows-server-1 looks to be a good resource on the software options for containers on Windows
• Eclipse Temurin does provide container images for Windows at https://hub.docker.com/_/eclipse-temurin/ - these are created from the dockerfiles in https://github.com/adoptium/containers/tree/main/21/jdk/windows which may give a good starting point for this work on investigating windows containers.

So the tasks required would be:

• Identify the appropriate software for running containers and ensure no licensing concerns (Likely something from the microsoft site linked above)
• See if we can verify that a "basic" dockerfile works in that environment and whether we can map directories into it (same as -v on linux) which are read+write in the container
• Determine whether we can create a container from the playbooks using a dockerfile equivalent to the Linux ones
• Once we create the container, map a directoryi from the host into it with -v and use that to build Temurin in the container on the mapped volume so that the output is visible on the host system.
• Understand whether we can reasonably push the resulting container images with the compiler up to dockerhub [Answer: We will push them to gcr.io and mirror to azurecr for better performance on azure dynamic machines.]
• Integrate this into the build pipelines
• Implement processes to regenerate the images when playbook updates are made, - likely an addition to what we do for Linux in https://github.com/adoptium/infrastructure/blob/master/FAQ.md#what-about-the-builds-that-use-the-dockerbuild-tag
• Declare SLSA Build level 3 on Windows :-)

Once this level of analysis and expertise is gained it will likely make windows installer testing, or any other such activities simpler and give us more options moving forward.

Related for historic reference:

• Remove deprecated Windows 2016 Docker image (O/S no longer in support) #2440
• github: cleanup GH Action on windows-2016 #2556

[RadekCap]

Please, assign this task to me. Thank you.

[sxa]

Of the three options listed on the Microsoft website:

• The first (Docker CE / Moby) seems to work well out of the box
• The second (Mirantis) appears to be a commercial offering
• The third (Containerd+nerdctl) appers functional although networking doesn't work out of the box and it seems to fail to be able to start the eclipse-temurin container's default jshell process.

[sxa]

OK First phase done ...

• docker run -p 5986:5986 -v c:\Users\sxa:c:\sxa mcr.microsoft.com/windows/servercore:ltsc2022
• Run ConfigureRemotingForAnsible.ps1 with the usual parameters with the netsh commands disabled (They require windows defender which isn't in the image)
• Create a user to connect with for the playbooks (MyPassword is not what I've used on the live system!):

net user ansible MyPassword /ADD
net localgroup "Administrators" ansible /ADD
net localgroup "Remote Management Users" ansible /ADD

This allows the machine to be accessible via ansible running on a remote machine :-)

(Also, for my own notes, to debug powershell scripts use Set-PSDebug -Trace 2)

[sxa]

Playbook execution notes:

• VS2013 requires the archive under /Vendor_Files/windows, otherwise MSVS_2013 needs to be skipped
• NTP_TIME needs to be skipped as that has issues that are presumably related to running in a container: FAILED! => {"changed": false, "msg": "Unhandled exception while executing module: Service 'Windows Time (W32Time)' cannot be started due to the following error: Cannot start service W32Time on computer '.'."}
• In the absence of the fixed layout files for VS2019 and VS2022, adoptopenjdk needs to be skipped to allow them to complete successfully