다음을 통해 공유

Windows Server 2016: Windows Containers vs. Hyper-V Containers

  • 아티클

Containers today are able to provide solutions to challenges and issues associated to application development. This is the reason, they are well known today in the world of Linux. Containers solves the issue of missing dependencies especially when the developer had an application code in his particular environment but the code was absent in the server environment. Containers create a comprehensive dependency for an application which is inclusive of libraries, middleware, runtimes as well as the OS requirements. Moreover, these layers or dependencies are enveloped and operate in their own user mode container. From other applications, they are completely isolated thus glitches of applications not harmonious with each other are avoided. Applications which run in containers have their separate view of the registry, file system as well as networking addresses.

In this amazing creation of containers, Docker is very well recognized for management layer and standard repository for built-in container functionality which is operational in Linux. Windows Server 2016 extends containers to Windows Server integrating with Docker for the management and storage repository. With the increasing acceptance and adoption of cloud computing, such new features and updated technology plays an important role in harnessing new opportunities and benefits. With different cloud deployment services like Linux VMware, Windows VMware, Windows Hyper-V Cloud etc. containers play an important role in performing tasks more efficiently and effectively. One will find two types of containers in Windows Server 2016 mainly Hyper-V containers and Windows containers.

With the new features of Hyper-V in Windows server 2016 been released Windows containers are similar like Linux containers. Every application is containerized and operate in their own user-mode and isolated container run on a shared host OS. This is explained in the image below as well as showing how Docker application pulls various dependencies.

Same libraries can be accessed by different containers. Certain applications are dependent on certain OS versions and a base image of the operating system can be downloaded. This should match with host operating system version as various operating system versions are not promising since a common operating system and kernel is shared.

However, challenges are faced here as well causing problems in certain environments.

  1. Enough isolation cannot be witnessed since the isolation is at shared kernel which means at a user mode.  This is not at all a problem in single tenant environment where applications are reliable. But on the other hand, when we talk about multi-tenant environment, a corrupt tenant can misuse the shared kernel for attacking other containers.
  2. The host operating system versions are dependent as well as patch level which can create problems if a patch is arrayed to the host which can then cause the application to break.

In such cases, Hyper-V containers can be used. Hyper-V containers utilize the base image which is well-defined for the application. A Hyper-V VM is automatically created by making use of that base image. Within VM are libraries, binaries and the applications within a Windows container making it a very crucial point. Windows containers are still used by Hyper-V containers within the VM. Here comes the point of difference. Windows container now operates inside a Hyper-V VM providing kernel isolation and host/patch version level is separated. Windows containers containerize the application and then at the time of deployment you can choose the level of required isolation by picking Hyper V or Windows container. This is explained in the diagram below. A common base image can be used by several Hyper-V containers and VM’s are not exposed to manual management. There is an automatic process where VM’s are created and deleted.

Nested virtualization is supported by Windows Server 2016 which implies that if a Hyper-V VM is your container host, one can still use Hyper-V containers on that specific container host as VMs can be created within VMs.