windowsservercore variants support

Question

windowsservercore variants support

Closed this issue 3 years ago · 10 comments

Hello,

A user opened a PR on our repo to add some windowsservercore variants (2004, 1909, 1904, 1809, ltsc2019)

I checked the official-images repo, and I only see 2 variants used: windowsservercore-ltsc2016 and windowsservercore-1809

Is it possible to use those variants inside the official Docker images build system?

Answer 1 · 2020-12-02T20:30:14.000Z

We only have one Windows VM for builds and it is running LTSC 2019 (aka 1809). So, we cannot build anything other than ltsc2016 and 1809 since there hasn't been a newer LTSC. 😞

Related: docker-library/golang#289

https://winreleaseinfoprod.blob.core.windows.net/winreleaseinfoprod/en-US.html

Answer 2 · 2020-12-02T21:59:50.000Z

maybe @StefanScherer can help here?

Answer 3 · 2020-12-02T22:13:48.000Z

It's more of a fundamental Windows issue for us -- the semi-annual channel doesn't support in-place upgrades, so our best workaround idea has been to run Windows 10 instead of Server, but that's not well-supported in cloud environments.

Answer 4 · 2020-12-02T22:20:53.000Z

That’s a painpoint on Windows. With a 1809 host you cannot build images with newer base images.

A Windows Server version 2004 would be required to build all variants. Hard to get such a machine due to the licensing. There are Azure VM images provided by MSFT, but probably not easy to use in the build infrastructure.

For my own Windows images that only require nanoserver, I used a different approach. I „rebase“ the application layers on top of newer base layers with a small tool. Absolute experimental and not recommended to provide official images, otherwise you really know what you‘re doing 😅

I know that portainer uses my tool as well, eg. https://hub.docker.com/layers/portainer/portainer-ce/2.0.0/images/sha256-8e1b979bc8e80127196304ffe6e5ae5b3d333887b1bde588d06615cef3b7c52a?context=explore gas variants 1809, 1903, 1909, and 2004.

My dockerfiles-windows github repo also uses this technique for a few images. But traefik needs one additional dll due to the golang bug. It‘s all very complicated.

So the TL/DR would be that it‘s not possible for official images.
But don‘t hesitate to ping me if you want to know more and go that route. 😊

Answer 5 · 2020-12-02T22:34:32.000Z

Ugly. Very ugly... 😐 Then I'll just use my own traefik images and hope for the best...

Answer 6 · 2021-08-20T01:01:39.000Z

@StefanScherer Hi! Could you please tell us where we can download your useful application to "rebase" images?

Answer 7 · 2021-08-20T07:59:21.000Z

@VuiDJi It's a NPM package, you can see an example here https://github.com/StefanScherer/whoami/blob/main/deploy.ps1#L35
But I haven't used it for a while.

Answer 8 · 2021-08-20T23:35:12.000Z

Now that we've got Windows Server 2022 (and maybe the death of that SAC confusion???) this might be easier to resolve! 👀

(actions/runner-images#3929 is a useful link for GitHub Actions support, which is not a blocker by any means, but it definitely helps to ensure things will probably work after we merge them 😅)

Answer 9 · 2021-08-24T21:37:38.000Z

We have set up a fresh new Server 2022 builder to replace our existing 2019 builder. We can now handle Constraints: windowsservercore-ltsc2022 and/or nanoserver-ltsc2022. 👍

Answer 10 · 2021-08-24T22:26:26.000Z

#10783 👀 (first image officially adding 2022)