Docker - Updates

[greystone]

Nochmal die Fortsetzung der Frage zum Thema Docker & Updates von hier:

Ubuntu Major Update - kleine Frage

Hallo liebe Community, ich habe auf meinem Webserver aktuell die Ubuntu Version 20.04 LTS. Nun gibts es ja schon "seit ein paar Tagen" die Version 22.04 - ebenfalls LTS. Allerdings liegen mehrere Minor Releses dazwischen, die also keine LTS sind: 21.10 (Impish Indri) 21.04 (Hirsute Hippo)...

serversupportforum.de

Der Updateaufwand ist bei Docker minimal und kann sogar noch automatisiert werden (Watchtower), sobald neue Versionen von Containern erscheinen. So schnell updated wohl kaum jemand seine Anwendungen manuell.

Also in meiner Vorstellung bzw. Erfahrung bin ich ja erst einmal selbst für die Updates zuständig. D. h. im normalen Webservergeschäft führe ich dann je nach Anwendungssoftware (Typo3, Joomla, whatever, ...) die Updateprozeduren gemäß der Dokumentation durch. Das könnte ich auch automatisieren. Die Automation ist aber da auch ein gewisser Aufwand.

Bei Docker-Nextcloud habe ich jetzt gesehen, dass Nextcloud die installierte Version erkennt und entsprechend den Updateprozess startet, für den es selbst die Upgrade-Programme mit dabei hat. Bei einem gitlab, dass mir mein Vorgänger hinterlassen hat läuft es ähnlich, nur das die Upgrades da schon öfters Probleme gemacht haben(System kommt dann nicht mehr hoch).

Meine Frage zu der Aussage Der Updateaufwand ist bei Docker minimal und kann sogar noch automatisiert an Dich @Thunderbyte - oder falls mir das jemand anders beantworten mag - ist, ob das Deine Erfahrung des Normalzustandes ist: Alle möglichen Projekte - die Personen hinter der jeweilligen Software - stellen also jetzt jeweils in kurzen Zeitabständen aktualisierte Container bereit, die auch die programmatische Updatelogik enthalten, so dass man selbst jeweils nur noch den aktuell gepullten bzw. darauf basierenden Container neu bauen und starten muss? Also wahrscheinlich unter Beachtung der Upgrade-Richtlinien der jeweiligen Container.(Bei Nextcloud darf man z. B. nur eine Major-Version überspringen, sonst klappt das Upgrade nicht).

 

[Firewire2002]

Ob Update-Routinen in einer Docker-Umgebung wirklich weniger Aufwand sind, hängt von vielen Faktoren ab. Die aktuelle Ausgabe vom Linux Magazin hat da übrigens eine ganze Reihe interessanter Artikel zu Kubernetes und Docker drin.

Es gibt Umgebungen da ist man mit einer klassischen Linux Installation und Software-Pflege via Paketmanagement besser beraten, als mit einem Docker-Container.
Entscheidend ist letztendlich die betroffene Anwendung, wer das Image oder die Software-Pakete baut und auf welche Infrastruktur man sonst sowieso betreibt.

In vielen Fällen liefert der Hersteller einer Software eben keine fertig einsetzbaren Docker-Images. Wenn man sie selbst bauen und pflegen muss, bedarf es dazu auch ein bisschen Infrastruktur, denn dann möchte man es in der Regel automatisieren (Jenkins, Gitlab Runner, sonstige CI/CD Tools) und zentral speichern (Docker Registry, bspw Nexus Sonatype).

Hinzu kommt die Vertrauenswürigkeit der öffentlich verfügbaren Docker Registries. Denn Signaturen sucht man da vergebens. Docker baut nur Prüfsummen über die Layer um zu erkennen, ob die Layer noch passen. Aber GPG Signaturen wie man sie von DEB/RPM Paketen kennt, fehlen.
Ein Paketmanagement kann daher durchaus die sichere Kette zur Softwarepflege sein.

Container sind kein Allheilmittel für alles. Man muss es im Einzelfall abwägen, ob es speziell in deinem Szenario einen Mehrwert bietet.

 

[Thunderbyte]

Meine Frage zu der Aussage Der Updateaufwand ist bei Docker minimal und kann sogar noch automatisiert an Dich @Thunderbyte - oder falls mir das jemand anders beantworten mag - ist, ob das Deine Erfahrung des Normalzustandes ist: Alle möglichen Projekte - die Personen hinter der jeweilligen Software - stellen also jetzt jeweils in kurzen Zeitabständen aktualisierte Container bereit, die auch die programmatische Updatelogik enthalten, so dass man selbst jeweils nur noch den aktuell gepullten bzw. darauf basierenden Container neu bauen und starten muss?

Im Prinzip ja, würde ich sagen. Natürlich kann ich nicht für ALLE Softwarepakete sprechen. Insbesondere zusammengesetzte Setups mit mehreren Containern, die zusammen arbeiten sollen und eine Datenbank enthalten können hier komplex sein. Bisher bin ich nur bei Nextcloud auf Probleme gestoßen: bei einer Anwendung mit Webserver und Datenbank für die Datenbank den ":latest" Tag zu setzen ist z.B. keine gute Idee. Hier hat mir ein automatisches Major DB Update (MySQL) eine Installation zerschossen. Das war aber auch schon die einzige Anwendung, die hier bislang Probleme bereitet hat. Mit einem Pin der DB auf eine Version mit dem Tag ":X.X.X" (z.B. "mysql:8.0.29") passiert aber auch hier nichts unvorhergesehenes.

Ansonsten verwende ich https://github.com/containrrr/watchtower als automatischen Updater. Mit der Doku kann man hier auch gemischte Setups fahren und manche Container automatisch updaten und andere nicht.

Also wahrscheinlich unter Beachtung der Upgrade-Richtlinien der jeweiligen Container.(Bei Nextcloud darf man z. B. nur eine Major-Version überspringen, sonst klappt das Upgrade nicht).

True, siehe oben. NC ist hier sicherlich etwas kapriziös. Die meisten anderen Anwendungen haben hier aber keine Probleme. Im Prinzip macht man mit automatischen Container Updates jede Version sehr zeitnah (innerhalb weniger Stunden) mit.

Wenn es für die verwendete Applikation ein offizielles Docker Image gibt, optimal. Wenn man die Applikation auch über eine Paketverwaltung updaten würde, kann man sie imho auch über den Container aus der gleichen Quelle updaten. Wenn es dafür nur 3rd party Container gibt, muss man ggfalls diesen Maintainern vertrauen. Auf der anderen Seite kann man jederzeit in die Dockerfiles reinschauen und sich das "Kochrezept" ansehen. Quasi jeder Container startet mit FROM von einem allgemeinen Basisimage und fügt dann Anweisungen hinzu. Die kann man jederzeit nachverfolgen und somit sicherstellen, dass nichts ungutes passiert.

Ein weiterer Punkt: falls man ein Update schief geht, kann man schlicht per Tag die vorhergehende Version wieder pullen. Im Prinzip gibts also einen Zurückspulenknopf.

Und: wenn man die docker-compose Files extern lagert (z.B. auf einem privatem Github Repo), hat man schon mal sein Gerippe safe. Wenn man dann noch die Daten auf den Massenspeichern sichert, hat man ein Backup, das jederzeit auf anderen Hosts lauffähig ist. Ein Umzug auf einen anderen Host ist so kein Problem.

Im Prinzip investiert man anfangs mehr Zeit dafür, die Umgebung und das "Kochrezept" der Anwendung zu konfigurieren und wird dafür mit einer jederzeit lauffähigen Version belohnt, die sich einfach updaten lässt. Bei Standardanwendungen ist es super easy, aber auch eigene, selbst programmierte Anwendungen kann man mit einem eigenen Dockerfile lauffähig machen.

Für mich war das auch neu und ich dachte mir auch: "umständlich". Aber wenn man sich mal drauf einlässt, gibts so viele Vorteile. Das Prinzip "läuft es einmal, läuft es überall" ist einfach nice.

 

[Thunderbyte]

Hinzu kommt die Vertrauenswürigkeit der öffentlich verfügbaren Docker Registries. Denn Signaturen sucht man da vergebens. Docker baut nur Prüfsummen über die Layer um zu erkennen, ob die Layer noch passen. Aber GPG Signaturen wie man sie von DEB/RPM Paketen kennt, fehlen.
Ein Paketmanagement kann daher durchaus die sichere Kette zur Softwarepflege sein.

Im Prinzip bauen alle Container ja auch nur auf Paketmanagern auf und nutzen dessen Signaturen und man kann sich das Kochrezept, meist basierend auf einem allgemeinen OS Container selbst ansehen. Von daher baut ein Container auch nur auf ein Basisimage mit Paketen aus dem Paketmanagement auf.

 

[Firewire2002]

Ein weiterer Punkt: falls man ein Update schief geht, kann man schlicht per Tag die vorhergehende Version wieder pullen. Im Prinzip gibts also einen Zurückspulenknopf.

Das ist allerdings auch wieder sehr von der Anwendung abhängig. Viele Tools haben eben genau wegen dieser Upgrade-Konzepte auch Automatismen beim Anwendungsstart, die die Version des DB Schemas prüfen und ggfls. Änderungen einspielen. Dann ist ein Rollback halt nicht mehr nur einfach mal den Container mit dem alten Image starten, sondern auch noch DB Schema zurückrollen oder schlimmsten falls sogar DB von einem Backup restoren, was dann mit entsprechendem Datenverlust verbunden ist, wenn sich die Container nachts selbst updaten.
Selbst Point-In-Time Recoverys machen dann einen großen Aufwand, weil man potentielle Datenänderungen nach der Schemaänderung manuell rauskratzen und auf das alte Schema neu anwenden darf.

Container Images bestehen nun mal auch nur bis zu einem gewissen Punkt aus reinem Paketmanagement. Der Anwendungsspezifische Teil ist in den allermeisten Dockerfiles ein COPY oder ADD, aber kein RUN apt-get install (oder yum, oder pkg, oder was auch immer ...).

Ich halte Containerisierung in vielen Fällen auch für eine gute Idee, aber eben nicht in allen. Sie kann viele Prozesse und Deployments deutlich vereinfachen. Die eingesparte Zeit legt man aber zwangsläufig an anderer Stelle für die dafür notwendige Infrastruktur drum herum wieder drauf. Ob es am Ende tatsächlich einen Mehrwert bietet, muss man im Einzelfall mit den jeweiligen Rahmenbedingungen betrachten.

Allerdings halte ich es für gefährlich, den Leuten einfach stumpf ins Hirn zu prügeln, dass Container alles besser könnten.

 

[Thunderbyte]

Allerdings halte ich es für gefährlich, den Leuten einfach stumpf ins Hirn zu prügeln, dass Container alles besser könnten.

Da hast Du Recht und das möchte ich auch nicht. Viele haben aber noch nie mit Containern gearbeitet und die Vorzüge (neben den Nachteilen) noch gar nicht kennen gelernt. Insofern kann man nur jedem empfehlen, sich damit zu beschäftigen und dann für die eigene Workload die richtige Wahl zu treffen.
Themen wie Clustering (z.B. Docker Swarm, Kubernetes), und diverse praktische Sachen wie Overlay Networks über Hosts hinweg u.v.m. haben wir ja noch gar nicht erwähnt.

 

[Joe User]

Alles was mit Containern geht, geht auch Bare-Metal (mit erheblich weniger Fehlerquellen und Sicherheitsdefiziten)...

Welchen Aufwand müsst Ihr bitte betreiben, um eine simple Lib wie zlib überall zu aktualisieren? Wisst Ihr überhaupt welche Eurer Container die zlib verwenden beziehungsweise mitschleppen? Vermutlich nicht...
Auf einem Bare-Metal kostet mich das selbst bei einem Rolling-Release wie FreeBSD/Gentoo/etc. inklusive (Re-)Kompilieren der zlib unter eine Minute plus dem obligatorischen Reboot beziehungsweise dem Restart der betroffenen Prozesse, also insgesamt aufgerundet maximal drei Minuten.

 

[Firewire2002]

Natürlich kann man alles was Containerisierung kann, auch ohne Containerisierung abbilden. Mit Kubernetes werden aber viele Funktionen für die breite Masse nutzbarer.
Dein Kenntnisstand in allen Ehren, aber dein Wissen und deine Fähigkeiten sind (leider) nicht repräsentativ für die große Masse von Software Entwicklern und Admins.

An der Stelle muss man etwas zwischen den verschiedenen Update-Konzepten differenzieren.
OS wie BSD oder Gentoo mögen da nochmal eine andere Sichtweise bieten, als Distributionen die auf reines Binär-Paketmanagement setzen. Zugegeben ich habe primär mit letzterem zu tun (RedHat-Derivate, Debian/Ubuntu-Derivate) und kann den Vergleich zu BSD/Gentoo nicht vollständig ziehen.

Wenn ich aber mehrere hundert oder tausend Systeme mit den unterschiedlichsten Debian/RedHat-Derivaten und Versionen habe, renne ich nicht mehr jedem Paket einzeln nach. Da kann ich im Minutentakt patchen, weil irgendeine Distribution für irgendwas einen Patch released hat. Was passiert also in der Realität? Patches werden gesammelt und gebündelt eingespielt oder alternativ, wenn es das jeweilige System in seiner Nutzung zulässt, vollautomatisch installiert.
Gibt es ein kritisches Update, was nicht Zeit X bis zum gesammelten Rollout warten kann, wird das halt gezielt auf die Systeme ausgerollt oder je nach Infrastruktur die bis zu diesem Zeitpunkt gesammelten Patches einfach früher als sonst üblich geplant ausgerollt.

Was machen die Leute nun mit Containern? Ganz einfach: mehr oder weniger das gleiche. Nur auf anderem Level.
Wer ernsthaft Containerisierung betreibt, betreibt zwangsläufig auch Infrastruktur welche regelmäßig automatisiert die Images aktualisiert und die Container ersetzt. Dank Automatismen in Kubernetes muss man sich als Admin noch nicht mal großartig um das Rolling-Update kümmern. Die Container werden der Reihe nach ersetzt, schlagen die Healthchecks nach dem Container-Start fehl, wird das Upgrade unterbrochen. Erst wenn die Healtchchecks positiv verlaufen, wird der alte Container gekillt.
Zugegeben die Logik kann nicht mit absolut jeder Anwendung im Container perfekt funktionieren. Wenn die Anwendung nicht mitspielt, macht sie das aber auch ohne Container nicht.
Da man aber immer das vollständige Image aktualisiert, interessiert es nicht, ob 3 von 7 Containern zlib drin haben oder nicht. Sie werden aktualisiert, fertig.
Wie Thunderbyte oben schon richtigerweise schrieb, kommen in den meisten Containern Distributionen mit Paketmanagement zum Einsatz. Entsprechend macht es bei den Updates keinen Unterschied, ob ich nun ein Bare-Metal Debian habe und ein "apt-get dist-upgrade" ausführe oder das gleiche beim Containerimage bau mache und danach den Container austausche.

Gibt es nun hier wieder einen konkreten Patch der nicht warten kann: Klickt man auf den Start-Button für eben genannten Automatismus (ob das nun ein Jenkins-Job oder irgendwas anderes ist, spielt keine Rolle) und guckt seinen Systemen beim Patchen zu.

Admins die Distris mit Paketmanagement einsetzen, beziehen üblicherweise auch die Updates vom Distributor. Gibt es keine Updates, werden auch keine installiert. Kaum einer wird da auf die Idee kommen, essentielle Software vom Paketmanagement selbst zu kompilieren. Insbesondere bei Libs für zlib oder openssl kannst das Paketmanagement danach wegschmeißen, wenn die Abhängigkeiten nicht mehr gegeben sind.
Ich weiß du bist kein Freund von Paketmanagementsystemen. Aber auch hier, deine Vorstellung wie IT-Systeme auszusehen haben ist nicht repräsentativ für die Masse der Systeme in der großen weiten Welt.

 

[Joe User]

Ich weiß du bist kein Freund von Paketmanagementsystemen.

Das ist nicht ganz korrekt:
Ich bin kein Freund von Binary-Distributionen, welche maximal mit CVEs versehene Patches auf ihre teilweise völlig veralteten Pakete, welche beim ursprünglichen Major-Release der Distri grösstenteils bereits veraltet waren und dann gefreezed wurden, setzen.
FreeBSD und Gentoo und Co. bieten ebenfalls Binary-Pakete und hervorragende Paketmanager, allerdings sind dort halt trotzdem die Pakete Rolling-Release, inklusive der Möglichkeiten Versionen individuell zu Pinnen oder bei Bedarf gar zu Downgraden.

Nur weil ich für meine Kisten minimalistische aka featureless aka bugless Pakete bevorzuge, welche sich halt nur durch wohldurchdachte Configure-/Compile-Optionen erzeugen lassen, heisst dass nicht, dass ich kein Freund von Paketmanagern bin.
Im Gegenteil, ich nutze selbst einen Paketmanager unter FreeBSD (Buildsystem->Deployment) und habe so gar mal Anfang der 2000er selbst einen in Bash(!) "programmiert", um für meine damalige eigene Distribution, welche auf HLFS (HardenedLinuxFromScratch), Gentoo, RedHat und SuSE basierte, nicht auf RPM oder dpkg zurückgreifen zu müssen.

Mir ist also bewusst, was Paketmanager können und wie nützlich sie sein können, wenn sie richtig[tm] eingesetzt werden...

 

[greystone]

Meine Frage zu der Aussage Der Updateaufwand ist bei Docker minimal und kann sogar noch automatisiert an Dich @Thunderbyte - oder falls mir das jemand anders beantworten mag - ist, ob das Deine Erfahrung des Normalzustandes ist: Alle möglichen Projekte - die Personen hinter der jeweilligen Software - stellen also jetzt jeweils in kurzen Zeitabständen aktualisierte Container bereit, die auch die programmatische Updatelogik enthalten, so dass man selbst jeweils nur noch den aktuell gepullten bzw. darauf basierenden Container neu bauen und starten muss?

Im Prinzip ja, würde ich sagen. Natürlich kann ich nicht für ALLE Softwarepakete sprechen.

Danke für diese Antwort. Das war mein Hauptanliegen in dem Thread. Wenn das tatsächlich sehr verbreitet ist, dann gehe ich in Zukunft vermehrt auf die Suche danach.

Hier hat mir ein automatisches Major DB Update (MySQL) eine Installation zerschossen. Das war aber auch schon die einzige Anwendung, die hier bislang Probleme bereitet hat. Mit einem Pin der DB auf eine Version mit dem Tag ":X.X.X" (z.B. "mysql:8.0.29") passiert aber auch hier nichts unvorhergesehenes.

Na da bekomme ich dann ja wohl überhaupt keine Sicherheitsupdates von mysql, wenn ich den Pin auf eine spezifische Versione setze? Vom groben hinschauen würde ich da eher das tag mysql:8.0 verwenden, womit ich zumindest noch minor Updates bekomme. (Natürlich pflegt wahrscheinlich nicht jedes Projekt solche Images mit Minor Updates).

 

[Thunderbyte]

Na da bekomme ich dann ja wohl überhaupt keine Sicherheitsupdates von mysql, wenn ich den Pin auf eine spezifische Versione setze? Vom groben hinschauen würde ich da eher das tag mysql:8.0 verwenden, womit ich zumindest noch minor Updates bekomme. (Natürlich pflegt wahrscheinlich nicht jedes Projekt solche Images mit Minor Updates).

Das Pinnen ist imho dahingehend relevant, dass es einem nicht "mal eben" ein Major Update einspielt, mit dem die Anwendung ein Problem hat. Insofern ja. Kann man so machen wie von Dir vorgeschlagen. Man muss das wohl von der Anwendung abhängig machen, welches DB Update es "verträgt". Major Updates kann man dann schon auch machen, aber halt nicht automatisch, sondern "begleitet" und mit Backup.

Ich finde Containerisierung hat bei sehr aufwändigen Anwendungen mit zahlreichen Bestandteilen / separaten Containern mit einem docker-compose File große Vorteile. Man braucht evtl einen Moment länger, um die Umgebung einmal einzurichten. Ist sie aber eingerichtet, hat man sein "Kochrezept" für immer. So kann man identische Installationen auch leicht vervielfachen oder mal eben eine Testumgebung betreiben, die man danach wieder einstampft.

habe so gar mal Anfang der 2000er selbst einen in Bash(!) "programmiert", um für meine damalige eigene Distribution, welche auf HLFS (HardenedLinuxFromScratch), Gentoo, RedHat und SuSE basierte, nicht auf RPM oder dpkg zurückgreifen zu müssen.

Diesen Kenntnisstand hat aber halt nicht jede(r). Und manche wollen in erster Linie die Anwendungen verwenden und nicht erst ne eigene Distribution dafür schreiben.

 

[Joe User]

Diesen Kenntnisstand hat aber halt nicht jede(r).

Richtig, aber diesen Kenntnisstand braucht man hierfür. Und gerade deshalb sollten Leute wie wir unsere Finger ganz tief in die Wunde (aka extremes Sicherheitsrisiko) legen und unbedarfte Hobbyadmins von diesem Container-Krams ganz weit fernhalten, da ihnen schlicht das nötige Wissen fehlt, um Container auch nur ansatzweise sicher betreiben zu können.

 

[Thunderbyte]

Richtig, aber diesen Kenntnisstand braucht man hierfür. Und gerade deshalb sollten Leute wie wir unsere Finger ganz tief in die Wunde (aka extremes Sicherheitsrisiko) legen und unbedarfte Hobbyadmins von diesem Container-Krams ganz weit fernhalten, da ihnen schlicht das nötige Wissen fehlt, um Container auch nur ansatzweise sicher betreiben zu können.

Das ist doch wieder eine typische Joe User "ich kanns nicht leiden, deswegen ist es Mist" Generalisierung, die im normalen Leben nicht weiterhilft.

Mir ist es lieber, wenn "Hobbyadmins" Anwendungen in Containern, die von Profis erstellt wurden, betreiben und Updates durch neue Containerversionen sehr zeitnah mitnehmen - ohne dass man sich durch tausend Schritte bei denen man Sachen falsch machen und Lücken aufreißen kann, kämpfen muss. Container können durch minimale Basisimages (z.B. Alpine) schon mal deutlich weniger Angriffsfläche bieten, das Docker Networking trägt auch zur Sicherheit bei (man legt nur unbedingt nötige Ports raus) und Reverse Proxies erledigen gleich noch sehr easy Let's Encrypt mit bzw. man lässt die Container ohnehin nur durch den Proxy raus.

 

[Joe User]

Das ist doch wieder eine typische Joe User "ich kanns nicht leiden, deswegen ist es Mist" Generalisierung, die im normalen Leben nicht weiterhilft.

Na dann...

Bin raus.