vSphere Integrated Containers (aka VIC) is VMware Enterprise Container Infrastructure. Any VMware customer having VMware vSphere Enterprise Plus can get enterprise container infrastructure to help IT Ops run traditional and containerized applications side-by-side on a common platform with vSphere Integrated Containers. Supporting containers in your virtualized environments means IT teams get the security, isolation, and management of VMs, while developers enjoy the speed and agility of containers—all within vSphere. The VIC project is available on GitHub at https://vmware.github.io/vic-product/
The overall concept is very interesting, especially for customers willing to use Docker containers but not having requirements or skills to operate Kubernetes. The most interesting part of VIC is the networking concept very well explained in following video https://www.youtube.com/watch?v=QLi9KasWLCM&feature=youtu.be
As one of my customers is considering VIC to provide containers to their developers, I have decided to test it in my home lab.
The first step is to deploy VIC from OVF. It's pretty straight forward so I'm not going to document any details.
The second step is to create the first VCH (Virtual Container Host), which acts as a remote Docker server. You can have multiple VCH's and they can be grouped into projects. Let's keep architectural decisions besides at the moment and focus on testing the technology itself.
VCH deployment is typically done via vic-machine CLI Utility as GUI is too slow interface for DevOps approach. Documentation is available at
https://vmware.github.io/vic-product/assets/files/html/1.5/vic_vsphere_admin/using_vicmachine.html
VIC-MACHINE ... is the primary tool for DevOps admin. I will discuss roles, tooling, and RBAC for particular actors in DevOps approach in the next blog post together with the overall architecture.
We can download vic-machine from VIC appliance deployed in step 1. In my case, it is available at https://vic.home.uw.cz:9443/
When we have vic-machine available in our DevOps workstation we can start act as a DevOps engineer.
Note 1:
Before the first VCH deployment, we have to enable the firewall rules in a particular vSphere cluster (the name of vSphere Cluster in my home lab is CLUSTER).
./vic-machine-darwin update firewall --target vc01.home.uw.cz --thumbprint 64:06:CD:4E:D8:39:8B:E8:80:2D:D3:25:50:C7:B9:7D:E1:6F:8B:E9 --user administrator@uw.cz --compute-resource CLUSTER --allow
Now we are ready to create our first VCH.
Here is the command, how to create VCH.
./vic-machine-darwin create --name vch01 --container-name-convention vch01-{name} --compute-resource CLUSTER --image-store vsan-Underlay --base-image-size 8GB --bridge-network VCH01-BRIDGE --bridge-network-range 172.16.0.0/12 --public-network MGMT --dns-server 192.168.4.4 --container-network CONTAINER01:container01 --container-network-ip-range CONTAINER01:192.168.51.0/24 --container-network-gateway CONTAINER01:192.168.51.254/24 --container-network-dns CONTAINER01:192.168.4.4 --container-network-firewall CONTAINER01:published --tls-cname vch01 --certificate-key-size 2048 --no-tlsverify --user admin@UW.CZ --thumbprint 64:06:CD:4E:D8:39:8B:E8:80:2D:D3:25:50:C7:B9:7D:E1:6F:8B:E9 --target vc01.home.uw.cz/SDDC --ops-user administrator
The output from the command looks similar to ...
My first VCH has been created with a single container network (network name CONTAINER01). To add another container network (CONTAINER02) we need to know VCH id, therefore inspect command has to be used.
./vic-machine-darwin inspect --target vc01.home.uw.cz --thumbprint 64:06:CD:4E:D8:39:8B:E8:80:2D:D3:25:50:C7:B9:7D:E1:6F:8B:E9 --user administrator@uw.cz --compute-resource CLUSTER --name vch2
Note that to configure additional network we have to add all already existing networks into the command as well.
./vic-machine-darwin configure --target vc01.home.uw.cz --thumbprint 64:06:CD:4E:D8:39:8B:E8:80:2D:D3:25:50:C7:B9:7D:E1:6F:8B:E9 --user administrator@uw.cz --id vm-299 --container-network CONTAINER01 --container-network CONTAINER02
Docker client is using VCH (aka Virtual Container Host) as a docker server
export DOCKER_HOST=192.168.4.140:2376
docker --tls info
docker --tls network ls
Here is the output of the networks available in my Docker host (aka Virtual Container Host)
and after vic-machine command to add additional network CONTAINER02 you can see the network in container host (VCH) and use it for our containers.
Of course, we can use other standard docker commands to manage our docker images and containers.
docker --tls images -a
docker --tls ps -a
Run NGINX and access the service through NAT
docker --tls run --name nginx1 -d –p 8080:80 nginx
docker --tls ps -a
docker --tls images -a
Run NGINX and access the service directly through container network (IP address assigned via DHCP)
docker --tls run --name nginx2 --network="container01" -d -p 80 nginx
Run NGINX and access the service directly through container network (IP address assigned staticaly)
docker --tls run --name nginx30 --network="container01" --ip="192.168.51.30" -d -p 80 nginx
Execute a Shell Command from a Container
docker --tls run busybox date
docker --tls ps -a
In the screenshot below you see what vSphere Admin has in his environment.
Docker Volumes
If you need persistent storage for your containers, you can create volumes which are persistently stored in your enterprise infrastructure and visible not only to DevOps admin and Developer, but also to your infrastructure administrator.
Create a Docker Volume
docker --tls volume create --opt Capacity=2GB --name volume-test
docker --tls volume ls
docker --tls volume inspect volume-test
Attach a Docker Volume to a Container
docker --tls run --name busybox -it -v volume-test:/data/volume-test busybox
And this is what vSphere Admin can see in his environment
List VCH instances
DevOps admin manages Virtual Container Hosts. Here is the command to list all VCH's from a particular vCenter.
./vic-machine-darwin ls --target vc01.home.uw.cz --thumbprint 64:06:CD:4E:D8:39:8B:E8:80:2D:D3:25:50:C7:B9:7D:E1:6F:8B:E9 --user administrator@uw.cz
Delete VCH
And here is the command to destroy particular VCH.
./vic-machine-darwin delete --target vc01.home.uw.cz --thumbprint 64:06:CD:4E:D8:39:8B:E8:80:2D:D3:25:50:C7:B9:7D:E1:6F:8B:E9 --user administrator@uw.cz --name vch2 --compute-resource CLUSTER
Conclusion
DevOps is a big topic nowadays. It is worth to say that DevOps is about methodology and not the tooling. At the end of the day, it doesn't matter if you use Docker, Kubernetes, Ansible or even more traditional tools. What matters is the final product which has to be developed in sync with the business owner, otherwise, there is a high chance you are not meeting business owner expectations. I'm ex-developer, Software Engineer / Architect and now I work as an Infrastructure Technical Designer / Architect, therefore I know, the DevOps methodology is the best way how to develop and deliver a business application to the business owner. The key principles of DevOps methodology are to identify the core business requirements, quickly develop the application prototype, present it to the business owner, validate if the business owner expectations are met and if so, move the prototype into production and continuously develop and deploy additional business requirements in short iterations with continuous feedback from the business owner. For such an approach, you need to deploy your application into infrastructure dynamically and quickly. Traditional Enterprise Infrastructure is not ready for such agility.
In this blog post, we were testing the tool (VMware vSphere Integrated Containers) which can help Developers, DevOps admins and infrastructure admins cooperate in an agile fashion. It might or might not help to deliver successfully the business project. However, it definitely helps DevOps teams to have agile DevOps infrastructure with Enterprise level of support, security, availability, and cooperation between Developers, Security, and Infrastructure (compute, storage, network) teams which each lives in the totally different world and they do not understand each other :-)
In my opinion, vSphere Integrated Containers is a great technology to start DevOps in the Enterprise environment. We all know that Enterprises will eventually adopt Kubernetes as it is nowadays a "de facto" standard for DevOps infrastructure, however huge Docker Hosts backed by solid enterprise infrastructure (VMware vSphere) is good enough for anybody just starting with DevOps methodology. In the near future, VMware vSphere will have integrated Kubernetes (watch the Project Pacific) and DevOps teams will be able to transform their DevOps tooling into another level.
In the next post, I will focus on the Architecture Design of DevOps environment leveraging VMware vSphere Integrated Containers.
Hope this blog post helps at least one other person in the great VMware community.
The overall concept is very interesting, especially for customers willing to use Docker containers but not having requirements or skills to operate Kubernetes. The most interesting part of VIC is the networking concept very well explained in following video https://www.youtube.com/watch?v=QLi9KasWLCM&feature=youtu.be
As one of my customers is considering VIC to provide containers to their developers, I have decided to test it in my home lab.
The first step is to deploy VIC from OVF. It's pretty straight forward so I'm not going to document any details.
The second step is to create the first VCH (Virtual Container Host), which acts as a remote Docker server. You can have multiple VCH's and they can be grouped into projects. Let's keep architectural decisions besides at the moment and focus on testing the technology itself.
VCH deployment is typically done via vic-machine CLI Utility as GUI is too slow interface for DevOps approach. Documentation is available at
https://vmware.github.io/vic-product/assets/files/html/1.5/vic_vsphere_admin/using_vicmachine.html
VIC-MACHINE ... is the primary tool for DevOps admin. I will discuss roles, tooling, and RBAC for particular actors in DevOps approach in the next blog post together with the overall architecture.
We can download vic-machine from VIC appliance deployed in step 1. In my case, it is available at https://vic.home.uw.cz:9443/
When we have vic-machine available in our DevOps workstation we can start act as a DevOps engineer.
Note 1:
If you have self-signed certificate as I have in my lab, you need to get vCenter Thumbprint.You have to ssh to vCenter Server Appliance and get the fingerprint.
openssl x509 -in /etc/vmware-vpx/ssl/rui.crt -fingerprint -sha1 -noout
The vCenter thumbprint in my lab is
SHA1 Fingerprint=64:06:CD:4E:D8:39:8B:E8:80:2D:D3:25:50:C7:B9:7D:E1:6F:8B:E9Note 2:
vic-machine tool is available for various operating systems (windows, linux, darwin). As my workstation is Mac OS X (aka darwin), in commands below I will use ./vic-machine-darwin
Before the first VCH deployment, we have to enable the firewall rules in a particular vSphere cluster (the name of vSphere Cluster in my home lab is CLUSTER).
./vic-machine-darwin update firewall --target vc01.home.uw.cz --thumbprint 64:06:CD:4E:D8:39:8B:E8:80:2D:D3:25:50:C7:B9:7D:E1:6F:8B:E9 --user administrator@uw.cz --compute-resource CLUSTER --allow
Now we are ready to create our first VCH.
Here is the command, how to create VCH.
./vic-machine-darwin create --name vch01 --container-name-convention vch01-{name} --compute-resource CLUSTER --image-store vsan-Underlay --base-image-size 8GB --bridge-network VCH01-BRIDGE --bridge-network-range 172.16.0.0/12 --public-network MGMT --dns-server 192.168.4.4 --container-network CONTAINER01:container01 --container-network-ip-range CONTAINER01:192.168.51.0/24 --container-network-gateway CONTAINER01:192.168.51.254/24 --container-network-dns CONTAINER01:192.168.4.4 --container-network-firewall CONTAINER01:published --tls-cname vch01 --certificate-key-size 2048 --no-tlsverify --user admin@UW.CZ --thumbprint 64:06:CD:4E:D8:39:8B:E8:80:2D:D3:25:50:C7:B9:7D:E1:6F:8B:E9 --target vc01.home.uw.cz/SDDC --ops-user administrator
The output from the command looks similar to ...
INFO[0068] VCH Admin Portal:
INFO[0068] https://192.168.4.140:2378
INFO[0068]
INFO[0068] VCH Default Bridge Network Range: 172.16.0.0/12
INFO[0068] VCH Default Bridge Network Width: 16
INFO[0068]
INFO[0068] Published ports can be reached at:
INFO[0068] 192.168.4.140
INFO[0068]
INFO[0068] Management traffic will use:
INFO[0068] 192.168.4.140
INFO[0068]
INFO[0068] Docker environment variables:
INFO[0068] DOCKER_HOST=192.168.4.140:2376 COMPOSE_TLS_VERSION=TLSv1_2
INFO[0068]
INFO[0068] Environment saved in vch2/vch2.env
INFO[0068]
INFO[0068] Connect to docker:
INFO[0068] docker -H 192.168.4.140:2376 --tls info
INFO[0068] Installer completed successfully
Davids-MacBook-Pro:vic-machine dpasek$
My first VCH has been created with a single container network (network name CONTAINER01). To add another container network (CONTAINER02) we need to know VCH id, therefore inspect command has to be used.
./vic-machine-darwin inspect --target vc01.home.uw.cz --thumbprint 64:06:CD:4E:D8:39:8B:E8:80:2D:D3:25:50:C7:B9:7D:E1:6F:8B:E9 --user administrator@uw.cz --compute-resource CLUSTER --name vch2
INFO[0005] VCH ID: vm-299
INFO[0005]
INFO[0005] VCH Admin Portal:
INFO[0005] https://192.168.4.140:2378
INFO[0005]
INFO[0005] VCH Default Bridge Network Range: 172.16.0.0/12
INFO[0005] VCH Default Bridge Network Width: 16
INFO[0005]
INFO[0005] Published ports can be reached at:
INFO[0005] 192.168.4.140
INFO[0005]
INFO[0005] Management traffic will use:
INFO[0005] 192.168.4.140
INFO[0005]
INFO[0005] Docker environment variables:
INFO[0005] DOCKER_HOST=192.168.4.140:2376 COMPOSE_TLS_VERSION=TLSv1_2
INFO[0005]
INFO[0005] Connect to docker:
INFO[0005] docker -H 192.168.4.140:2376 --tls info
INFO[0005] Completed successfully
Note that to configure additional network we have to add all already existing networks into the command as well.
./vic-machine-darwin configure --target vc01.home.uw.cz --thumbprint 64:06:CD:4E:D8:39:8B:E8:80:2D:D3:25:50:C7:B9:7D:E1:6F:8B:E9 --user administrator@uw.cz --id vm-299 --container-network CONTAINER01 --container-network CONTAINER02
Docker client is using VCH (aka Virtual Container Host) as a docker server
export DOCKER_HOST=192.168.4.140:2376
docker --tls info
docker --tls network ls
Here is the output of the networks available in my Docker host (aka Virtual Container Host)
dpasek@photon-machine [ ~ ]$ docker --tls network ls
NETWORK ID NAME DRIVER SCOPE
4313b6b0ab2e CONTAINER01 external
6eb9e8911266 bridge bridge
dpasek@photon-machine [ ~ ]$
and after vic-machine command to add additional network CONTAINER02 you can see the network in container host (VCH) and use it for our containers.
dpasek@photon-machine [ ~ ]$ docker --tls network ls
NETWORK ID NAME DRIVER SCOPE
4a8318cb2738 CONTAINER01 external
a011cf3ced72 CONTAINER02 external
7445a9e714ed bridge bridge
dpasek@photon-machine [ ~ ]$
Of course, we can use other standard docker commands to manage our docker images and containers.
docker --tls images -a
docker --tls ps -a
Run NGINX and access the service through NAT
docker --tls run --name nginx1 -d –p 8080:80 nginx
docker --tls ps -a
docker --tls images -a
Run NGINX and access the service directly through container network (IP address assigned via DHCP)
docker --tls run --name nginx2 --network="container01" -d -p 80 nginx
Run NGINX and access the service directly through container network (IP address assigned staticaly)
docker --tls run --name nginx30 --network="container01" --ip="192.168.51.30" -d -p 80 nginx
Execute a Shell Command from a Container
docker --tls run busybox date
docker --tls ps -a
In the screenshot below you see what vSphere Admin has in his environment.
 |
| Containers visibility for vSphere Admin |
 |
| Specific container (nginx) visibility for vSphere Admin |
If you need persistent storage for your containers, you can create volumes which are persistently stored in your enterprise infrastructure and visible not only to DevOps admin and Developer, but also to your infrastructure administrator.
Create a Docker Volume
docker --tls volume create --opt Capacity=2GB --name volume-test
docker --tls volume ls
docker --tls volume inspect volume-test
Attach a Docker Volume to a Container
docker --tls run --name busybox -it -v volume-test:/data/volume-test busybox
# cd /dataThis is what Developer and DevOps admin see via Docker Client
/data # ls
volume-1
/data # ls –l
total 4
drwxr-xr-x
/data # df -h
dpasek@photon-machine [ ~ ]$ docker --tls volume ls
DRIVER VOLUME NAME
vsphere volume-test
And this is what vSphere Admin can see in his environment
 |
| Docker volume (2 GB) is visible as 1.92 GB Hard Disk |
DevOps admin manages Virtual Container Hosts. Here is the command to list all VCH's from a particular vCenter.
./vic-machine-darwin ls --target vc01.home.uw.cz --thumbprint 64:06:CD:4E:D8:39:8B:E8:80:2D:D3:25:50:C7:B9:7D:E1:6F:8B:E9 --user administrator@uw.cz
Davids-MacBook-Pro: vic-machine dpasek$ ./vic-machine-darwin ls --target vc01.home.uw.cz --thumbprint 64:06:CD:4E:D8:39:8B:E8:80:2D:D3:25:50:C7:B9:7D:E1:6F:8B:E9 --user administrator@uw.cz
INFO[0000] vSphere password for administrator@uw.cz:
INFO[0003] ### Listing VCHs ####
INFO[0003] Validating target
ID PATH NAME VERSION UPGRADE STATUS
vm-299 /SDDC/host/UNDERLAY/CLUSTER/Resources vch2 v1.5.4-21221-b3d3b06f Up to date
Davids-MacBook-Pro:vic-machine dpasek$
Delete VCH
And here is the command to destroy particular VCH.
./vic-machine-darwin delete --target vc01.home.uw.cz --thumbprint 64:06:CD:4E:D8:39:8B:E8:80:2D:D3:25:50:C7:B9:7D:E1:6F:8B:E9 --user administrator@uw.cz --name vch2 --compute-resource CLUSTER
Conclusion
DevOps is a big topic nowadays. It is worth to say that DevOps is about methodology and not the tooling. At the end of the day, it doesn't matter if you use Docker, Kubernetes, Ansible or even more traditional tools. What matters is the final product which has to be developed in sync with the business owner, otherwise, there is a high chance you are not meeting business owner expectations. I'm ex-developer, Software Engineer / Architect and now I work as an Infrastructure Technical Designer / Architect, therefore I know, the DevOps methodology is the best way how to develop and deliver a business application to the business owner. The key principles of DevOps methodology are to identify the core business requirements, quickly develop the application prototype, present it to the business owner, validate if the business owner expectations are met and if so, move the prototype into production and continuously develop and deploy additional business requirements in short iterations with continuous feedback from the business owner. For such an approach, you need to deploy your application into infrastructure dynamically and quickly. Traditional Enterprise Infrastructure is not ready for such agility.
In this blog post, we were testing the tool (VMware vSphere Integrated Containers) which can help Developers, DevOps admins and infrastructure admins cooperate in an agile fashion. It might or might not help to deliver successfully the business project. However, it definitely helps DevOps teams to have agile DevOps infrastructure with Enterprise level of support, security, availability, and cooperation between Developers, Security, and Infrastructure (compute, storage, network) teams which each lives in the totally different world and they do not understand each other :-)
In my opinion, vSphere Integrated Containers is a great technology to start DevOps in the Enterprise environment. We all know that Enterprises will eventually adopt Kubernetes as it is nowadays a "de facto" standard for DevOps infrastructure, however huge Docker Hosts backed by solid enterprise infrastructure (VMware vSphere) is good enough for anybody just starting with DevOps methodology. In the near future, VMware vSphere will have integrated Kubernetes (watch the Project Pacific) and DevOps teams will be able to transform their DevOps tooling into another level.
In the next post, I will focus on the Architecture Design of DevOps environment leveraging VMware vSphere Integrated Containers.
Hope this blog post helps at least one other person in the great VMware community.
3 comments:
Can I use docker compose instead of docker to have multiple containers in individual C-VM ? so basically not have to ideally have one VM per container but rather one C-VM for group of containers that are stateless (like a Kubernetes POD definition that can have multiple container)
Well, you can use docker compose, but there are some limitations due to Docker API emulation VMware is doing in VIC implementation. Read further details at https://vmware.github.io/vic-product/assets/files/html/1.5/vic_app_dev/deploy_multiple_docker_compose.html
And I have the question ... why not use Kubernetes when you want K8s features? VMware has vSphere 7 with Kubernetes and other Tanzu K8s clusters options for enterprise use cases or you can choose RedHat Openshift or Vanilla Kubernetes if VMware Tanzu does not fit your requirements. Can you share the reasons why you would consider VIC rather than K8s? To be honest, this container world is still very new to me so I’m interested in real user use cases and thoughts.
Post a Comment