GeezerVison

Got AppVeyor setup on my fork: https://ci.appveyor.com/project/LaurentGoderre/docker-node/history

@StefanScherer I just added the multiple versions of nanoserver and servercore, though I don't have aliases setup in stackbrew yet

And here is the build: https://ci.appveyor.com/project/LaurentGoderre/docker-node/build/1.0.138

Very good. But at the moment AppVeyor cannot be used to build 1709 or 1803 images. The plan is to add a Windows 10 1803 build agent and allow hyperv isolation, so maybe we can build such images in the near future with AppVeyor.

@StefanScherer can we try getting those Windows image working without Multi-stage for now?

@LaurentGoderre It depends. You could build a node image based on windowsservercore by removing the second FROM and the two COPY instructions. But then gpg tools are also installed in the image.
When you start building multi-line RUN instructions to download GPG, install it, run it and remove it then this layer still has a lot of temporary artifacts with GPG binaries I guess. MSI packages and EXE installers normally cache these things at a second place on disk.

For a nanoserver image the GPG tools won't work (MSI/EXE installer, probably only 32bit). An image based on microsoft/nanoserver:sac2016 could work.

For Windows builds I really depend on multi-stage builds (or at least the old fashioned way with docker build -t download ; docker create / docker cp ; docker build -t final to ship a usable and small image.
Having only a fat image gives a very poor experience for Windows developers (downloading 6 GB image...)

6GB??? What artifacts causes this?

If we want Windows images soon, we don't have much choice but to forgo the Multi-stage until they are supported for official-images.

6GB is when someone wants to pull or create a „tiny“ node hello world app on a fresh Windows 10 or 2016 server. This is the windowsservercore image which weighs so much.

I know the hard constraint for official images. But it‘s a solvable problem in the (more or less small) CI pipeline compared to the benefit for the whole Windows community getting a great and fast experience.

I can't solve the multibuild but i can try to solve the images. Right now the install works on nanoserver but the subsequent call to gpg fails, as if it isn't aware of the change to $PATH

You can check binaries with the NanoServer API Scan tool. I‘ve built an image for such tasks.
32bit binaries can‘t be used in NanoServer.
But maybe only a runtime DLL is missing.

@StefanScherer do you know if there's a way to get access to a cloud version of Windows 10 Enterprise so I could test this without appveyor? I discovered I have PowerShell on my workmachine (which mildly shocked me) so that part is now easier, but the docker part is still hard.

@LaurentGoderre You could use the 30 days trial at Azure to spin up Windows 10 Pro 1803 which should be good enough to use containers. Use eg. a Standard_D2_v3 (or bigger) instance type which has nested Hyper-V support to be able to run eg. Docker for Windows in such an Azure instance.
Otherwise DM me via email.

@StefanScherer what is the benefit of having Windows Containers where there are already Linux Containers, especially since LCOW is now possible - (appveyor does support this on a paid plan).

@swissarmykirpan It all depends on your application and environment. When one of your node modules needs Windows API then it's good to have same packaging as Docker image as on Linux.
When you can run your app in Linux containers then I recommend a Linux VM and not LCOW.
But it all depends on your environment, the servers and OS you can choose etc.

@LaurentGoderre Yesterday I saw that the golang image has several Windows versions supported. Now that the Windows Server 2019 images are a lot smaller it gets more interesting to stay at the servercore variant for a first release.

Is the build infra for the official node images also able to build for Windows Server 2019? I may have asked that years ago if you use the same infra as eg. for the other official Docker images? :-)

So if there is support for at least Windows Server 2016 and 2019 I could help to get this done as it makes sense to me.

Ok, a version without multi-stage build, so far so good.

One obstacle is that nanoserver no longer has PowerShell support, the 1809 images now have curl.exe and tar.exe in a CMD shell, but scripting all the GPG loop will be painful in just cmd scripts.

So maybe drop the nanoserver image and just use mcr.microsoft.com/windows/servercore:ltsc2016 and mcr.microsoft.com/windows/servercore:ltsc2019

WDYT?

Is the build infra for the official node images also able to build for Windows Server 2019? I may have asked that years ago if you use the same infra as eg. for the other official Docker images?

We have our own CI to test PRs, but the official images (the ones you pull down) are built by Docker on their own infra

Thanks @SimenB

Do you think it would be possible to check PR's for Windows Server 2016 only on your side and let the Docker infra build all four Windows variants to provide a manifest list like the golang?

$ docker run --rm mplatform/mquery node
Image: node
 * Manifest List: Yes
 * Supported platforms:
   - linux/amd64
   - linux/arm/v7
   - linux/arm64
   - linux/ppc64le
   - linux/s390x

$ docker run --rm mplatform/mquery 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.2665
   - windows/amd64:10.0.16299.846
   - windows/amd64:10.0.17134.469
   - windows/amd64:10.0.17763.194

There are 2016, 1709, 1803 and 1809 variants there, so on any Windows Version it picks the best fitting image (just like working on different Linux CPU architectures).

Windows Server 2019 / Windows 10 1809 brings so many bugfixes for Node.js on Windows (the mapped folders for source code from the host work, port mapping to localhost works, docker pull and extract is faster than on 2016, ...).

And then we have to choose which PR we want to update, this one or #362.

FYI, for testing Windows images, we've used AppVeyor for a long time (https://github.com/docker-library/golang/blob/60879215d473711ae500cc43acbfa037cf808fb0/.appveyor.yml), but they only currently support the LTSC release of 2016.

Travis recently (https://blog.travis-ci.com/2018-10-11-windows-early-release) added support for Windows with 1803 (https://github.com/docker-library/golang/blob/60879215d473711ae500cc43acbfa037cf808fb0/.travis.yml#L6-L8), which makes it easier to run similar tests across both Windows and Linux, even with Docker. 👍

Any plans on merging this?

This PR is now many years old, and the original submitter is no longer active in this repo.

I suggest to close the PR. It has multiple conflicts requiring a complete rework.
The requirements for Windows Docker images should also be revisited.

The versions of Node.js that the PR targets (6, 8, 9, 10) are now all in end-of-life status.

Travis & Appveyor CI are no longer considered mainstream, and GitHub Actions would probably be the CI provider of choice.

Yarn has been dropped from new images.

There were no objections to closing, so now going ahead.