If you’ve started using Docker for a while you might be asking the same question «how to manage a group of Docker containers into a consistent topology?».
On your local workstation, projects such as fig simply help you do the job: local, fast, easy.
Flocker gets a step further by adding some major features:
- Multi-hosts management: containers can be spread onto several Docker hosts, called nodes,
- ZFS-based shared filesystem: store your non-volatile storages onto it to deal with high-availability.
The magic in Flocker network proxy design allows you to talk to any of the nodes to reach any container. The price is that exposed ports must be unique per container to avoid conflicts.
Flocker relies on two YAML files describing
- The applications involved into the topology (think a DB server, an app server, links and so on): application.yaml
- A static definition of the containers location (on which node they run): deployment.yaml
Flocker YAML files are declarative. Flocker will perform the needed operations to comply with the YAML files, and nothing if it is all set-up. To move a container from a host simply modify the location of the container into deployment.yaml and rerun Flocker.
Actually, container motion is not the correct term as containers are destroyed on a node and then re-created on another one.
You may really have a look at two Vagrant-based tutorials to understand the basics of Flocker:
- A simple single MongoDB tuto explaining a container motion and the need for data persistence,
- An ELK example, more advanced which involves the famous ElasticSearch, LogStash and Kibana stack.
Many questions remain about flocker:
- How hard is it to setup the underlying multi-host ZFS configuration? Do we need Puppet/Chef/SaltStack/Ansible to do so?
- How to handle container pools (as in fig scale)?
- How fast?
- Live Migration?
- Automatic Container start / restart?
However, it’s totally worth it having a look. I bet some of its ideas might probably be reused into other projects (such as Kubernetes).