Q
Get started Bring yourself up to speed with our introductory content.

How OS components affect Windows and Hyper-V containers

Serious issues can occur during updates in a production environment if the four levels of the version system don't match up between Windows or Hyper-V containers and the Windows Server host.

One of the principal benefits of containers is deployment flexibility. The idea is that a container is assembled...

from a series of layers, which allow the container to package all of the dependencies that are involved in the application -- thus enabling the container to run almost anywhere regardless of the platform. But the OS itself can pose a serious wrinkle in container compatibility that's often overlooked.

Even though containers share the underlying OS kernel, each container itself will include some OS components -- an OS layer. The problem is that the OS components included with the container must match the OS version running in the host kernel. If the OS versions don't match, the container might not function properly -- if at all.

Containers are blocked if the build numbers are different. For example, Microsoft uses a four-level version notation system that designates major, minor, build and revision -- such as 10.0.14393.0. Ideally, all four levels of the version system should match before a Windows or Hyper-V container will run on a Windows Server host. In actual practice, a container will start if there's a difference in the revision -- lowest -- designation level, but there's no guarantee that the container will work properly. However, no differences are allowed in the major, minor and build levels.

This can become a serious problem for DevOps teams. Consider an environment where an IT staff updates the OS on production hosts, only to find that hundreds, thousands or even tens of thousands of containers no longer function properly because of an OS kernel mismatch. Operations staff will need to coordinate OS patches and updates with developers so containers can be updated and redeployed with the equivalent OS layer in concert with production environment changes. The challenge is a bit less pressing for Hyper-V container deployments where there might be more latitude in delaying and coordinating VM OS upgrades.

Next Steps

Differences between Windows Server containers and Hyper-V containers

Evaluate Microsoft Azure Container Service

Understand the relationship between containers and microservices

This was last published in September 2017

Dig Deeper on Application virtualization

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What else is important to know about OS components and Windows containers?
Cancel

-ADS BY GOOGLE

SearchVMware

SearchWindowsServer

SearchCloudComputing

SearchVirtualDesktop

SearchDataCenter

Close