Post by Ralph AichingerNein, ich meine mehr die Komplexität von Installation und Administration.
Die ist bei Swarm niedrig, bei Kubernetes und Mesos erheblich höher. Für
beide gibt es Installer die das in eins durchziehen, aber nach dem
Verteilen der diversen Komponenten fängt da der Spaß erst an. Das will ja
auch konfiguriert und verstanden werden.
Post by Ralph AichingerDerzeit ist das wohl nur für die motiviertesten Privatnutzer und Hobbyisten,
aber auch nur für sehr wenige kleinere Betriebe interessant.
Das kann ich mindestens für Docker swarm mode nicht ganz so gelten lassen.
Eine erste Installation und ein Grundverständnis für notwendige Tätigkeiten
schafft jeder mit Linux-Erfahrung in einem halben Tag. Das bedeutet aber
*nicht*, das ich Container überall für sinnvoll halte. Gerade in dem Umfeld
ist der Nutzwert in vielen Fällen begrenzt.
Post by Ralph AichingerSpannend wird, ob das irgendwann mal so ausgereift wird, daß es eine
auch für kleinere Szenarien (sagen wir z.B. 5-10 Nodes) eine lohnende
Übung wird (z.B. weil man bei 5 Knoten schon stressfrei welche aus
dem Cluster nehmen kann ohne sich um Ausfälle sorgen zu müssen).
Viele gehen einfach von live migration aus: Das gibt es (Stichwort für die
Suchmaschine lautet CRIU), ist aber AFAIK noch bei keiner Lösung aus der
beta-Phase raus. Die gehen ja als Regelfall davon aus, das ein Container
statuslos ist, also einfach gekilled und woanders neu gestartet werden
kann. Ansonsten gibt es natürlich Dinge wie einen Wartungsmodus, damit ein
Server im Cluster nichts mehr annimmt.
Post by Ralph AichingerWenn man dafür dann auch Off-the-Shelf-Hardware nehmen kann, dann wäre
das doppelt lohnend.
Das geht. Und ein fünf bis zehn Knoten Cluster ist IMHO für Docker Swarm
durchaus keine seltene Größe. Bei Mesos oder Kubernetes wäre das eher
klein. Im Gegensatz zu VMs sind Container aber derzeit keine Universal-
lösung, auch wenn manches es leider so verkaufen. Programme mit Daten-
haltung, zum Beispiel DBs wie Postgres, sind die große Herausforderung.
Wer nicht schon an anderen Stellen von Containern profitiert, sollte es da
einfach bleiben lassen.
Für ein kleines Cluster, am besten noch mit Teilzeit-Admins finde ich sowas
wie Proxmox und ähnliche Lösungen - ich bin da religionslos :-) - deutlich
naheliegender. Container will man IMHO, wenn man entweder nur Anwendungen
darin betreibt die das auch ohne viel Zuwendung verkraften. Oder man legt
viel Wert auf die zusätzlichen Möglichkeiten wie sehr schnelles, rück-
standsfreies Installieren und Entsorgen wechselnder Inhalte, zum Beispiel
für Testinfrastrukturen oder beim Skalieren. Ersteres ist at $WORK die
Hauptaufgabe: Wegwerf-Standardinstallationen für Entwickler, die "früher"
Vagrant+VMs genommen hätten.
Post by Ralph AichingerIm Prinzip ist es egal ob da LXC, oder Docker oder was auch immer drunter
liegt, wichtig wäre, daß sich ein bis zwei Setups rauskristallisieren
die soweit perfektioniert werden, daß sie einerseits eine Art Standard
bilden, und andererseits von jedem halbwegs motivierten Linux-User in
einer Woche rausgestampft werden können.
Mit Docker kommt man da schon sehr weit, aber sicherheitshalber :-)
nochmal: Da Container-Umgebungen ein paar Annahmen tätigen, z.B. das ein
Image unveränderlich ist, muss man im Cluster Themen wie Storage oft neu in
Angriff nehmen. Für Admins alles kein Hexenwerk. Ich würde aber nicht ohne
Not etwas mit Containern aufbauen, für das es Lösungen auf VM-Basis gibt
die viele Jahre mehr Zeit hatten, um zu reifen.
Post by Ralph AichingerBei halbwegs gegebener Kompatibilität zu Sachen wie AWS oder Azure,
Ein OCI- oder Docker-konformes Image ist nichts anderes als ein Tarball
plus Metadaten. Die kannst du problemlos hin und her schieben. Was nicht
standardisiert ist, sind die Ebenen oben drüber, insbesondere Komposition,
also das zusammenbauen einer Anwendung aus Webserver, Datenbank, etc. Die
naheliegende Lösung ist, den lokal genutzten Stack mitzunehmen oder dort
neu aufzusetzen, weil dessen Komponenten ja auch alle im Container laufen.
*Den* Standard gibt es dafür nicht.
BTW: Wir hatten jetzt schon zwei Hersteller, einen kleinen und einen sehr
großen (big blue), die mit "wir liefern das bevorzugt als Docker Images"
ankamen. Das wird mehr werden, gerade für alles was den Charakter einer
Blackbox/Appliance hat. Ich bin weit davon ab, das als Allheilmittel zu
sehen, kann aber schon aus diesem Grund jedem Admin nur empfehlen sich
damit zu beschäftigen. Je nach Sichtweise mutig, frech oder dumm ist die
Aktion eines anderen Projektes, alle Installationsmethoden außer Docker auf
deprecated zu setzen. Ich verstehe die Motivation - eine größere Python-
Anwendung für Kunden zu paketieren ist nicht immer trivial - aber viele
größere Firmen dürften sie dafür derzeit noch mit Missachtung strafen.
Post by Ralph AichingerPost by Bernd Waterkamp[0] Eine Art Verwaltungsfrontend für Docker Swarm, Mesos und Kubernetes,
das auch mehrere parallel unterstützt. Siehe http://rancher.com
Irgendsowas will ich daheim haben, ich weiß nur nicht genau was ;)
Kommt darauf an, was das Ziel der Aktion ist. Rancher hilft beim schnellen
Installieren dieser drei Lösungen. Wenn du "nur" Container einsetzen
möchtest, würde ich mir andere Dinge anschauen: IIRC nutzt du Distris aus
der Redhat-Familie. Da passiert durch die geschäftlichen Interessen an
diesem Umfeld derzeit sehr viel, das auch in Fedora und Centos Einzug hält.
Wenn du den letzten Schrei (aus deren Sicht) sehen willst, sind das Dinge
wie Project Atomic[0] oder buildah[1]. Ich vermute aber, du möchtest eher
eine Minimal-Installation deiner Standard-Distribution und ein wenig Zeit
mit docker verbringen. :-) Das brauchst du sowieso meistens unten drunter
und man kommt damit für einfach Tätigkeiten schon ziemlich weit. Ganz
nebenbei frischt du im Redhat-Umfeld vielleicht deine SELinux-Kenntnisse
auf, weil die immer öfter davon ausgehen, das es eingeschaltet ist. ;-)
Man frischt auch zwei andere Konzepte auf: Letztlich sind Container nichts
anderes als eine Kombination aus cgroups und Namespaces.
Grüße,
Bernd
[0] https://www.projectatomic.io - neues Betriebssystem: Images/Container
statt RPM.
[1] Container ohne jegliche Docker-Beteiligung. Noch ziemlich beta.