Docker ist weniger interessant für Endnutzer. Noch viel weniger die zugehörigen Tools. Die hier vorgestellten Tools erleichtern aber das Leben eines Entwicklers/Admins ungemein.
Ich verpacke zur Zeit selbst einige (teils alte) Webanwendungen einer SOA-Landschaft in Container und bin wirklich begeistert von dem Toolset. Früher hat es mindestens einen halben bis ganzen Tag gedauert, bis ein neuer Entwickler im Team halbwegs die Anwendungen bei sich lokal eingerichet hatte, um entwickeln zu können. Dieses Setup hatte dann aber wenig bis gar nichts mit dem zu tun, was auf QA/Production läuft. Wollte man das, hätte man noch deutlich länger gebraucht.
Durch Docker (in Verbindung z.B. mit gradle, aber ein shell script tut es auch) kann man das Ausrollen eines solchen Environments, auch lokal, quasi "vorscripten". Das war zwar auch schon vorher mit Tools wie Vagrant möglich, aber doch deutlich schwergewichtiger, weil dort immer echte VMs hochgefahren wurden. D.h. man brauchte haufenweise RAM, weil jede VM ihr eigenes vollwertiges OS mitgebracht hat.
Fig (nun compose) kommt in dem Moment ins Spiel, wenn deine Anwendung Abhängigkeiten z.B. zu einem Webserver wie Apache, einer Datenbank, einer anderen Anwendung (SOA) o.ä. hat. Dann fährst du die nämlich einfach zeitgleich mit hoch statt alles einzeln zu starten.
Docker Machine kommt nun als Tool mit, um die händische Arbeit des Aufsetzens eines Docker-Hosts zu erleichtern. Bisher musste man die Ziel-VM entweder komplett manuell vorbereiten - d.h. docker dort installieren und auf Remote-Modus trimmen + Security-Geraffel, damit nicht jeder von außen auf deiner VM hochfahren kann, was er will - oder auf Tools wie Chef, Puppet, Ansible o.ä. zurückgreifen.
Swarm ist halt eine Art Management-Proxy, der dir die Arbeit insofern erleichtert, dass du nicht zu jeder deiner weltweit deployten 100 VMs händisch connecten musst, um einzelne Befehle auszuführen. Stattdessen sendest du die Befehle zu Swarm und das verteilt sie dann an alle ihm bekannten VMs.
