Windows Support

[fkorotkov]

Are there any plans to get official Windows Server images? Preferably based of microsoft/windowsservercore image?

[sfackler]

We'd definitely like to have them - the only blocker is figuring out how to make them actually work. There's an attempt here for example: alexcrichton@494237c

[nelsonjchen]

Is there a list of unresolved issues with that attempt?

[nelsonjchen]

🤷‍♂️

I guess a big one is that the build tools are kinda launched in a forked process on that branch and don't specify --wait, causing a premature killing of the intermediate build step and no VS stuff being installed. I'm saying this in case anyone wants to go ahead of me and bang on it. This was something I noticed by looking at examples of Windows Containers in GitHub installing the VS Build Tools.

I have a branch in my fork that definitely hacky, still doesn't work, and still a WIP. Need to rebase and it's kinda annoying that generated "artifacts" are in this repo.

[nelsonjchen]

My branch works, I can do that nifty "Compile your app inside the Docker container" but with Windows thing with the whole --rm thing at the bottom of the README but I don't have it backported to the generate.sh stuff yet. I think I'll go check out how the python Docker image works since they have a windows target there and see what they do.

[sfackler]

Awesome!

I cargo-culted a bunch of the setup here from the python and golang images, so they'd be good places to look for Windows setup as well.

[nelsonjchen]

By the way, if anyone is developing this on Windows 10 and not Windows Server:

If you're on 10 and 1809, replace the docker.exe and dockerd.exe executables from the latest builds of docker from the tip. Microsoft recently sent in a PR and licensing approval to remove Docker's artificial disablement of --isolation=process on Windows client SKUs from the daemon. It's not in Docker Edge yet as of this comment. This means faster development without the Hyper-V VM and visibility with Procmon and so on. Only supported for dev/test.

[nelsonjchen]

I've decided to drop nanoserver from my efforts. It'll probably be great for those multi-stage builds where someone compiles something with Rust from the bigger windowsservercore-based images and copies it to nanoserver for running/runtime but it's probably inappropriate for a build tool. I mean, do you see an alpine image for rust? Though, I guess there's debian slim and a hypothetical alpine version would kinda be oddly supported in a weird way. But this is Microsoft country, and it takes years for them to trim more fat.

[sfackler]

I mean, do you see an alpine image for rust?

The only reason there's no alpine image is that there isn't an x86_64-unknown-linux-musl rustc build yet. #10

[nelsonjchen]

Oh! I didn't see that.

[nelsonjchen]

There are some straggling issues left I guess.

• The MSVC variant probably can't be redistributed. IANAL. Technically you need to have a license to Visual Studio to use the build tools distributions. I think the output from this for this project might just be a Dockerfile licensed users can use and no more. I guess a more freely redistributable version would have to be Mingw based.
• Unfortunately, there does not appear to be a way to pin a MSVC or build tools 2017 version. For reproducibility reasons, this is worrying. You can pin the latest patched minor versions of N-1 minor versions 2017 tools but you can't pin the latest version or any of the patch releases. This really isn't great for reproducibility of builds. It's a bit more worrying if the limit for what can be distributed for these kinds of users are a Dockerfile.

[nelsonjchen]

The GNU variant was predictably crazy easy to implement and definitely not encumbered.

[nelsonjchen]

I have to take a break from this for now. If someone wants to take a crack at getting this upstreamed, have at it. There are MSVC and GNU Dockerfiles in here:

https://github.com/nelsonjchen/docker-rust/tree/windows

I am not sure how to get this integrated in with that generate-stackbrew-library.sh. What's the play here? Run that in WSL with Docker for Windows configured in a mode that supports both Linux and Windows containers exposed to the Docker client inside WSL? I just don't know.

[sfackler]

That just generates the metadata blob that goes over to the docker-library/official-images repo - it doesn't need to run in the same OS as the docker image or anything.

[nelsonjchen]

Oops, I meant update.sh, it depends on something called bashbrew and I'm not familiar with that yet.

[sfackler]

Similarly, update.sh can create a Dockerfile for a Windows image without being run on Windows.

Bashbrew is here: https://github.com/docker-library/official-images/tree/master/bashbrew