In Windows Server Insider Preview Build 17074 released on Tuesday Jan 16, 2018, there are some exciting improvements to Windows Server containers that we’d like to share with you. We’d love for you to test out the build, especially the Windows Server Core container image, and give us feedback!
Windows Server Core Container Base Image Size Reduced to 1.58GB!
You told us that the size of the Server Core container image affects your deployment times, takes too long to pull down and takes up too much space on your laptops and servers alike. In our first Semi-Annual Channel release, Windows Server, version 1709, we made some great progress reducing the size by 60% and your excitement was noted. We’ve continued to actively look for additional space savings while balancing application compatibility. It’s not easy but we are committed.
There are two main directions we looked at:
1) Architecture optimization to reduce duplicate payloads
We are always looking for way to optimize our architecture. In Windows Server, version 1709 along with the substantial reduction in Server Core container image, we also made some substantial reductions in the Nano Server container image (dropping it below 100MB). In doing that work we identified that some of the same architecture could be leveraged with Server Core container. In partnership with other teams in Windows, we were able to implement changes in our build process to take advantage of those improvements. The great part about this work is that you should not notice any differences in application compatibility or experiences other than a nice reduction in size and some performance improvements.
2) Removing unused optional components
We looked at all the various roles, features and optional components available in Server Core and broke them down into a few buckets in terms of usage: frequently in containers, rarely in containers, those that we don’t believe are being used and those that are not supported in containers. We leveraged several data sources to help categorize this list. First, those of you that have telemetry enabled, thank you! That anonymized data is invaluable to these exercises. Second was publicly available dockerfiles/images and of course feedback from GitHub issues and forums. Third, the roles or features that are not even supported in containers were easy to make a call and remove. Lastly, we also removed roles and features we do not see evidence of customers using. We could do more in this space in the future but really need your feedback (telemetry is also very much appreciated) to help guide what can be removed or separated.
[Added on Jan 14, 2019: The list here from Gist shows what we removed to optimize the image size: https://gist.github.com/weijuans-msft/19a04903a24487c296effa3f88b603e6.]
So, here are the numbers on Windows Server Core container size if you are curious:
- 1.58GB, download size, 30% reduction from Windows Server, version 1709
- 3.61GB, on disk size, 20% reduction from Windows Server, version 1709
MSMQ now installs in a Windows Server Core container
MSMQ has been one of the top asks we heard from you, and ranks very high on Windows Server User Voice here. In this release, we were able to partner with our Kernel team and make the change which was not trivial. We are happy to announce now it installs! And passed our in-house Application Compatibility test. Woohoo!
However, there are many different use cases and ways customers have used MSMQ. So please do try it out and let us know if it indeed works for you.
A Few Other Key App Compatibility Bug Fixes:
- We fixed the issue reported on GitHub that services running in containers do not receive shutdown notification.
https://github.com/moby/moby/issues/25982
- We fixed this issue reported on GitHub and User Voice related to BitLocker and FDVDenyWriteAccess policy: Users were not able to run basic Docker commands like Docker Pull.
https://github.com/Microsoft/Virtualization-Documentation/issues/530
https://github.com/Microsoft/Virtualization-Documentation/issues/355
- We fixed a few issues reported on GitHub related to mounting directories between hosts and containers.
https://github.com/moby/moby/issues/30556
https://github.com/git-for-windows/git/issues/1007
We are so excited and proud of what we have done so far to listen to your voice, continuously optimize Server Core container size and performance, and fix top application compatibility issues to make your Windows Container experience better and meet your business needs better. We love hearing how you are using Windows containers, and we know there is still plenty of opportunities ahead of us to make them even faster and better. Fun journey ahead of us!
Thank you.
Weijuan
For “Removing unused optional components” is there a list of what was removed or will be removed somewhere? Want to make sure we’re not broken or blocked as we move things to using Docker.
Thanks for asking. I have shared the list of features we removed here:
https://gist.github.com/weijuans/19a04903a24487c296effa3f88b603e6
If you have any input on what features we should not remove, or other features we should remove, let me know! Thanks!
Weijuan
Getting a 404 for that gist. Perhaps it’s a permissions issue to that particular gist or an incorrect url?
I figured it out, this is the correct url from your posts on github elsewhere. The url was missing the “-msft”.
https://gist.github.com/weijuans-msft/19a04903a24487c296effa3f88b603e6
Good Schlock work! Glad you figured it out. I added “-msft” to my user name. I guess that broke the original URL.
Any more information for this:
“We fixed the issue reported on GitHub that services running in containers do not receive shutdown notification.
https://github.com/moby/moby/issues/25982”
We need to be able to gracefully shutdown web nodes that currently have connections. The issue fixed here plus no easy way to hook into some pre shutdown hook made this a blocker as we don’t want to sever active connections. How was this fixed as there were no details in the information supplied at that link.
We currently do this by telling our HAProxy instance that the node is out, wait for a time until no connections and then update the node. With Docker swarm on Windows there didn’t appear to be a way to have this behavior and was even worse in that the container just shut down without notifying the processes inside.
How would one achieve this scenario with this Insider version?
I would need more info to see how we can help here. Are you asking how to send shutdown notification to services inside containers?
The fix we made was when a container is being shutdown, we now send notifications to services running in that container and make sure they receive them, so they can shutdown gracefully.
Docker Swarm shouldn’t make any difference here as far as the fix goes. But like I said above, I am not clear not you are asking here.
So long as docker swarm when shutting down the container sends the the correct shutdown message that we can hook into we should be able to solve the problem.
Thank you for answering my two questions. 🙂
There was a small correction added by our engineer in the GitHub thread:
https://github.com/moby/moby/issues/25982#issuecomment-361391154.
“Just a small followup with some more info: The process shutdown notification has changed in the above insider update. Now, all processes in windowsservercore based containers will receive CTRL_SHUTDOWN_EVENT, rather than the previous CTRL_CLOSE_EVENT. Note there is a small bug in that insider build that causes the initial process (The same one that worked in the above shutdown trapping samples) to still receive a CTRL_CLOSE_EVENT, I have fixed this internally to now send CTRL_SHUTDOWN_EVENT like all other processes, and it will be hitting an insider build soon.
In the above insider build (17074), services in windowsservercore based containers will now receive the SERVICE_CONTROL_SHUTDOWN notification if they register for shutdown notifications.
The only change in nanoserver based containers is that the initial process will now receive CTRL_SHUTDOWN_EVENT rather than CTRL_CLOSE_EVENT. There’s still more work in the platform to enable shutdown notifications to all processes and services in nanoserver based containers.”
Awesome hearing about the footprint reduction! I did some experimenting on my own in this regard (managed to shave it down to 1.7 GB later) and I’m looking forward to trying the same again with 17079. Also would you happen to know whether is incomplete removal of WOW64 fixed or is it being worked on?
WOW64 uninstallation issue: https://social.technet.microsoft.com/Forums/windowsserver/en-US/f3520ba5-f73c-4acf-ab85-3598d0a7e0cb/simple-32bit-exe-runs-even-after-wow64-feature-is-removed-intended-supported-bug
Our footprint reduction tests results: https://techcommunity.microsoft.com/t5/Windows-Server-Insiders/Minimizing-Server-footprint/m-p/135912
Jan – are you working on footprint reduction of Server Core or Server Container? Is that 1.7GB for on disk size of Server Core container. Glad to see your effort here but I couldn’t tell if you were talking about Container or not.
For WOW64, we didn’t remove it this time. I am not aware of any other work either on Container side.
That 1.7 GB is for Server Core virtual machine. I’m not using containers until MS removes dependency on Docker. But it is really stretching. I achieved it by:
(1) deploying with dism […] /compact,
(2) deploying with no recovery partition and winre.wim,
(3) removing pagefile,
(4) uninstalling all features with payload removal and that includes WOW64, PowerShell and .NET, which obviously makes maintenance a little difficult, then
(5) manually deleting some speech recognition caches and Windows Defender leftovers, and running dism […] /StartComponentCleanup /ResetBase twice for a good measure.
(6) And running defrag to optimize and consolidate slabs also freed a few megabytes.
But 300 MB of files (150 MB compressed) still remains in SysWOW64, after WOW64 is uninstalled, hence my question above.
If you ask for my reasons for trying all this, well, for one, I’m an enthusiast in this regard, and I’m looking for a way to deploy our upcoming industrial telco/scada software on low-power devices with small soldered-on eMMCs.
Hello,
Will MSMQ be enabled for older Windows Server Core versions(for example Build 14393)? When will it be released?
Thanks.
Have you tested the recent release? Did MSMQ work for you in the Server Core container?
Right now, our plan is to have that in the next release of Windows Server, scheduled for first half of this year.
Hello,
I am having the same issue related to BitLocker and FDVDenyWriteAccess on Windows 10 Enterprise 1709 with Bitlocker enabled. Will there be any updates for Windows 10 Client as well that address this issue?
Regards
Alex
We have fixed the issue for Windows 10 Client as well in the upcoming release this Spring. You can try an Insider build of Windows 10 (17074 build or higher) and see if this is indeed fixed.