In the first part of the vSphere Integrated Containers Engine performance review article, we introduce Containers, Images and Volumes and the concept of Runtime and Package in Containers. In fact, vSphere Integrated Containers Engine provides vSphere administrators with the tools to easily make their vSphere infrastructure accessible to users so they can prepare their Container workloads for the operating environment. Below we examine different scenarios in this area.
Scenario 1: Implementation with the old Container environment
In an older Container environment the following conditions should be considered:
- The user creates a ticket and says, "I need Docker ."
- The administrator prepares a Linux virtual machine and sends its IP address.
- The user installs Docker, patches the operating system, configures the network and in-machine storage, secures the operating system, isolates and efficiently packages the Containers, and manages upgrades and downtime.
In this scenario, the conditions provided by the manager are similar to a Nested Hypervisor that managers must manage themselves, and the working conditions may be ambiguous. If the manager upgrades the virtual machine to a Linux virtual machine per Tenant, it will eventually create a large distributed silo for the Containers.
Scenario 2: vSphere Integrated Containers Engine
Implementation with vSphere Integrated Containers Engine can be done according to the following scenario:
- The user creates a ticket and says, "I need Docker."
- The administrator identifies datastores, networks, and processors on its cluster that the user can use for their Docker environment.
- The administrator installs a small Appliance using a tool called Vic-Machine. This appliance provides access to the infrastructure that the administrator has identified by providing an authentication system, so that the user can provide the Container workloads within it.
- This Appliance runs a secure Remote Docker API that only provides access to users who have access to the vSphere infrastructure.
- Rather than sending a Linux virtual machine to his user, the administrator sends him the IP address of the Appliance, the Remote Docker API port, and a Certificate for Secure Access.
In this scenario the administrator has provided the user with a service portal which is better than the first scenario because the user does not have to worry about isolation, patching, security, backup and more. This scenario is even better for the administrator, since every container that the user implements is a VM Container that can perform vMotion and, like all other virtual machines, monitor the Container virtual machines.
If the user needs more computing capacity, in Scenario 1, the realistic choice is that the administrator shut down and reconfigure the virtual machine, or present a new virtual machine to the user, leaving the user with the consequences of clustering. Both of these solutions are harmful to the user. In Scenario 2, the vSphere Integrated Containers Engine can be reconfigured in vSphere or implemented in a new configuration in a way that is completely transparent to the user.
In fact, the vSphere Integrated Containers Engine gives administrators the ability to select the appropriate infrastructure for an existing Task.
- Network: The administrator can select multiple Port Groups for different types of network traffic and thus ensure that all Containers that a user prepares have appropriate interfaces on the appropriate networks.
- Storage: Different vSphere datastores can be selected for different modes (States). For example, the Container mode is short-lived and is likely to need a backup, but the Volume mode needs a backup. Containers integrated with vSphere automatically ensure that when a user prepares a Container, the state is written to the appropriate Datastore.
Finally, it can be said that the vSphere Integrated Containers Engine provides managers with a mechanism that allows users to prepare their own virtual machines in the virtual infrastructure.