Am 07.06.19 um 16:24 schrieb Heiko Schlittermann:
Thomas Güttler guettliml@thomas-guettler.de (Fr 07 Jun 2019 16:04:53 CEST):
Aktuell muss ich nur SuSE-Enterprise, OpenSuse und Ubuntu unterstützen. Aber in verschiedenen Versionen. Das schon allein ist ein lustiger Kasper-Floh-Zirkus. Sicherlich kann man ins snap eine Apache-Konfig integrieren. Aber wie soll das über mehrere Distris hinweg funktionieren? Ich vermute, dass das doch wieder jedes mal pro Anwendungsfall mit Fallunterscheidungen gelöst ist. Das wäre coole "Magic" wenn das Distri-übergreifend geht.
Docker ist für sowas vielleicht wirklich Deine Antwort. Auch wenn es etwas shiny ist und vermutlich dahinter ordentlich stinkt.
Von rkt habe ich lange nichts mehr gehört, das fand ich damals besser, wenn auch nicht so einfach, weil es zu viel Flexibilität bot. (das übliche: Playmobil vs Lego)
Der Trend scheint klar zu Containern zu gehen, aber auch da sind teilweise mehr Fragen als Antworten. Gerade wenn es um Verantwortlichkeiten geht, Abhängigkeiten zu z.B. Libraries, die Du vielleicht nutzt, aber auch nicht trackst. Wer baut das Image neu? Wer ist für die Distro-Integration des Images beim Start verantwortlich usw.
Ich denke der Ablauf sollte etwa so sein:
- vanilla Image wird als Vorlage genommen. - Updates werden eingespielt - Config-Management Tool mach aus dem Image den Container, den man möchte - Continous Integartion prüft den Container - Falls alle Tests ok sind: Deployment.
Wenn es von der Distribution ein neues RPM/DPKG gibt (zB Security-Update), dann wird obiger Ablauf erneut durchgespielt.
Applikation linkt LibFooNun gibt es in LibFoo ein sicherheitskritisches Update. Wenn es ein Image ist, dann ist der Image-Erzeuger (vermutlich Du) verantwortlich, das möglichst zeitnah neu zu bauen.
Ist es ein Distro-Paket, wird vermutlich ohne Dein Wissen in der Distro die Library getauscht und alle Nutzer Deiner Applikation sind auf der sicheren Seite.
Dafür hast Du vielleicht mehr Arbeit, weil Du irgendwie mit allen Varianten von libFoo leben musst, erst recht, wenn es eine LibBar gibt, die behauptet, kompatibel zu LibFoo zu sein. Dieses Problem hast Du bei einer Container-Lösung nicht. Da schnürst Du alles zusammen, definierst die Schnittstellen zur Außenwelt (Port, Mountpoint, vielleicht erforderliche Services und fertig.) - na ja, hört sich einfach an, ist aber letzten Endes auch viel Gefrickel.
Mir gefällt dabei die klare Trennung zwischen Code und Daten. Der Container ist der Code, er ist ohne Gedächtnis (ohne Datenspeicher). Er kann dadurch super leicht ausgetauscht werden. Kein ssh+vi mehr :-)
Auch wenn ich es schon lange als sinnvoll ansehe, habe ich bisher nicht darauf umgestellt.
Erstmal die Pioniere mit Entdecker-Engagement die Bugs rausmachen lassen :-)
Gruß, Thomas