@fwgdocs
Sehr interessante Idee, ich sage: Zum Teil. Es gibt einfach Vorteile von VMs (Migration), die durch Docker auf baremetal nicht ersetzt werden koennen. MaaS von Ubuntu ist in dem Punkt ja aehnlich und setzt sich auch nicht durch.
Ich denke am Ende wird es so laufen, dass agnostic services massiv ueber VM image mit installiertem Docker laufen werden, waehrend alles andere VM images + Provisionierung werden (DBs etc.).
@MarcDK
Du bringst da Dinge durcheinander. Puppet/Chef/CFEngine/Ansible etc. sind Werkzeuge zur Provisionierung. D.h. es wird immer ein Objekt gegeben, was einen definierten Zustand erreichen soll. Das kann z.B. eine VM sein, die am Ende ein Webserver ist. Das erfolgt ueber Definitionen (bei chef nennt man das cookbook mit recipes, ansible hat playbooks mit tasks etc.).
Docker hat aehnliches als Dockerfile. Darin laesst sich definieren, wie der Container zusammengebaut werden soll. Das ist dem provisioning extrem aehnlich. Das ist aber sehr viel simpler gestaltet als z.B. ein recipe bei chef. Es gibt zum Beispiel keine Weichen (z.B. chef cookbooks muessen moeglichst frueh erkennen, was das OS der Maschine ist, die gerade provisioniert werden soll). Das ist auch nicht notwendig, da das Resultat eben genau definiert ist. Du kannst quasi den Container am Ende auf einen USB stick kopieren und ins RZ tragen. Oder den container auf irgendeinem linux ausfuehren, was lxc container (basis von docker) unterstuetzt. Alles was in dem Container laeuft darf sich vom Konzept nicht fuer die Aussenwelt interessieren (z.B. wer fuehrt mich aus?). Deshalb gibt es auch in diesen Dockerfiles keine Moeglichkeit automatisiert irgendwelche Ordner vom Hostsystem einzubinden. Waehrend des Erstellens des Containers kann man ohne Probleme Files in den Container kopieren, zur Laufzeit geht das aber nicht mehr.
Die grossen Vorteile:
- Der VM typische Overhead ist nur minimal vorhanden
- Ein gebauter Container kann ueberall laufen, wo Docker laufen kann
- Ein Container laeuft ueberall gleich, egal ob im RZ auf Hardware, auf einer VM oder auf dem Ubuntu des App-Entwicklers.
Die grossen Nachteile:
- Man ist quasi auf Wegwerf-Applikationen begrenzt (ergo kannst du z.B. ein wordpress blog mit nginx, php und mysql in einen container tun, es ist aber nicht schlau, weil der container nur ueber sich selber Bescheid weiss. Will man jetzt zwei Nebeneinander laufen lassen, haben beide ihre eigene Datenbank). Das ist eins von den Themen, die Kubernetes versucht zu verbessern, indem Abhaengigkeiten ausserhalb der Container definiert werden.
- Es laeuft nur auf linux. Klingt erstmal nicht so schlimm, wenn man aber mit OS X oder sogar Windows arbeitet wirds hackelig. Da hilft Vagrant momentan etwas, hat aber noch einen bescheuerten Haken mit portforwarding.
- (Noch) keine automatisierte seemless Migration von einem Host zum anderen. Dank der Wegwerfmentalitaet duerfte das eigentlich egal sein, da man ja einfach einen zweiten container anschubsen und den dns namen umziehen kann.
lxc ist uebrigens nichts neues, es setzt sich nur so langsam durch, weil Docker endlich mal werbewirksam ist.
@PaddyG
Naja, das ist halt ein aktuelles DevOps und System Engineering Thema und die wenigsten im Consumer-Bereich duerfte das interessieren. Prinzipiell finde ich es aber lobenswert, dass CB in letzter Zeit gerne mal ueber so etwas berichtet. Aber eine Sache bei dem Heise Artikel: Ich stimme dem Autor absolut nicht zu, wenn er von hoeherem Einstiegsaufwand bei der Konfiguration spricht.