DRAFT - I think this could do with a diagram and definitely expanding on the separation of roles - the current overview explicitly states that the Admin uses vSphere to managed the containerVMs, but that's almost the opposite of the product intent
Using constructs from the Open Container Initiative to map Docker containers to vSphere infrastructure, vSphere Integrated Containers Engine containers are provisioned as virtual machines, offering the same security and functionality of virtual machines in VMware ESXi™ hosts or VMware vCenter Server® instances.
vSphere Integrated Containers Engine enables IT teams to run traditional and container workloads side-by-side on existing infrastructure seamlessly. With vSphere Integrated Containers Engine, containers are provisioned as virtual machines, offering the same security and functionality of virtual machines in VMware ESXi™ hosts or VMware vCenter Server® instances.
From a developer's perspective, vSphere Integrated Containers Engine is a seamless Docker interface for containers with a vSphere back end. Developers can deploy, test, and run container processes faster in the same environment as traditional applications.
From a developer's perspective, vSphere Integrated Containers Engine is a seamless Docker interface to vSphere back end, allowing developers to deploy, test, and run containers in the same environment as traditional applications.
A virtual container host (VCH) is compatible with standard Docker client tools and backed by a pool of resources to accommodate applications.
vSphere Integrated Containers Engine is used to create Virtual Container Hosts (VCH) in a vSphere environment. Each VCH provides an isolated Docker API endpoint, a resource pool in which containers are provisioned, and a private network that containers are attached to by default. If the VCH is created within a vCenter cluster it spans all of the hosts in the cluster, providing the same flexibility and dynamic use of host resources as is the norm.
NOTE: I know it's likely because of trademark rules or somesuch, but the reuse of vSphere Ingrated Container Engine makes the documentation really awkward to read - can we not use an acronym, or just reword to avoid the name of the product where ever possible?
DRAFT - I think this could do with a diagram and definitely expanding on the separation of roles - the current overview explicitly states that the Admin uses vSphere to managed the containerVMs, but that's almost the opposite of the product intent
vSphere Integrated Containers Engine enables IT teams to run traditional and container workloads side-by-side on existing infrastructure seamlessly. With vSphere Integrated Containers Engine, containers are provisioned as virtual machines, offering the same security and functionality of virtual machines in VMware ESXi™ hosts or VMware vCenter Server® instances.
From a developer's perspective, vSphere Integrated Containers Engine is a
seamlessDocker interface to vSphere back end, allowing developers to deploy, test, and run containers in the same environment as traditional applications.vSphere Integrated Containers Engine is used to create Virtual Container Hosts (VCH) in a vSphere environment. Each VCH provides an isolated Docker API endpoint, a resource pool in which containers are provisioned, and a private network that containers are attached to by default. If the VCH is created within a vCenter cluster it spans all of the hosts in the cluster, providing the same flexibility and dynamic use of host resources as is the norm.
NOTE: I know it's likely because of trademark rules or somesuch, but the reuse of vSphere Ingrated Container Engine makes the documentation really awkward to read - can we not use an acronym, or just reword to avoid the name of the product where ever possible?