Key Takeaways
- Native Docker on Windows (supported by both Microsoft and Docker, Inc.) is available on Windows Server 2016 and Windows 10
- While Windows containers have a larger footprint than Linux, they are still roughly 10x more efficient than VMs because container processes run directly on the host server
- Docker has a positive cultural impact as dev and ops teams start sharing not only artifacts - Dockerfiles and Docker images – but a common language and tools
- Feature parity across Windows and Linux containers is expected by the end of 2017 - Microsoft is working on reducing the size of the base images and extending networking capabilities
- Any Windows application which you can install and run without a UI should be able to run in Docker – many organizations are migrating applications from old versions of Windows (e.g. from Server 2003) to run on a modern, supported version such as Server 2016
These are still early days for Docker on Windows but the possibilities in terms of workloads keeps growing.
InfoQ spoke with Elton Stoneman, author of the book Docker on Windows, and speaker at the recent WinOps conference, to understand how to run containers on Windows and which kind of workloads are a good choice for migration.
InfoQ: Could you briefly introduce yourself, what you do and what brought you to the world of containers?
Elton Stoneman: Sure. I'm an Azure MVP and a Pluralsight author - and I spent 15 years consulting before I joined Docker. My background is in Windows and .NET programming, typically large server-side applications using ASP.NET, WCF, Web API and SQL Server. I was working on a big Azure project in 2014, providing APIs to support an Android device. It was a cross-platform project, and the Linux team were using Docker to run their dev tools. I got interested, started using Docker a lot, started blogging and speaking about Docker and got invited to join the Docker Captains program (the Docker equivalent of Microsoft MVPs). Then a Developer Advocate role came up at Docker, Inc. and gave me a chance to focus 100% on Docker and the Microsoft ecosystem, and that's what I'm doing now.
InfoQ: Could you tell us what's the current status of "native", so to speak, Docker on Windows?
Stoneman: In container terms "native" means the application in the container uses the operating system of the host. If you run ten ASP.NET apps in Docker containers, you'll see ten instances of `w3wp.exe` in the task list on the server. The containers are still isolated units, and each app thinks it's on a separate server - with a hostname and an IP address - but it's the container processes which are isolated from each other. That's what makes Docker so efficient, running lots of containers on your server is just like running lots of apps on your laptop. Windows Server 2016 supports native Windows containers, and Docker Enterprise Edition is included in the Windows Server 2016 licence, so you get production support for your containers from Microsoft and Docker, Inc.
InfoQ: Does the Docker host for Windows-based Docker containers have to run a specific Windows OS?
Stoneman: You can only run Windows containers with process isolation on Windows Server 2016, and that can be on bare metal or VMs, on-prem or in the cloud. On the desktop, you can run Docker Community Edition on Windows 10. That uses a different isolation model (where each container runs in its own Windows Server 2016 kernel), but the way you run and manage containers is the same as on the server.
InfoQ: Windows typically has a larger memory and resources footprint than Linux, so isn't there a risk of ending up running "fat containers" that very much resemble a virtual machine?
Stoneman: There are differences between Windows and Linux containers, but Windows containers are still much more efficient than VMs. A Linux container could use Alpine Linux as the base (which is a 10MB operating system), and run the application in a single process. A Windows container might use Windows Server Core as the base (which is a 10GB operating system), and the application process will run alongside several background Windows services in the container.
But that Windows container is still running the processes directly on the host server, there's no heavyweight VM in between the app and the compute resources. Typically we see customers get between 5X and 10X efficiency - so a server that can run 10 VMs could run 100 containers. Lots of Docker customers are seeing an immediate return on investment when they move to containers, because they can decommission a lot of servers or cloud VMs.
There are storage efficiency gains, too. You package your application into a Docker image, which is a complete snapshot of one version of your app, with all its dependencies, configuration and application runtime. Images are split into layers which are shared, so if you have those ten ASP.NET apps packaged in Docker images, they all share the same 10GB Windows Server Core base image - only the delta between images is physically stored.
InfoQ: Can you briefly guide us through the biggest hurdles and critical milestones so far for Docker on Windows, both from technical and possibly cultural point of views?
Stoneman: The biggest cultural challenge is that this is a new way of running applications, and there is a learning curve for engineers and operations teams. But you can get started with Docker very quickly, and you soon see the benefits from having all your apps built, distributed and managed in the same way. The move to Docker often has a positive cultural impact. Dev and ops teams start working together on a common set of artifacts - Dockerfiles and Docker images - so they start talking the same language and using the same tools, and that can really help in the move to DevOps.
Technically, there are still some features of Docker that are Linux-only, but there's a lot of work going into the next update of Windows Server, so by the end of 2017 we should have pretty much parity across Windows and Linux containers. The biggest investment companies need to make is in writing the Dockerfile to package their applications, and integrating Docker into their CI/CD process. Tools like Jenkins, TFS and VSTS all provide Docker support. The outcome is usually a much cleaner, simpler workflow, which makes it easy to deploy updates automatically, but it does take some work to get there.
InfoQ: Docker was built upon Linux kernel isolation features such as cgroups and namespaces. How does this translate in the Windows world?
Stoneman: Those core Linux features have been around for a very long time, and Docker built on them to make containers easy to use. They've never existed in Windows, but when Microsoft people were working on Windows Server 2016 they wanted to add support for containers on Windows. The engineering teams at Microsoft and Docker worked together to add that support. The implementation is different from Linux, but it exposes a similar API so that Docker can manage containers in the same way. If you want to learn about the internals, there's a great talk from Microsoft at DockerCon 16 which goes into detail.
InfoQ: What types of Windows workloads can be safely migrated to Docker today? Do you have real world examples you could share?
Stoneman: Any Windows application which you can install and run without a UI should be able to run in Docker.
We usually work with clients who are "dockerizing" their own applications - from older ASP.NET WebForms apps, to new Go applications. Docker doesn't impose any restrictions on the style of the application, so you can have a monolithic web app running in a Windows Server Core container, and a microservices app running across multiple Nano Server containers, all running on the same cluster. We have a number of clients who are using Docker to migrate from older versions of Windows (think Server 2003). Then they can move to the cloud or on to modern infrastructure.
At Microsoft Ignite we had sessions with customers walking through their Docker journey - MetLife and Fox are real-world examples. You can also package off-the-shelf applications to run in Docker containers, provided you can script the installation. There are some server workloads which you definitely can't run in Windows containers – Microsoft Message Queuing (MSMQ) is one example - because the Windows Server Core image doesn't support it.
InfoQ: Who is working on and what is the roadmap for expanding support to more Windows workloads?
Stoneman: Microsoft's main focus for Windows containers is reducing the size of the base images, and extending the networking capabilities of Windows Server, so we'll get closer to parity between Docker on Linux and Docker on Windows. Microsoft maintain images on Docker Hub for some of their key workloads: SQL Server, ASP.NET and .NET Core. There are also official images on Docker Hub, which are trusted apps curated by Docker and the product teams. These are mostly Linux right now, but you can run Java apps with the Windows OpenJDK image, and the NATS message queue also has Windows images.
Anyone can package a Windows app into a Docker image and publish it on Docker Hub (if the product licence allows for that), so we will see a lot more open-source projects providing a Windows Docker image. Publishing an image on Docker Hub (or Docker Store if it's a commercial app) makes it very easy for users to try your app - all they need is Docker, everything the app needs to run is there in the image.
InfoQ: How does Windows licensing work for containers?
Stoneman: Windows licensing applies at the host level, so you pay for the number of servers or VMs running Windows. You don't need a licence for a Windows Server container, so if you can run 100 containers on one server, you only pay for one Windows licence.
InfoQ: What is your recommended roadmap for adopting Docker on Windows, starting from zero? What kind of considerations are needed in terms of infrastructure/applications as well as process and skills?
Stoneman: If you want to learn the basics then my talk from WinOps Docker on Windows: The Beginner's Guide is a good place to start. It covers the key concepts you need to know: Dockerfiles, images, registries, containers and orchestrators. Then if you want to get hands-on, you'll find the content for my Docker on Windows workshop on GitHub, which you can follow along to see how to move existing applications to Docker, and how that puts you in a good position to modernize them.
After that you should be ready to run your own proof-of-concept and move one of your existing apps to Docker. Start simple - an ASP.NET web app without too many integrations is a good choice, and you should be up and running in Docker in a day or two. For larger organizations Docker, Inc. can help run the PoC with the “Modernize Traditional Applications” program. And of course you should get a copy of my book, Docker on Windows.
InfoQ: In your talk you mentioned a helper tool called "image2docker", can you briefly explain what it does? Are there other tools to help migrate to Docker?
Stoneman: Image2Docker is a PowerShell tool that migrates existing applications to Docker. It's targeted for ASP.NET apps right now, and it can connect to a remote machine, or a virtual machine disk, extract the application content from the source and build a Dockerfile to package that app as a Docker image. It's a good starting point for seeing how your app runs in Docker, and we use it for PoCs when we're working with clients who have an existing suite of apps that they want to move to Docker.
Image2Docker is the only tool I know of that converts a deployed application to Docker, but a lot of IDEs have Docker support built-in for source code. Visual Studio 2017 has the highest feature set for adding Docker support to an application. It generates the Dockerfile to package the application image, and you can run the app in a container through Visual Studio and debug the app just as though it was running locally.
InfoQ: Will a Windows IT person be able to leverage Docker without any Linux knowledge?
Stoneman: Absolutely. Docker is cross-platform and it runs in the same way on Linux, Windows, IBM mainframes and the Raspberry Pi. If you only run Windows containers, you don't need to learn any Linux. You'll need to learn the basic Docker commands (like `docker image build` and `docker container run`), and how to package your application in a Dockerfile. The Dockerfile syntax is very simple, and mostly you'll be writing PowerShell or batch commands for the actual deployment in the Dockerfile, so you don't need to learn a lot of new stuff.
InfoQ: Do you think Docker on Windows will be a step forward in breaking down OS-level silos (the "Windows IT" vs the "Linux IT") in large organizations? Or will those two parallel skillsets still be needed?
Stoneman: All containers look the same to Docker, whether you're running a Go application in a Linux container, or an ASP.NET WebForms application in a Windows container. You can only run Linux containers on Linux servers and Windows containers on Windows servers, but you can join multiple Linux and Windows servers into a single cluster and manage all your workloads in the same way. Docker Enterprise Edition is very attractive to companies with diverse workloads for that very reason - you have a single pane of glass to manage all these apps. You build, deploy, scale, update, secure and administer them all in the same way using the same tool.
For IT teams Docker makes it very easy to work with apps from "the other side". Windows developers can add analytics to their apps by running Elasticsearch and Kibana in Linux containers. Linux admins can build a CI/CD pipeline for SQL Server databases running in Windows containers. I think we will get to the point soon where it doesn't really matter what's inside the container, from a user perspective. Maintainers will still need to know the internals to package the most efficient and secure images, but I'm sure the tooling will evolve so that becomes a simple task too.
About the Interviewee
Elton Stoneman is a Microsoft MVP, Pluralsight author and InfoQ editor, and he works for Docker, Inc. Elton blogs and tweets about Docker, .NET and Azure and is a regular conference speaker. He’s looking forward to the nei xt DockerCon.