Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce windows images #362

Closed

Conversation

StefanScherer
Copy link

This PR introduces Dockerfiles for both Windows base OS images windowsservercore and nanoserver.

You can use AppVeyor for test builds like the Travis builds for Linux. The appveyor.yml is provided with this PR. It runs test-build.ps1 which builds and tests the images like the test-build.sh script.

See https://ci.appveyor.com/project/StefanScherer/docker-node for an example.

Supersedes #222 and #223

@chorrell
Copy link
Contributor

A couple of things we'll need to think about:

  • Updating the update.sh script to include the new windows variants
  • Updating the generate-stackbrew-library.sh script to generate the appropriate tags for the windows variants

@pesho
Copy link
Contributor

pesho commented Mar 22, 2017

Updating the update.sh script to include the new windows variants

This would also involve updating their SHA256-sums which are used instead of GPG signature checking.

@StefanScherer
Copy link
Author

I keep the Windows Dockerfiles up to date with this update.sh
https://github.com/StefanScherer/dockerfiles-windows/blob/master/node/update.sh
This might help adding it to the update shell script.

@StefanScherer
Copy link
Author

We could switch over to GPG signature checking for Windows as well. But I only found https://www.gpg4win.org/package-integrity.html which burries the gpg.exe into a exe installer and eventually not working in Nanoserver. It is complex to get rid of the temporary exe installer again I guess.

But once we have PR moby/moby#31257 in offical Docker engine we could run the gpg installer in windowsservercore, then download and check GPG signature and extract the ZIPs and finally draft small windowsservercore and nanoserver images with multiple FROM instructions.

In my dockerfiles repo I could switch to this approach as I'm using AppVeyory and can switch to master builds of dockerd.exe very easily.

@StefanScherer
Copy link
Author

StefanScherer commented Apr 1, 2017

That would be a way to do it. See a proof-of-concept at

which does the gpg installation, adding the gpg keys, downloading SHA256SUMS.txt.asc checking the signature and grepping the checksum for the zip file and the final sha256 check itself.

@SimenB
Copy link
Member

SimenB commented Jul 22, 2017

@StefanScherer could you include updates to the files @chorrell mentions?

You can look at the python repo for examples of update.sh and generate-stackbrew-library.sh with Windows support. https://github.com/docker-library/python

@StefanScherer StefanScherer force-pushed the introduce-windows-images branch 2 times, most recently from 2dab140 to 3d6a793 Compare July 23, 2017 10:10
@StefanScherer
Copy link
Author

@SimenB I've updated the update.sh and generate-stackbrew-library.sh and added Windows templates to generate all version from them. The Windows builds use multi-stage builds with Docker 17.06.1-ee-1-rc1 in AppVeyor, the final EE version should be available soon.
Travis and AppVeyor build https://ci.appveyor.com/project/StefanScherer/docker-node/build/1.0.10 are green.

@SimenB
Copy link
Member

SimenB commented Jul 23, 2017

@nodejs/docker any reason not to merge this? If not, how do we handle CI?

@tianon does this look correct to you? Is using multi-stage builds ok?

@SimenB
Copy link
Member

SimenB commented Jul 23, 2017

@StefanScherer could you paste the output from running generate-stackbrew-library.sh here for verification?

Edit: oops, wrong tag. Fat thumbs!

@StefanScherer
Copy link
Author

Maybe I should add Yarn as well?

@SimenB
Copy link
Member

SimenB commented Jul 23, 2017

Maybe I should add Yarn as well?

Definitely!

SimenB

This comment was marked as off-topic.

SimenB

This comment was marked as off-topic.

@StefanScherer
Copy link
Author

@SimenB This is the output of generate-stackbrew-library.sh

$ ./generate-stackbrew-library.sh 
# this file is generated via https://github.com/nodejs/docker-node/blob/6912e1204a853e38e9439e849ef73a4a569f7b85/generate-stackbrew-library.sh

Maintainers: The Node.js Docker Team <https://github.com/nodejs/docker-node> (@nodejs)
GitRepo: https://github.com/nodejs/docker-node.git

Tags: 8.2.1, 8.2, 8, latest
Architectures: amd64, ppc64le
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 8.2

Tags: 8.2.1-alpine, 8.2-alpine, 8-alpine, alpine
Architectures: amd64
GitCommit: f547c4c7281027d5d90f4665815140126e1f70d5
Directory: 8.2/alpine

Tags: 8.2.1-onbuild, 8.2-onbuild, 8-onbuild, onbuild
Architectures: amd64, ppc64le, windows-amd64
GitCommit: f547c4c7281027d5d90f4665815140126e1f70d5
Directory: 8.2/onbuild

Tags: 8.2.1-slim, 8.2-slim, 8-slim, slim
Architectures: amd64, ppc64le
GitCommit: f547c4c7281027d5d90f4665815140126e1f70d5
Directory: 8.2/slim

Tags: 8.2.1-wheezy, 8.2-wheezy, 8-wheezy, wheezy
Architectures: amd64
GitCommit: f547c4c7281027d5d90f4665815140126e1f70d5
Directory: 8.2/wheezy

Tags: 8.2.1-windowsservercore, 8.2-windowsservercore, 8-windowsservercore, windowsservercore
Architectures: windows-amd64
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 8.2/windows/windowsservercore

Tags: 8.2.1-windowsservercore-onbuild, 8.2-windowsservercore-onbuild, 8-windowsservercore-onbuild, windowsservercore-onbuild
Architectures: windows-amd64
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 8.2/windows/windowsservercore/onbuild

Tags: 8.2.1-nanoserver, 8.2-nanoserver, 8-nanoserver, nanoserver
Architectures: windows-amd64
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 8.2/windows/nanoserver

Tags: 8.2.1-nanoserver-onbuild, 8.2-nanoserver-onbuild, 8-nanoserver-onbuild, nanoserver-onbuild
Architectures: windows-amd64
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 8.2/windows/nanoserver/onbuild

Tags: 7.10.1, 7.10, 7
Architectures: amd64, ppc64le
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 7.10

Tags: 7.10.1-alpine, 7.10-alpine, 7-alpine
Architectures: amd64
GitCommit: 0aadad9c44ff26afc81469d77df9b948be47c312
Directory: 7.10/alpine

Tags: 7.10.1-onbuild, 7.10-onbuild, 7-onbuild
Architectures: amd64, ppc64le, windows-amd64
GitCommit: 0fcdf0b2660e73ab1054f932f4beac5b3946fb21
Directory: 7.10/onbuild

Tags: 7.10.1-slim, 7.10-slim, 7-slim
Architectures: amd64, ppc64le
GitCommit: 0aadad9c44ff26afc81469d77df9b948be47c312
Directory: 7.10/slim

Tags: 7.10.1-wheezy, 7.10-wheezy, 7-wheezy
Architectures: amd64
GitCommit: 0aadad9c44ff26afc81469d77df9b948be47c312
Directory: 7.10/wheezy

Tags: 7.10.1-windowsservercore, 7.10-windowsservercore, 7-windowsservercore
Architectures: windows-amd64
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 7.10/windows/windowsservercore

Tags: 7.10.1-windowsservercore-onbuild, 7.10-windowsservercore-onbuild, 7-windowsservercore-onbuild
Architectures: windows-amd64
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 7.10/windows/windowsservercore/onbuild

Tags: 7.10.1-nanoserver, 7.10-nanoserver, 7-nanoserver
Architectures: windows-amd64
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 7.10/windows/nanoserver

Tags: 7.10.1-nanoserver-onbuild, 7.10-nanoserver-onbuild, 7-nanoserver-onbuild
Architectures: windows-amd64
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 7.10/windows/nanoserver/onbuild

Tags: 6.11.1, 6.11, 6, boron
Architectures: amd64, ppc64le
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 6.11

Tags: 6.11.1-alpine, 6.11-alpine, 6-alpine, boron-alpine
Architectures: amd64
GitCommit: bb200caf20280e436dedc56a5f194fd21e684758
Directory: 6.11/alpine

Tags: 6.11.1-onbuild, 6.11-onbuild, 6-onbuild, boron-onbuild
Architectures: amd64, ppc64le, windows-amd64
GitCommit: bb200caf20280e436dedc56a5f194fd21e684758
Directory: 6.11/onbuild

Tags: 6.11.1-slim, 6.11-slim, 6-slim, boron-slim
Architectures: amd64, ppc64le
GitCommit: bb200caf20280e436dedc56a5f194fd21e684758
Directory: 6.11/slim

Tags: 6.11.1-wheezy, 6.11-wheezy, 6-wheezy, boron-wheezy
Architectures: amd64
GitCommit: bb200caf20280e436dedc56a5f194fd21e684758
Directory: 6.11/wheezy

Tags: 6.11.1-windowsservercore, 6.11-windowsservercore, 6-windowsservercore, boron-windowsservercore
Architectures: windows-amd64
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 6.11/windows/windowsservercore

Tags: 6.11.1-windowsservercore-onbuild, 6.11-windowsservercore-onbuild, 6-windowsservercore-onbuild, boron-windowsservercore-onbuild
Architectures: windows-amd64
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 6.11/windows/windowsservercore/onbuild

Tags: 6.11.1-nanoserver, 6.11-nanoserver, 6-nanoserver, boron-nanoserver
Architectures: windows-amd64
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 6.11/windows/nanoserver

Tags: 6.11.1-nanoserver-onbuild, 6.11-nanoserver-onbuild, 6-nanoserver-onbuild, boron-nanoserver-onbuild
Architectures: windows-amd64
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 6.11/windows/nanoserver/onbuild

Tags: 4.8.4, 4.8, 4, argon
Architectures: amd64, ppc64le
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 4.8

Tags: 4.8.4-alpine, 4.8-alpine, 4-alpine, argon-alpine
Architectures: amd64
GitCommit: 3ffba881ad5a78d33b8edf888d5406222b60686e
Directory: 4.8/alpine

Tags: 4.8.4-onbuild, 4.8-onbuild, 4-onbuild, argon-onbuild
Architectures: amd64, ppc64le, windows-amd64
GitCommit: 3ffba881ad5a78d33b8edf888d5406222b60686e
Directory: 4.8/onbuild

Tags: 4.8.4-slim, 4.8-slim, 4-slim, argon-slim
Architectures: amd64, ppc64le
GitCommit: 3ffba881ad5a78d33b8edf888d5406222b60686e
Directory: 4.8/slim

Tags: 4.8.4-wheezy, 4.8-wheezy, 4-wheezy, argon-wheezy
Architectures: amd64
GitCommit: 3ffba881ad5a78d33b8edf888d5406222b60686e
Directory: 4.8/wheezy

Tags: 4.8.4-windowsservercore, 4.8-windowsservercore, 4-windowsservercore, argon-windowsservercore
Architectures: windows-amd64
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 4.8/windows/windowsservercore

Tags: 4.8.4-windowsservercore-onbuild, 4.8-windowsservercore-onbuild, 4-windowsservercore-onbuild, argon-windowsservercore-onbuild
Architectures: windows-amd64
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 4.8/windows/windowsservercore/onbuild

Tags: 4.8.4-nanoserver, 4.8-nanoserver, 4-nanoserver, argon-nanoserver
Architectures: windows-amd64
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 4.8/windows/nanoserver

Tags: 4.8.4-nanoserver-onbuild, 4.8-nanoserver-onbuild, 4-nanoserver-onbuild, argon-nanoserver-onbuild
Architectures: windows-amd64
GitCommit: 3d6a793311fdb9e3e4a18edf97a3fab429be638c
Directory: 4.8/windows/nanoserver/onbuild

@StefanScherer
Copy link
Author

I had a look at Yarn how to install it on Windows. I can't take the similar way as on Linux, there is no *.asc file and there is only a MSI package. But they provide a Chocolatey package that does the download + checksum check here.
So in the multi-stage build we easily can use Chocolatey.
For the MSI package we definitely should use multi-stage build as an MSI installation leaves a backup of the MSI in another folder and msiexec is not available in the nanoserver image as shown here.

yhwang

This comment was marked as off-topic.

yhwang

This comment was marked as off-topic.

@StefanScherer
Copy link
Author

Oh, a choco install -y yarn -version 0.27.5 would also install Node.js choco package. This approach becomes more and more complicated.
Downloading the MSI manually I can't find a checksum or GPG signature.

Should we ask the Yarn team to provide a GPG signature for the MSI package?

@StefanScherer
Copy link
Author

@yhwang Don't worry. Adding AppVeyor CI would help testing further pull requests for the Windows images. I have added an appveyor.yml and also activated it for my fork to build each commit. The output of this PR build on AppVeyor can be found here and does verify the build of all Windows images and a simple test, just like in the test-build.sh.

Think of AppVeyor = Travis, but for Windows :-)

@SimenB
Copy link
Member

SimenB commented Jul 23, 2017

Do we need to use the msi? Why not just download the JS file (that's what the other images do, right?)?

/Cc @Daniel15 as he has done lots of work on yarn packaging (and use Windows!)

@StefanScherer
Copy link
Author

I thought about npm install -g yarn@$env:YARN_VERSION but this is not recommended as noted in https://yarnpkg.com/en/docs/install#alternatives-tab.
The Linux images download the .tar.gz + GPG signature .tar.gz.asc and verify the download with it.

@SimenB
Copy link
Member

SimenB commented Jul 23, 2017

The Linux images download the .tar.gz + GPG signature .tar.gz.asc and verify the download with it.

Why can't we do the same for windows? AFAIK there are no native dependencies, it should be pure JS

@StefanScherer
Copy link
Author

@SimenB Good idea. Yes, even the .tar.gz has the yarn.cmd which is needed on Windows.

root@b77d7633e398:/# ls -l /opt/yarn/bin/
total 20
-rwxr-xr-x 1 node node 868 Jun 30 23:28 yarn
-rw-r--r-- 1 node node  34 Jun 30 23:28 yarn.cmd
-rwxr-xr-x 1 node node 177 Jun 30 23:28 yarn.js
-rwxr-xr-x 1 node node  42 Jun 30 23:28 yarnpkg
-rw-r--r-- 1 node node  30 Jun 30 23:28 yarnpkg.cmd

@StefanScherer
Copy link
Author

Still not so easy, I need 7-Zip to extract the .tar.gz 😂

@JustinBeckwith
Copy link

I know this issue has been floating around for a while, but we're really excited to see something like this land :) Anything we can do to help?

@SimenB
Copy link
Member

SimenB commented Jun 28, 2019

docker-library/official-images#5929 has landed, so we should be able to use multi-staged builds now. @StefanScherer wanna refresh this?

@StefanScherer
Copy link
Author

Thanks @SimenB for the heads-up. That are very good news. A lot things changed since then, a lot of base images for different Windows OS versions are available, nanoserver:sac2016 and 1709 is already deprecated.

Do you know if this repo also has access to multiple Windows Server versions? The golang repo uses eg. %%MICROSOFT-TAG%% (update.sh line 116) to create multiple Windows Dockerfiles and to build images for Windows Server 1803, 1809 and 2016 (update.sh line 109-110).

@SimenB
Copy link
Member

SimenB commented Jun 28, 2019

I don't know, maybe @tianon could chime in? 🙂

@PeterDaveHello
Copy link
Member

If any other official images can, I believe that we also can, just need help from official image team.

Maybe we can resolve some of the conflicts first?

@LaurentGoderre
Copy link
Member

The main obstacles at the time was that there was that we were unable to install a GPG tool to validate the download on nanoserver.

@tianon
Copy link
Contributor

tianon commented Jul 3, 2019

I would recommend just ditching PGP verification for Windows -- IMO the added overhead of installing a tool isn't worth the benefit (a SHA256 or similar should be sufficient).

What I'd recommend for getting Nano Server accepted here is to structure this with Windows Server Core variants that Nano Server uses via COPY --from=node:....

See docker-library/openjdk@e4f01b5 for an example of this approach I've just played with over on OpenJDK (although that one will ultimately likely not end up getting published due to https://bugs.openjdk.java.net/browse/JDK-8218486 / https://bugs.openjdk.java.net/browse/JDK-8225425 which still plagues even OpenJDK 13 -- Nano Server really just doesn't seem to be actually supported by OpenJDK, and I'd caution only going forward with Nano Server here if the Node.js community is going to support Nano Server officially).

@Daniel15
Copy link

Daniel15 commented Jul 3, 2019

Do you even need PGP verification on Windows, if you're using Authenticode verification?

@nschonni
Copy link
Member

nschonni commented Jul 4, 2019

I have a version with MSI and Authenticode in #827, but that won't work on nanoserver

@SimenB
Copy link
Member

SimenB commented Jul 4, 2019

I'd caution only going forward with Nano Server here if the Node.js community is going to support Nano Server officially

@nodejs/build is this something you can chime in on?


Regardless of ^, we could start with windowsservercore versions and add nanoserver later if that makes sense?

@mhdawson
Copy link
Member

mhdawson commented Jul 4, 2019

I've not seen any discussion of nanoserver on the Node side and there are no instances in our CI. @joaocgreis is this in your plans at all?

@joaocgreis
Copy link
Member

It might be possible to add Nano Server to CI, we are looking into this.

cc @MichelLopez

@StefanScherer
Copy link
Author

Well, for nanoserver you only need a Windows Server 2016/2019 with Docker engine, then you can run nanoserver containers. There is no nanoserver OS anymore, only as a lightweight container image.

@dmbarry86
Copy link

What's the latest status with this PR? Doesn't appear to have been any activity for quite a while. I ask because I am looking for exactly this image (node + windowsservercore) for one of our projects.

Base automatically changed from master to main March 15, 2021 16:23
@behroozbc
Copy link

hi dont any update about it??

@cmaneu
Copy link

cmaneu commented Feb 17, 2022

Hello @StefanScherer,
I saw you have closed this PR quite recently, however I haven't seen any progress on the related #827 and #720.

This issue is somewhat blocking the release of a product here at Microsoft (it creates a sub-par experience where we have to embed nodejs in our image instead of using an official image). I'm willing to spend some engineering time needed to make this happen.

What was the reasoning behind closing this PR, except the fact it was open quite a long time ago? What is needed to get a Windows-based NodeJS image?

Thanks in advance for your answer!

@SimenB
Copy link
Member

SimenB commented Feb 17, 2022

@tianon @yosifkit any new thoughts on this, or is #362 (comment) still the current state of affairs? Any versions you recommend (or not)?

@tianon
Copy link
Contributor

tianon commented Feb 17, 2022

My suggestion would be to start with a Windows Server Core version and only doing checksum validation (which can be done in raw PowerShell -- I can provide examples if necessary). I'm willing to work on an initial version from what Stefan's built here too, if you want.

@cmaneu
Copy link

cmaneu commented Feb 21, 2022

@tianon let me know if you need anything from me (pair programming, testing on different Windows VMs, ...).

@tianon
Copy link
Contributor

tianon commented Feb 24, 2022

Here's a first pass: (verbose on the Write-Host invocations because we otherwise don't get any indication of what's happening, and Complete. at the end because there's often a large delay between "the command exited" and "the layer is saved" during which it just hangs)

FROM mcr.microsoft.com/windows/servercore:1809

SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"]

# PATH isn't actually set in the Docker image, so we have to set it from within the container
RUN $newPath = ('C:\nodejs;{0}\Yarn\bin;{1}' -f $env:LOCALAPPDATA, $env:PATH); \
	Write-Host ('Updating PATH: {0}' -f $newPath); \
	[Environment]::SetEnvironmentVariable('PATH', $newPath, [EnvironmentVariableTarget]::Machine)
# doing this first to share cache across versions more aggressively

ENV NODE_VERSION 17.6.0
ENV NODE_SHA256 eb9ff1dde916436716fe9054e6b5fd310e7f6bac3599bbd0cb335d4ac8b0cc96

RUN $url = ('https://nodejs.org/dist/v{0}/node-v{0}-win-x64.zip' -f $env:NODE_VERSION); \
	Write-Host ('Downloading {0} ...' -f $url); \
	Invoke-WebRequest -Uri $url -OutFile 'node.zip'; \
	\
	Write-Host ('Verifying sha256 ({0}) ...' -f $env:NODE_SHA256); \
	if ((Get-FileHash node.zip -Algorithm sha256).Hash -ne $env:NODE_SHA256) { throw 'SHA256 mismatch' }; \
	\
	Write-Host 'Expanding ...'; \
	Expand-Archive node.zip -DestinationPath C:\; \
	\
	Write-Host 'Renaming ...'; \
	Rename-Item -Path ('C:\node-v{0}-win-x64' -f $env:NODE_VERSION) -NewName 'C:\nodejs'; \
	\
	Write-Host 'Removing ...'; \
	Remove-Item node.zip -Force; \
	\
	Write-Host 'Verifying ("node --version") ...'; \
	node --version; \
	Write-Host 'Verifying ("npm --version") ...'; \
	npm --version; \
	\
	Write-Host 'Complete.'

ENV YARN_VERSION 1.22.17

# "It is recommended to install Yarn through the npm package manager" (https://classic.yarnpkg.com/en/docs/install)
RUN Write-Host 'Installing "yarn" ...'; \
	npm install --global ('yarn@{0}' -f $env:YARN_VERSION); \
	\
	Write-Host 'Verifying ("yarn --version") ...'; \
	yarn --version; \
	\
	Write-Host 'Complete.'

CMD [ "node" ]

One fun quirk here (that's a quirk of Windows containers in general) is that you can RUN yarn ..., docker run ... cmd /c yarn ..., docker run ... powershell -Command yarn ..., and even docker run ... yarn.cmd ... but you cannot docker run ... yarn ... (I tried to chase the details of this a little, but it got deep enough that I ran out of spoons).

@s-weigand
Copy link

s-weigand commented Jun 16, 2022

@tianon Thanks a lot your Dockerfile works gr8 🎉

I only encountered one problem when using parcel-bundler because vc_redist is missing

So one should also add something like this to the Dockerfile

RUN $url = 'https://aka.ms/vs/17/release/vc_redist.x64.exe'; \
	Write-Host ('Downloading {0} ...' -f $url); \
	Invoke-WebRequest -Uri $url -OutFile vcredist_x64.exe; \
	\
	Write-Host ('Installing vcredist_x64.exe ...'); \
	Start-Process -filepath "vcredist_x64.exe" -ArgumentList "/install", "/passive", \
	"/norestart", "'/log c:/temp/a.txt'" -PassThru | wait-process; \
	\
	Write-Host 'Removing vcredist_x64.exe ...'; \
	Remove-Item vcredist_x64.exe -Force; \
	\
	Write-Host 'Complete.'

I put it before the node installation for caching reasons

@Coconaut5
Copy link

Whats the status on this? Will node never host images compatible for docker-windows?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.