Blog Post

Containers
4 MIN READ

A smaller Windows Server Core Container with better Application Compatibility

Virtualization-Team's avatar
Virtualization-Team
Copper Contributor
Mar 22, 2019
First published on TECHNET on Jan 22, 2018
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

https://windowsserver.uservoice.com/forums/304624-containers/suggestions/18544312-fix-docker-load-pull-build-issue-when-bitlocker-is

  • 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
Published Mar 22, 2019
Version 1.0

2 Comments

  • scotttak's avatar
    scotttak
    Copper Contributor

    Hi, I hope this is a good place to post my situation with MSMQ and containers

    I've tried to get MSMQ working for our use case but can't seem to do so. Basically,we are trying to use private queues in a server core container which are accessed through WCF (need the net msmq binding and msmq integration binding to work) from another container sharing the same NAT network.

    Has anyone gotten this use case to work? If so, how?

    I've tried setting the bind ip for MSMQ to the network adapter used by the container, exposing all the MSMQ ports through the Docker Build file, added the Everyone and Anoynmous Logon permissions to the queues, set the MSMQ security registry values inside the containers, and tried direct=os and direct=tcp using the container hostname and IP.

    When trying to open the queue, I am always getting "The queue does not exist or you do not have sufficient permissions to perform the operation. (-1072824317, 0xc00e0003). The message cannot be sent or received from the queue. Ensure that MSMQ is installed and running. Also ensure that the queue is available to open with the required access mode and authorization. "

    Accessing the queue from the same container that is hosting the queue works with WCF, but not from a different container (both running the same windows core image).

  • mvdezz's avatar
    mvdezz
    Copper Contributor

    Is only the base image so big and are the containers just a layer on top of that storage or are the containers so big as well?