Am 07.06.19 um 16:24 schrieb Heiko Schlittermann:
Thomas Güttler <guettl...@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 LibFoo
Nun 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
--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
