Having set up the blog and created a ticking timebomb of IaaS, it’s time to crack on with a great first question.
There are a few decent write-ups out there, but mostly those can only analyze what immediately presents itself and less about the intent or direction. That’s what I am going to attempt to succinctly cover here. The scope of this post is really just expanding on the summary in the About section. There will be plenty of scope to deep-dive in other posts about specifics.
In a Nutshell
The VIC product is a container engine (VICe), management portal (Admiral) and container registry (Harbor) that all currently support the Docker image format. VIC is entirely OSS, free to use and support is included in the vSphere Enterprise Plus license.
I don’t plan to cover anything more about Admiral or Harbor in this post. Admiral is a neat way to tie together image registries, container deployment endpoints and application templates into a UI. Harbor is a Docker image registry with additional capabilities such as RBAC, replication etc.
VIC engine (VICe) is a ground-up open-source rewrite of research Project Bonneville, the high-level premise of which is “native containers on vSphere”. So what does that actually mean in practice?
- vSphere is the container host, not Linux
- Containers are spun up as VMs not in VMs
- Every container is fully isolated from the host and from each other
- Provides per-tenant dynamic resource limits within an ESXi cluster
- vSphere is the infrastructure, not Linux
- vSphere networks appear in the Docker client as container networks
- Images, volumes and container state are provisioned directly to VMFS
- Shifts complexity away from the user to the admin
- vSphere is the control plane
- Use the Docker client to directly control vSphere infrastructure
- A container endpoint presents as a service abstraction, not as IaaS
VICe will be the fastest and easiest way to provision any Linux-based workload to vSphere, provided that workload can be serialized as a Docker image.
VICe tackles head-on the question of how to authenticate tenants to self-provision workloads directly into a vSphere environment without having to raise tickets for VMs. It provides a vSphere admin the capability to pre-authenticate access to a certain amount of compute, network and storage without having to create resource reservations.
It’s all centered around the notion of a Virtual Container Host (VCH). A VCH is a vApp with a small appliance running in it. It is a per-tenant container namespace with dynamic resource limits. The appliance is the control plane endpoint that the client connects to and is effectively a proxy to the vSphere control plane.
When a tenant wants to run a container from a Docker client, vSphere creates a VM within the resource pool, attaches the image and volumes as disks and boots the VM from an ISO containing a Linux kernel. The image cache and volumes are persisted on a vSphere datastore. The networks are vSphere distributed port groups. The only thing running in the containerVM is the container process and a PID 1 agent that extends the control plane into the containerVM.
It’s good for the admin because it allows them complete visibility, auditing and control over which workloads have access to what resources. It also allows them to extend their existing infrastructure to provide a flexible CaaS offering to their clients.
It’s good for the clients because they no longer have to deal with any of the complexities of running a container workload in production. There is no infrastructure to manage, it is simply a service.
VICe is a VM provisioning mechanism that applies container characteristics to a VM in a way that is completely transparent to a client. How many of those characteristics you can take advantage of will depend on functional completeness of the version you’re using and a few fundamental limitations that will be a good topic for another blog.
What VICe is not is a container development or build environment. It is designed specifically to sit at the end of a CI pipeline and pull down images from a trusted registry and run them. This is an important distinction. Unfortunately this a distinction that currently can’t be separated out in the Docker client or API definition, so at least for now, VICe only supports a subset of the Docker API.