This content is part of the Conference Coverage: VMworld 2017 conference coverage

Conference Coverage

Browse Sections

Roadblocks highlight common VMware VIC and Docker container issues

VMware vSphere Integrated Containers has many positive selling points, but running a microservices demonstration with Docker containers isn't one of them.

VMware vSphere Integrated Containers purports to help organizations seamlessly run containerized applications,...

but existing limits make it a hassle to get containers to run under vSphere.

VSphere Integrated Containers (VIC) allows customers with existing applications running in vSphere VMs to add containers to their estate. Container-based applications run as VMs alongside conventional applications in VMs. Developers get to use Docker commands, and operations use vSphere. In a previous article, I showed how easy it is to deploy a virtual container host (VCH) with VIC and then use Docker commands to deploy a web server in a container. Next, I showed how to add graphical management tools to manage containers and container images. In this article, I originally intended to show how to deploy a complex application made up of several containers but ran into some complications along the way that highlight issues with both Docker containers and VMware VIC.

VMware VIC lacks Docker image support

The first demonstration I like to use is the voting application; it is one of Docker's sample applications and lives on GitHub. I have Docker for Mac on my laptop, which allows me to run containers the same way a developer might. To start the voting app, I cloned the GitHub repository and ran the docker-compose up –d command in the Downloaded folder. Docker Compose read a configuration file, built five container images and then launched the five containers. This process took a few minutes. Once it was complete, I chose between cats and dogs -- as you can see, we're a cat household.

Docker sample app
Figure A. Docker sample voting application

This process runs the same on a Windows machine with Docker Toolbox, so developers will have the same experience regardless of whether they use a Mac or Windows machine.

I ran into issues when I tried to move this app onto my production platform. VMware VIC doesn't offer support to build Docker images, so Docker Compose failed almost immediately because VIC won't build the images. I suspect VMware's rationale behind failing to provide this build support is that enterprise customers have their own container registry and will build their container images as part of the continuous integration/continuous deployment (CI/CD) process. Clearly, the CI/CD cannot use VIC to build the images. I also imagine there are customers who don't want to move images from development directly to production, so it would be helpful for VMware to add the docker build command to VIC.

The VMware VIC documentation on how to build the voting app for VIC tells you to build the container images on another machine and upload to a repository. I tried to follow these instructions but was unable to get a working voting app under VIC; a couple of my containers crashed as soon as they started. Not a great start to show a multicontainer demo with VIC.

VIC runs into trouble with file mapping

A quick Google search led me to a different demo application; this one is a web store demo produced by Weaveworks. This app uses container images downloaded directly from Docker Hub, Docker's public image repository. I just needed the docker-compose.yml file on my laptop and to run the docker-compose up –d command for the application to start. This time, there were around 15 container images to download, so it took a few minutes. After the containers started, I was rewarded with a nice graphical web store that was happy to sell me hypothetical socks.

Weaveworks demo app
Weaveworks web store demo application

Like the voting app, the sock shop worked fine on my Mac and Windows PC but failed with VIC. This time it was because a developer used file mapping to get information from the Docker host to one of the containers. VIC doesn't support local mappings and isn't a Linux machine, so it doesn't have standard Linux files. The developer incorrectly assumed that the user would use a Linux container host. This is a classic issue with moving code from development to production -- an issue that containers are supposed to prevent. Containers promise write once and run anywhere, but the reality doesn't always live up to this promise. Such assumptions and poor application development can cause problems. To start the sock store demo app on VIC, I removed mapping from the YAML file. However, doing this only brought up the webpage header; I was unable to order any socks. As you can see, it isn't as easy to run a multicontainer demo on VMware VIC as I initially presumed.

Containers promise write once and run anywhere, but the reality doesn't always live up to this promise.

So, what did I learn from my day of trying to run a microservices demonstration on VIC? I learned that it's complicated: Containers aren't a silver bullet to bring application deployments to production. I learned that VIC isn't functionally identical to Docker on my laptop and, by extension, any developer's laptop. I learned that developers will find ways to make operations difficult and that careful coding is essential. On the positive side, I also learned how to set up a VCH to use certificates and set environment variables and how to use the VCH and those certificates without specifying them on the Docker command line. I'm a little disappointed that VMware VIC isn't as complete as I'd like. I'm still a fan of containers as a way to run applications but am certain that good developers are central to getting good applications in production.

Next Steps

Container competition heats up between VMware and Docker

Docker containers strive to live up to the hype

What's so special about vSphere Integrated Containers?

Dig Deeper on VMware performance enhancements