drx - Fotolia
Container deployment considerations for successful implementation
Containers can be useful for specific workloads but admins should consider certain factors, such as security and portability needs, before taking a containerized approach over VMs.
Container technology provides virtualization administrators with a different way to host applications, but VMs continue to hold against the increasingly popular containerized approach. Which instance type to use greatly depends on each application's needs.
Before admins consider integrating containers into their environments, they must understand the differences between containers and VMs and how application type factors into deciding between the two. Both instance types offer virtualization capabilities, but container deployment affects workloads differently. Proper deployment and management will help admins optimize workload performance.
Differences between VMs and containers
Although admins can use both VMs and containers to host application workloads, each instance type has its own pros and cons.
VMs rely on a hypervisor, which is a software layer that makes the system's computing resources available to them, and VMs are fully isolated from each other. Containers require a container layer -- usually a Linux variant -- and share the host OS, which can expose them to a single point of failure. This means that VMs are generally more secure, because they each operate on their own OS. However, containers have better scalability and tend to provide faster migration speeds because they are smaller than VMs.
Choosing between bare-metal and hypervisor-based models
Before deciding whether to run containers on bare-metal or a hypervisor-based platform, admins must consider application performance requirements and their portability and security needs.
Bare-metal hardware typically provides better performance, reduced overhead and increased density, but a hypervisor-based container platform might be ideal for admins who rely on older applications that aren't as easy to migrate. Specific performance metrics and portability options greatly depend on the type of workloads admins run.
Security is more often the deciding factor between bare-metal and hypervisor-based models. If admins don't require a deep layer of security, containers will work just fine. But a hypervisor provides better isolation to combat weaknesses, so VMs might be the better choice if admins are willing to accept the reduced performance and density compared to containers.
Difficulties with container deployment within a VM
Admins can realize the advantages of both containers and VMs with the help of nested virtualization. Though the base concept itself is enticing -- the ability to run a container within a VM -- there are several issues with how the instances coexist with each other.
One potential problem is incompatibility. This is because some hypervisors virtualize hardware differently, which can lead to faults that are difficult to predict and remedy. If admins want to use nested virtualization, they must meet specific requirements. First, admins should ensure that the nested virtualization service itself is enabled and provision adequate system resources to operate the workload. Then, admins should install any and all current OS patches and updates, being wary of older processors that might be more sensitive to nested virtualization performance.
Use cases for Hyper-V containers and VMs
Hyper-V containers reside in Hyper-V VMs and integrate their own copy of the Windows kernel. The choice between Hyper-V containers and traditional Hyper-V VMs can be difficult, but admins shouldn't go with Hyper-V containers just because it's a newer feature. Determining which of the two offers the most benefits comes down to application needs over anything else.
If a service or cloud provider needs to host multiple tenants that require strong isolation, Hyper-V containers are ideal. Hyper-V containers enable service or cloud providers to run untrusted and multi-tenant applications on the original host, and admins to run an application securely while separating it from other production workloads, successfully isolating it from the host and the core infrastructure. But Hyper-V containers aren't particularly ideal if an admin's application requires enduring data connections.
Prepare host for Hyper-V container deployment
Admins considering incorporating Hyper-V containers into their environments must complete a few essential steps first. In general, they must prepare the host machine before installing and running Hyper-V containers.
Once admins have ensured that they've met the requirements for hosting Hyper-V containers -- Windows Server 2016, a processor with Intel VT-x, at least 4 GB of memory and two virtual processors -- the first step is to install the Hyper-V role and container feature on the host machine. They must then install the most recent Docker Engine software along with modules and libraries, which help create an isolation environment, before installing the base OS image for the container. There are also several Docker commands that admins can execute to ensure proper Hyper-V creation with the specified OS image, assist with killing a container and provide valuable data about the containers themselves.
