Before we dive into vSphere Integrated Containers lets look at what a container is. Containers are simply put, a sandbox where processes can run independent of each other. You could compare a container to a VM. The difference being the abstraction layer. For instance a container is a sandbox within an OS where a VM is a sandbox within a hypervisor. Containers are very portable due to the fact you can package a container to an image. You can run this image on any platform that runs a container engine. The reason why this works is that a container consists of the entire runtime environment. This includes the application, dependencies, libraries, configuration files etc.
A container is also stateless and all data written by it is non-persistent. To actually save data it needs to be transported over the network or a so-called volume can be attached to store the data.
This guide will walk you through setting up your vSphere environment so we can then run containers with our current infrastructure.
In general vSphere Integrated Containers is made up of three major components.
The engine consists of a set of binaries that allow you to deploy a Virtual Container Host.
The registry is where container images are stored and distributed.
The management portal provides a UI to provision and manage containers. It also provides information and statistics about container instances.To keep it simple I will not go in to the details of the Registry or Management Portal.
The Virtual Container Host is basically where the containers will reside. It acts as namespace that can be used by developers to start running containers in. Think of it as a Docker compatible self-service portal where containers can be spun up. There can be multiple VCH's in a vSphere environment. You install a VCH through a command line tool where you specify networking, storage, credentials and information about the vSphere environment.
There are 5 different types of network that come in to play when adding a Virtual Container Host to the environment.
Network type - Communicates with - Mandatory
Management network - VCH, vCenter, ESXi hosts - No, if not specified Public network is used
Public network - Internet, end-users - No, if not specified the 'VM Network' is used
Client network - Docker clients (developers) - No, if not specified Public network is used
Bridge network - Container VM to container VM within VCH - Yes
Container network - vSphere networks - No
Please note that there is a lot of very specific information tied to each network type. For this guide we only need to know the basics. To learn more about networking go to the official documentation.
There are basically two types of storage. The first is the 'image' store where container images will be cached. The second is the 'volume' store which is used to provide containers with a persistent volume to store data. These volumes are actually VMDK files stored on datastores.
When deploying the VCH we need to have an account with administrative privileges to set up the VCH vAPP and VM in the environment. There is also the option to specify an ops account. The ops account will be used from the namespace to run actions that need to be performed in the vSphere environment. This way we don't have to use the administrator account for this.
To install vSphere Integrated Containers you install an OVA appliance which gives access to all vSphere Integrated Container components. For this guide I am using the OVA appliance from VMware. I am using the latest version to date which is version 1.1.1. This version is also the first to include all components in one single OVA. There are also open source builds available on Github. Please note that open source builds are not supported by VMware Global Support. Also you need vSphere Enterprise Plus for support.
The lab consists of the following components:
Open up the vSphere webclient and right-click your vCenter server. Choose 'Deploy OVF Template'
Step 1. Click browse and select the downloaded OVA file.
Step 2. Select a location.
Step 3. Select a resource.
Step 4. View the details.
Step 5. Read and accept the EULA (I know we don't read these, just click accept).
Step 6. Select the storage location for the appliance.
Step 7. Select a network.
Step 8. Fill in the password you want to use for the appliance, registry and database. Also fill in the network details like IP, mask, gateway and DNS (separated by a SPACE).
The rest can be left at their default values.
After clicking next and finish the appliance will be installed. After this is done power on the appliance.
If all went well you should now see this screen when you open the console.
Download the VIC engine and deploy VCH
After the OVA is installed we can browse to the Registry and Management Portal as shown in the console. To setup our Virtual Container Host we need to download the engine binaries.
These are somewhat hidden and reading through the documentation will reveal where to find them. When we go to the same location but use port 9443 we will find some downloads.
Download the vic_1.1.1.tar.gz file to your management station and unpack it. There are binaries available for Windows, Linux or Mac OS so use whatever has you preference. In this guide I will be using Windows.
To deploy a VCH we will work with the command line utility vic-machine and in this case it is actually vic-machine-windows.exe since we are on a Windows management system.
If you want to do this on a Mac or Linux you can replace windows.exe with darwin or linux. To get help about the various parameters that are available use the --help parameter. For this guide I will not go in to all the details and just show the commands needed to get your VCH up and running.
With that said, start the command prompt and let's get started.
First make sure the ESXi firewall is configured correctly. Outbound connections must be allowed for TCP 2377. Of course any network firewall needs to be opened as well.
vic-machine-windows.exe update firewall --target vcsa-01a.corp.local --user [email protected] --compute-resource RegionA01-COMP01 --allow
Now we can deploy the VCH.
vic-machine-windows.exe create --target vcsa-01a.corp.local --user [email protected] --ops-user [email protected] --name vch1 --compute-resource vch1-rp --image-store RegionA01-ISCSI01-COMP01 --volume-store RegionA01-ISCSI01-COMP01:default --bridge-network vch1-bridge --public-network VM-RegionA01-vDS-COMP --container-network VM-RegionA01-vDS-COMP --no-tlsverify
If everything went well we should now have a Virtual Container Host running on our environment.
Now we can do a quick test in our environment so we know we are ready to continue. To do that we need Docker since the VCH is a Docker compatible environment.
I have installed 'docker toolbox' on my management VM so I can run Docker commands.To test if the interface to our newly created VCH works type the following command.
docker -H 192.168.100.125:2375 info
Now we should get a response like this.
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 0
Server Version: v1.1.1-10711-56a309f
Storage Driver: vSphere Integrated Containers v1.1.1-10711-56a309f Backend Engine
VolumeStores: default
vSphere Integrated Containers v1.1.1-10711-56a309f Backend Engine: RUNNING
VCH CPU limit: 1020 MHz
VCH memory limit: 3.698 GiB
VCH CPU usage: 816 MHz
VCH memory usage: 3.64 GiB
VMware Product: VMware vCenter Server
VMware OS: linux-x64
VMware OS version: 6.5.0
Plugins:
Volume: vsphere
Network: VM-RegionA01-vDS-COMP bridge
Swarm: inactive
Operating System: linux-x64
OSType: linux-x64
Architecture: x86_64
CPUs: 1020
Total Memory: 3.698GiB
ID: vSphere Integrated Containers
Docker Root Dir:
Debug Mode (client): false
Debug Mode (server): false
Registry: registry-1.docker.io
Experimental: false
Live Restore Enabled: false
Very well, it looks we are almost there. Now that we know everything is set up correctly we can start spinning up containers.
From a vSphere administrator point of view you would now hand over the connection information to your developement team. They can then start using the environment to start building their containerized applications or bring existing ones in.But, we didn't do all this work for nothing so we want to get a container up and running, right?
Lets get a simple container running at the least.Start by pulling a simple container image called 'hello-world'.
docker -H 192.168.100.125:2375 image pull hello-world
When this is done start your container.
docker -H 192.168.100.125:2375 container run hello-world
Hello from Docker!
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.
To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash
Share images, automate workflows, and more with a free Docker ID:
https://cloud.docker.com/
For more examples and ideas, visit:
https://docs.docker.com/engine/userguide/
This command actually spins up a container that just has a script inside it to display this information. You will notice that the container has stopped running after it has displayed the information. This is because containers only live as long as their main process. If that is done, the container ends.
We have come to the end of this guide. You should now have a basic understanding on how to get started with vSphere Integrated Containers. We deployed the OVA and downloaded the VIC engine files. Then we used these executables to get a Virtual Container Host up and running. After that we spun up a very simple container. Of course, there is a lot more ground to cover but that would go beyond a getting started guide. Also please be aware that VIC does have its quirks and some functionality that you would find in Docker is not yet implemented in the VCH. To keep up with the changes check out VIC on Github.Just one more thing, there is a fun fact that if you do not specify the '--name' parameter when running a container the system will create a random name. These can be very funny sometimes, what about 'naughty_jennings' or 'serene_dijkstra'. Any developers of VIC called Jennings or Dijkstra perhaps?
