0

For our continuous integration environment, we want to start working with docker swarm and the latest version V3 of the compose files specification. (Docker 1.13.1 and docker-compose 1.10.0).

We are currently working with V2 and therefore deploying everything to host level.

It is possible to work, for data containers --database data-- or statefull containers, with local volumes in swarm mode, with affinity so that the database container and the data containers reside on the same host ? Makes sense?

We know that there are several plugins to work with distributed volumes -Flocker, NFS, etc --- but we do not know what are the advantages and disadvantages of this scheme with respect to local volumes,

With docker swarm, for the case of distributed stateful containers, who is responsible for maintaining data consistency and synchronization?

Thank you very much for the help

Regards, Marano

1 Answers1

0

It is possible to work, for data containers --database data-- or statefull containers, with local volumes in swarm mode, with affinity so that the database container and the data containers reside on the same host ? Makes sense?

One of the main features of swarm mode is providing high availablity for node failure. Using affinity to pin down the containers to single nodes will cause the service outage on node failure.

Now in order to achieve bind mounts/volumes across multiple nodes you have these options:

  1. Use a cluster filesystem like glusterfs, ceph and ... across swarm nodes, then use bind mounts in your service defenition pointing to shared fs.

  2. Use one of the many storage drivers available to docker that provide shared storage like flocker, ...

  3. Switch to Kubernetes and take advantage of automated volume provisioning using multiple backends via Storage classes and claims.

We know that there are several plugins to work with distributed volumes -Flocker, NFS, etc --- but we do not know what are the advantages and disadvantages of this scheme with respect to local volumes.

Depends on the solution, workload, the application but main advantage would be: you dont need to use affinity and you can achieve high availablity for your stateful containers too. Although I suggest you move to kubernetes for more suphisticated persistent storage provisioning and scale handling.

With docker swarm, for the case of distributed stateful containers, who is responsible for maintaining data consistency and synchronization?

Application itself. Cloud ready applications do that automatically. Take a look at elasticsearch, cockroachdb, mongodb, ...

Farhad Farahi
  • 35,528
  • 7
  • 73
  • 70