This introduction to Windows containers describes the benefit and use of containers as the next step in the evolution of virtualization in Windows Servers.
- [Narrator] One of the most talked about features in Windows Server 2016 is the newly-introduced Windows containers. While containers are not a new concept to many developers, the integration of containers as a feature of the Windows server environment has opened up a new level of cooperation for developers and network operations. Before we get into different scenarios and the tools needed to manage containers I wanted to describe what a container is.
The best way I can do that is to review a little bit of history. There was a time when a server was always a collection of dedicated hardware. One box housed the processors, memory, and hard drives that ran one instance of an operating system, and on that server you could install or configure applications that would serve your network users. At some point people realized that it wasn't necessary to give each server it's own box, and blade servers were introduced to save space in data centers.
All of the hardware necessary to run a server operating system and multiple applications, could be made available on one large card, and multiple blade servers could share a single power supply, each with their own operating system and applications. Then we took a giant step forward as hardware became increasingly more powerful. It was determined that one beefy piece of hardware could have the processing cores, memory, and other resources necessary allocated to virtual machines.
Each of these virtual machines could be allocated the resources they needed to run their own complete server operating system and house just about any network application you wanted. This did more than just save space, it made better use of server hardware. It allowed us to combine several partially used servers into one more completely utilized investment. Also, checkpoints made it possible to revert to previous running states of our servers.
And the fact that a virtual machine was made up of a configuration file and one or more virtual hard drive files, made these virtual machines portable. They also had the ability to scale the hardware by simply reallocating resources in a management pool. A server no longer had to be defined by a specific collection of hardware. For the programming world a developer could spin up a virtual machine to test out and refine their code before deploying an application to production.
Well, because a programmer's ultimate goal is to develop applications, and deploy them to users, the next logical question would become, besides hardware what else could be virtualized or shared? Applications under development will have their issues, so they need to be isolated. They can't just be installed and tested on a production server. But what else do they really need? They need an operating system. Well scratch that. They actually just need access to a kernel and various libraries.
They need their own processor, or at least processor time. They need memory, or at least memory spaces. And they also need storage space, and a network interface if they're to interact across a network environment. In response to these needs, containers were introduced. A container is a space running on a server, physical or virtual, that's allocated processor time, virtual memory, storage space, and access to an operating system.
It doesn't have it's own kernel and libraries, because the host server already has those resources. A container is little more than a run-time environment, with everything an application needs to run, and nothing that it doesn't. It's more efficient than a virtual machine, because it doesn't require a separate installation of an operating system. Multiple containers can share a single OS environment. And there's the added benefit that it doesn't require the licensing or the licensing costs of separate instances of an operating system.
A container can be deployed in a matter of seconds or minutes with no unnecessary overhead or cost. Developers can be granted their protected space and when the application is ready for deployment, it can be deployed as a container to the production server, not only remaining as efficient and portable as possible, but consistent with the environment where it was created. Stick with me as we explore different uses of the containers introduced in Windows Server 2016, and what it takes to run them.
- Physical host environments
- Virtual host environments
- Installing and creating Windows containers
- Creating Hyper-V containers
- Creating, tagging, and pushing images
- Removing images
- Configuring startup options
- Working with PowerShell, Docker daemon, and Azure
- Managing container networking
- Managing data volumes, resources, and repositories