Orchestrate Stateful Containers Using Docker Swarm and vSphere Docker Volume Service

This blog is written by Liping Xue who is a software engineer in Cloud Native Applications Storage team. She focuses on vSphere Docker Volume Service.

As described in this blog,  we can see that users have strong demands to run data intensive workloads in containers. Although Docker has good support for running stateless applications which dominate the micro services era, it lacks enough support to enable users to run stateful applications effortlessly.

Starting 0.12 release, Docker has introduced swarm mode which is a great tool to setup a clustered Docker environment to run applications quickly and efficiently.  In Docker swarm mode, users can deploy an application image as a service easily.

Swarm manager accepts the service definition as the desired state of the service, and tries to maintain the desired state of the service automatically. For example, if a user deploys a “Nginx” service to the swarm cluster and specifies the number of replicas of the service to 1, swarm manager will figure out which node to run this task on and starts this task by creating a container on the selected node automatically. If the node running the task is down for whatever reason, swarm manager will automatically create another container on one of the remaining nodes. No user intervention is needed. Sounds great! Unfortunately, it only works well if the service is a stateless service.

When a user deploys a stateful service like PostGreSQL, swarm manager will start the container on a node and attach the container to a local volume created by Docker. In case of a node failure, swarm will create another container on another node but leaving data behind which is not good. Long lived stateful service like database need persistent storage which should exist outside the container because it has a life span longer than the container which uses it.  With vSphere Docker Volume Service  (vDVS), a user can create highly available Docker Volumes by using either vSAN, NFS or VMFS as the underlying storage.  Here is the introduction about this. vDVS provides a real persistent layer to run stateful containers with the benefit of all the enterprise capabilities.

In this post, we’d like to show you how to deploy a stateful service like PostgreSQL with Docker swarm mode and vDVS.


Our configuration includes three VMs, named “swarm01”, “swarm02” and “swarm03”. Each VM has a Docker engine and vDVS installed. All three VMs are running on vSphere and have access to a shared vSan Datastore. We create a swarm cluster with those three VMs, and the following tables shows the role of each VM in the swarm cluster. Please refer here on how to create a swarm cluster.
VM name      Role
swarm01     manager
swarm02     worker1
swarm03     worker2

Deploy PostGreSQL service using “docker stack” command

We run “docker stack deploy” command from the swarm manager(“swarm01”) to deploy a stack with the following yaml file:

The following shows the command to deploy the service and check the status of the service after deploy .In the above YAML file, we define the service needed to mount a volume “postgres_vol” which maps to “/var/lib/data” to store the database file. That volume is created by vDVS.

We can see that, after deploy, a volume “postgres_postgres_vol” is created on the “vsanDatastore”, and a container starts  running on node worker1(“swarm02”) with the volume attached, which is shown in the following diagram.


Then we run “docker inspect” command to inspect the service. In the “Mounts” section of the output shown below, we can see that the source of the mounts is “postgres_postgres_vol”, which was created by vDVS.  We can also see the driver specific options  in the “DriverConfig” section when the volume was created.

Connect to PostGreSQL service

Then we try to connect to the service through PostgreSQL client. We connect to swarm manger’s IP at port 5432, then create a table “user” with two columns “name” and “department”.

We then insert the following three rows into table “user”.

DB table is persistent after node failover

We shutdown node worker1(“swarm02”). After node shutdown, swarm manager restarts the container on another worker node worker2(“swarm03”) with the same volume attached, which is shown in the following diagram.


Then we try connect to swarm manger’s IP at port 5432 again, and check the content in table “user”.  The content in table “user” keeps unchanged as expected.

As you can see,  vDVS implements a persistent storage layer for Docker Swarm mode which enables users to run stateful applications as a service easily.

We would love to hear your feedback! We will be at DockerCon. Please drop by at booth G9 to learn more about what we have to offer.

If you are interested in contributing code or have any questions or feedback, you can reach us at

Let’s block ads! (Why?)

VMware Blogs

Leave a Reply

%d bloggers like this: