As many of you know docker-machine is the client side tool that allows an individual on his/her own workstation to fire up docker hosts either locally or remote.

Docker-machine supports a variety of “drivers” to accomplish this. Some of these drivers deploy locally (e.g. Virtualbox, VMware Fusion), some of them deploy inside the data center (e.g.  OpenStack, VMware vSphere) and others can deploy in public clouds (e.g. AWS, VMware vCloud Air).

As I was experimenting with the vSphere driver for some tests I was doing with Docker Swarm, I found that the number of options available on the vSphere driver and the flexibility it provides, could make its usage challenging without proper examples to kick off the scripting.

For this reason, I am sharing some of the scripts I have used for my experiments with the ultimate goal of providing solid practical examples of how to use those vSphere parameters.

For your convenience, I am also attaching the variable configuration examples in this post.

This is how you’d configure the variables or corresponding options if you were to deploy to a vCenter server:

VSPHERE_VCENTER=                                                                # vCenter IP/FQDN

VSPHERE_USERNAME=’administrator@vsphere.local’                             # vCenter user

VSPHERE_PASSWORD=’***********’                                                             # vCenter user password

VSPHERE_NETWORK=’VM Network’                                                          # PortGroup

VSPHERE_DATASTORE=’datastore1′                                                          # Datastore

VSPHERE_DATACENTER=’Home’                                                               # Datacenter name

VSPHERE_HOSTSYSTEM=’Cluster1/*’                                                        # cluster name

#VSPHERE_POOL=’/Home/host/Cluster1/Resources/SwarmTeam13′        # *optional* Resource Pool name

This is how you’d configure the variables or corresponding options if you were to deploy to a standalone ESXi host:

VSPHERE_VCENTER=                                                          # ESXi IP/FQDN

VSPHERE_USERNAME=’root’                                                                      # ESXi user

VSPHERE_PASSWORD=’***********‘                                                              # ESXi user password

VSPHERE_NETWORK=’VM Network’                                                           # PortGroup

VSPHERE_DATASTORE=’datastore1′                                                           # Datastore

#VSPHERE_POOL=’/*/host/*/Resources/SwarmTeam9′                               # *optional* Resource Pool name

In particular, the syntax to use for the VSPHERE_POOL variable (or corresponding options) requires a bit of attention.

Let’s say, for example, that you want to deploy a 5-node Swarm cluster in a vCenter Resource Pool called “SwarmTeam13”, inside a cluster called “Cluster1”, in a data center called “Home”.

To do so, you will use the first syntax above inside the script and then you will run it on your workstation using the following parameters:

> ./ 5 vmwarevsphere vcenter

Note: the VSPHERE_POOL variable has to be set if you want to deploy inside a Resource Pool (and not in the root of the cluster) so you need to remove the comment preceding the variable.

This is what you will see in the vCenter UI once the script has completed:


You can set the proper environmental variables to access the Swarm cluster by running the following command at the prompt:

> eval $(docker-machine env –swarm swarm-node1-master)

If you want to play with the scripts and deploy / destroy an entire multi-node Swarm cluster on vSphere, just grab them here.





Quote_VMware_isdeveloping Copy

Listen to podcast >>

The concept of microservices is built on the need to develop apps faster, be more resilient and offer a great experience for the customer. However, the new practices that come with microservices means smaller teams that need to work iteratively, often in a manner that is unfamiliar to companies that work in a top-down fashion. This means sweeping changes to how businesses function that we are just now starting to realize. First, it’s now less expensive to build software, and containers have made it even more affordable. Docker is on everyone’s roadmap — from software vendors to end users, all trying to figure out how to use containers — because they can accelerate software delivery. But it also means that the systems need to be instrumented at the application level, which means different requirements for developing, deploying and managing applications.

In this podcast with NewStack, Kit talks about customers who want a DIY approach are seeking to support application technologies with vSphere Integrated Containers (VIC) and Photon OS to accelerate deployment. Learn more.

Follow us @cloudnativeapps