Deploy a virtual container host with vSphere Integrated Containers

Prepare your vSphere environment

To deploy a container host with vSphere Integrated Containers (VIC), first prepare your vSphere environment. VSphere Enterprise Plus licenses VIC, so you need an environment with either evaluation licensing or Enterprise Plus. VIC is compatible with vSphere 6.0 and 6.5 either as stand-alone ESXi servers or as a Distributed Resource Scheduler (DRS) cluster managed by vSphere.

A VIC environment requires a trusted network for management. VIC also requires a "public" network with one IP address for the virtual container host (VCH); this can be a single port group for all VCHs. I used my normal server network for both management and public.

You must also create a port group for each VCH, which hosts use for communication among containers. The VCH uses the public IP to provide Network Address Translation so that containers can connect to networks outside the VCH. If you choose to use the DRS option for vSphere Integrated Containers, you'll need a vSphere Distributed Switch.

For storage, you need a data store for container VMs -- potentially more than one if you have a lot of containers. You may also want data stores to provide persistent volumes to the containers.

VSphere Integrated Containers requires two vCPUs, 8 GB of RAM and up to 80 GB of disk space. VCHs require additional resources to run containers as VMs.

Deploy the VIC appliance

Once you've prepared your vSphere environment, download the latest VIC virtual appliance from VMware's website and deploy it. This appliance is a deployment tool for the VCHs your developers will access. You need to provide a few passwords. Use the trusted management network for the VIC appliance, which gives you the option to set a static IP address and provide certificates. Otherwise, use Dynamic Host Configuration Protocol and self-signed certificates -- the default option.

Once you deploy the vSphere Integrated Containers appliance, download the user interface from HTTPS://<OVA IP address>:9443. The VM console shows the IP address. In my lab, the appliance is on 192.168.111.140, but you will have a different IP address. We need to use the bottom file -- vic_1.1.0.tar.gz -- which is the management interface.

Download and extract the file -- I used WinZip to extract everything. As you can see in Figure C, the extracted directory contains a few files; locate the "vic-machine executables file." The vic-machine uses ISO files to create the VCH and containers as VMs.

There are separate executables for OSX, Linux and Windows. I used a Windows machine for this example, so I used vic-machine-windows.exe. Open a command prompt and change into this directory to run the executable. You need to provide a target -- usually your vCenter -- and some credentials for that target when you run operations.

Create a VCH and deploy a container

Your first task is to create a VCH. As a minimum, specify the port group and data store for this VCH. The specification should look like this:

vic-machine create --bridge-network <vic-bridge> --image-store <datastore> --no-tlsverify –force

Next, accept the self-signed certificate and use the default for any VCH that you haven't explicitly set. I used a data store called SSD-241 and a port group called VCH-001 in my lab. Once you've specified the port group and data store, you should see a window similar to the one shown in Figure D.

Notice the Docker command to connect to the VCH at the bottom of Figure D -- this is important for developers who use Docker. This command shows a Docker host and a few details about that host; this is standard Docker information, although VIC provides it.

Now that you have a Docker host to play with, deploy a container to test VIC. I like to run a simple web server, NGINX, and expose it to the public IP on port 80 (Figure E).

Point a web browser at the VCH's public IP address to see the NGINX default web page. Next, take a look at the results in vSphere. The VCH is a vApp with one VCH endpoint VM named after the vApp that provides the Docker interface. The VCM endpoint VM provides monitoring and logging for both its own services and the container it's in.

In my lab, I call the NGINX container "sharp-rosalind-ee184b2199f1" -- a name Docker randomly generates. If I ran multiple containers, there would be multiple VCH endpoint VMs -- one for each VCH vApp.

You've now successfully deployed vSphere Integrated Containers to an existing vSphere cluster, created a single virtual container host and deployed a singular container to that VCH.