When Microsoft introduced Nano Server in Windows Server 2016, as a small-footprint server OS with no local logon, it was targeted at a few different workloads. The company has found the software is increasingly being used for one type of workload: managing containers.
As a result, the company has whittled down the core of Nano Server to just those components needed to run containers. It has also added in networking support to accommodate the needs of container orchestrators, notably Kubernetes and Swarm.
For Microsoft, Nano Server is the heart of Windows Server; a minimal refactoring that future versions of Windows Server will build on, with “just enough” of an operating system to run applications without introducing more of a risk surface than necessary. For customers, it was designed to run both containers and some key infrastructure roles.
“When we launched Nano Server last fall, it had a very small footprint for a compute cluster, a storage cluster and other infrastructure roles, but people weren’t using it for that, but they were using it for containers,” Chris Van Wesep, Microsoft Enterprise Cloud product marketing director told The New Stack. The anonymized telemetry in Windows Server 2016 showed that “the vast, vast majority of Nano Server deployments were for container scenarios not for the infrastructure scenarios.”
Nano Server will include more platform support for container orchestrators like Kubernetes and Swarm.
That’s why the next version of Windows Server, which will be available in the latter part of this year, removes those unused infrastructure roles from Nano Server to make a smaller image still. A smaller image means higher density, faster startup times and the ability to deploy enough containers on a laptop to be consistent with the production environment on the server for development and testing.
Smaller, Faster, More Containerized
“The feedback we got on Nano Server was ‘it’s good, but it could be better’,” Van Wesep explained. “Customers are saying ‘You got it down to sub 500MB, but I would like to see it 200MB or sub 100MB smaller.’ There is a tradeoff that needs to be made here and we’re making that tradeoff; Nano Server is an optimized-for-containers runtime image.”
At one point, the Nano Server image was 1GB, uncompressed, Taylor Brown from the Windows Server team told us. “We have a lot of components that really weren’t relevant to containers but they were relevant to physical machines and virtual machines, like the recovery shell. They weren’t optional components; they were just parts of the OS that we couldn’t pull out in a container-native way.”
For the next release, Microsoft is already committed to getting the uncompressed image down to 500MB and Brown called that conservative; “I think we’re actually going to exceed that in the first release and we’re really committed to continuing down that road. The pull size, the compressed size, and the on-disk size will both get much, much smaller.” In the long term, the goal is to have a Nano Server image with .NET Core in be the same size as a Linux image with .NET Core.
That means removing a lot of components. “We’re gutting Nano Server,” Taylor said. “We’re pulling out WMI, we’re pulling out IIS, we’re pulling out .NET, we’re pulling out PowerShell, we pulled out every driver, we pulled out event loggers, we pulled out scheduled tasks.”
That might well break workloads, so Brown encouraged developers to join the new Windows Server Insider program to try this container-optimized version of Nano Server as soon as possible, so the team can add back any components that turn out to be necessary. “We’ve got to be aggressive; the vision is let’s cut and prune and get the thing as optimized as possible. Let’s not be afraid, let’s move forward fast and make this thing small.”
Components that used to be part of the images will now be optional. “You’ll pull down Nano Server and if you want .NET, you pull down .NET on top of that, if you want PowerShell you pull down PowerShell. If you don’t want .NET, you don’t have to have .NET, if you don’t want PowerShell, you don’t have to have PowerShell. These are all optional layers now and very native to the container experience.”
Nano Server will include more platform support for container orchestrators like Kubernetes and Swarm. It already has network overlay support, so you can make native bridge networks across Swarm clusters, but the next release, named 1709, for the planned September release date, will add mapping named pipes into containers, which means you’ll be able to run container orchestrators as container images — for both Docker and Hyper-V isolation containers.
Nano Server will also let you hot-add network interfaces; that’s been a problem for Kubernetes, which starts a container without network adapters and then adds them to the container. Also useful for Kubernetes is what Brown called “initial support” for sharing network interfaces between containers; that will work with shared kernel containers in Nano Server 1709 but Hyper-V isolation containers in Server Core won’t get it until a later release. Mapping SMB volumes from file servers and named pipes will make it easier to connect storage to containers and have it remain accessible as containers move around.
Adding the Windows Subsystem for Linux to Server Core hosts (though not Nano Server) will also be useful for scripts that handle containers. You can even use Linux containers to build Windows container images, and vice versa, giving you a lot of flexibility to work with the tools you want.
Nano Server has always had a GUI — of sorts. The Azure Server Management Tools gave you the traditional task manager, registry editor, control panel, performance monitor, disk management, user and groups management, device manager, file explorer and even Hyper-V management through a web interface. It worked with Nano Server, Server Core and Server with the full desktop experience, all the way back to Windows Server 2012, but you needed both an on-premises gateway and an Azure account to use it. That service never came out of preview (so it was never supported for production workloads — previews are ‘use at your own risk’) and Microsoft is discontinuing it as of June 30, 2017.
That doesn’t mean Microsoft thinks you don’t need a GUI for troubleshooting. “We got a lot of feedback saying ‘we think the functionality is really neat but it would be great if you didn’t force us to go through Azure to get back to our on-premises stuff,” Van Wesep told us. He promised more information about what will replace SMT at the Ignite conference in September, but there will definitely be options. “We’re dialed into customers saying ‘If you’re going to keep pushing GUI-less things then you should give us a nice way to interface with them’.”
Nano Server and Server Core will both be part of the new Semi-annual Channel, getting updates twice a year. You need Software Assurance to get those updates — or to be using Azure or a hosting provider that provides them. Server Core is also available as Long Term Servicing Channel (which is the only way you can get Windows Server with Desktop Experience). That’s because the container model Nano Server is now aimed at is still evolving and new features will arrive regularly.
If you want to run containers and container orchestrators on your own infrastructure rather than handing over the update work to a cloud provider like Azure Container Service, you need to be prepared for regular updates.
Six-monthly updates should be less work for DevOps teams to adopt than big updates every three years, Brown suggested. “When we have long release cycles, a lot of stuff changes and it takes a long time to validate it and certify it and get it into production. A shorter release cycle should be a lot easier.” In general, he noted that the developer audience is more open to updating Windows Server frequently than admins running infrastructure roles like Active Directory, “as long as you give me new features.”
And Nano Server is proving very popular for containers, he told us. “We’ve got crazy Nano Server adoption for containers; the numbers are shockingly high.”
Feature image via Pixabay.