Wie halte ich meine Container aktuell

  • Zwei Fragen zur Containerverwaltung:

    • Wie halte ich das in den Containern installiere OS aktuell? Ich habe z.B. das Postgress Dockerimage eingerichtet. Mit dem Image kommt ein kleines Linuxsystem. Was ist die beste Methode dies automatisch aktuell zu halten?
    • Angenommen eine neue Version eines installierten Containers wird veröffentlicht, was ist dann der beste Weg, meine vorhandenen Container zu aktualisieren?

    Ich weiß, wie ich all dies 'manuell' bewerkstelligen kann. Es geht mir hier um ein 'QNAP'-Lösung.

  • Eine sehr gute Frage, die mich auch schon eine Weile beschäftigt. Ich glaube eine QNAP spezifische Lösung gibt es nicht... die "großen", also Enterpriseanwendungen verwenden meines Wissens nach eine Orchestrierungssoftware wie docker-compose oder kubernetes unter anderem für solche Sachen. Dann gibt es noch Watchtower was vielleicht auch schon mal weiter helfen kann.Wie gut man jetzt diese Tools auf dem NAS betreiben kann, weiß ich bisher noch nicht (wenn ich mal Zeit habe werde ich mich aber damit mal auseinandersetzen).


    Wenn es bei dir wirklich nur um das eine Image geht, würde ich dir empfehlen einfach in dem Container die "unattended-updates" zu aktivieren. Das sollte mittlerweile bei jeder Distribution ohne weiteres möglich sein.

  • ...
    Wenn es bei dir wirklich nur um das eine Image geht, würde ich dir empfehlen einfach in dem Container die "unattended-updates" zu aktivieren. Das sollte mittlerweile bei jeder Distribution ohne weiteres möglich sein.

    Auch das ist nur bedingt möglich. Dies setzt voraus, dass eine Art Crondaemon im Container läuft, um regelmäßig Jobs auszuführen. Dies ist bei meinem Postgress-Container nicht der Fall! Dort läuft Postgress und sonst kein anderer Prozess. Theoretisch könnte man einen Container auch so weit abspecken, dass er keine Systemtools wie apt oder yum enthält.


    Das Watchtower das Du erwähnt hast gefällt mir gut. Ich denke ich werde die vorgefertigten Container durch meine eigenen ersetzen und die Images mit Watchtower aktuell halten. ist etwas mehr Aufwand aber auch ein guter Vorwand, mich mit Docker näher auseinander zu setzen.

  • Moin,


    ich würde das ganze etwas anders angehen. Im Prinzip würde ich ein Shell-Skript basteln, welches den entsprechenden Container anhält, einen Pull ausführt (also das Image updatet), den alten Container löscht und danach wieder anlegt. Falls man docker-compose verwendet, kann man sich einige Schritte sparen und es läuft auf ein Skript hinaus, welches die neueste Version des Images per Pull zieht und danach einfach docker-compose aufruft.


    Das Skript muss danach noch als cron-Job zu bestimmten Zeiten laufen und damit sollte das Updaten gegessen sein.


    Allerdings rate ich von einem solchen automatischen Update ab, da ich schon einige Fälle hatte, in denen die neueste Version des Images nicht mehr kompatible mit den alten Einstellungen war und damit nachher nicht mehr starten konnte. Daher bevorzuge ich persönlich das manuelle Update meiner Docker-Container.

  • Naja so wie ich das verstanden habe geht es nicht um das aktuell halten der im Docker laufenden Software, sondern auch um das dem Container zugrundeliegende Betriebssystem. Soweit ich weiß, muss es nicht immer bei einem neuen Image der Fall sein, dass auch die aktuellen Updates (apt update && apt upgrade) mit einfließen.
    Hauptfrage ist natürlich auch, ob das bei Containern zwingend nötig ist, oder ob durch das "Containerisieren" der potentielle Angriffsvektor schon genug abgeschwächt wird.

  • Guten Morgen :)


    Selbst in so einem Fall ist ein manuelles apt-get im Docker-Container nicht sinnvoll, da nach Updates, evtl. Restarts usw. immer wieder sämtliche Updates hinüber sind. Normalerweise basieren viele Images auf dem latest-Stand der betroffenen Betriebssysteme. Sollte ich mal einen erwischen, der doch nicht auf dem aktuellsten Stand ist, dann wäre der eher sinnvollere Weg, ein eigenes lokales Image auf Basis des "alten" Images zu erzeugen und beim Erzeugen über das Dockerfile und Docker die passenden Updates einzuspielen.


    Docker ist nicht ohne Grund in eine Anwendungs- und Datenschicht geteilt. Die Anwendungsschicht ist zwar im Laufenden Zustand änderbar, aber die Änderungen sind nicht persistent. Persistente Änderungen können nur auf Verzeichnisse durchgeführt werden, die als ein volume mit dem Host "verbunden" sind. Dort liegen dann sämtliche Änderungen und diese "überleben" auch Neustarts oder Updates.


    Ciao
    ariaci

  • Naja wenn man möchte, kann man auch die "nicht persistenten Daten" in ein neues Image speichern, nämlich in Form von docker commit. Weiterhin setzt dein Vorgehen voraus, dass man Zugriff auf das verwendete Dockerfile hat, was nicht immer der Fall ist. Zum Beispiel nutze ich das Docker Image von ecoDMS, wo das nicht der Fall ist...
    Ich glaube auch nicht, dass man sich bei Drittanbietern darauf verlassen kann, dass die jeweiligen Images immer auf dem letzten Stand sind, denn das setzt ja voraus, dass die Images fast täglich neu gebaut werden müssen.

  • Das eine Speicherung per docker commit möglich ist, mag sein. Es handelt sich jedoch dabei nicht um den empfohlenen Weg. Eine Benutzung des Befehls löst zwar augenscheinlich mein aktuelles Problem, kann jedoch in Zukunft zu weiteren Problemen führen. Weiterhin benötige ich zur Erstellung eines eigenen Images auf Basis eines anderen nicht das Original-Dockerfile. Meine selbst erzeugten Images basieren alle auf Images, die zwar auf gitlab das Dockerfile anbieten, jedoch habe ich diese noch nie benötigt.


    Dies zeigt auch schon ein Blick in die Dokumentation des Dockerfile (https://docs.docker.com/engine…uilder/#parser-directives). Die FROM-Direktive benötigt laut Dokumentation ein Name eines bestehenden Images. Beim Bauen eines eigenen Images über docker build kann man dies auch sehr gut sehen. Es werden alle benötigten Layer einzeln gedownloaded. Am Ende werden diese per Overlay-Technik zu einem virtuellen Dateisystem gebunden.


    Somit wird lediglich ein eigenes Dockerfile benötigt, was über die FROM-Direktive ein lokal vorhandenes Image als Basis verwendet und über weitere RUN-Direktiven dieses erweitert. Dieses Konzept habe ich selbst schon unter Linux- und Windows-Docker probiert.

  • Cool, das man einfach FROM benutzen kann war mir neu, danke für den Tipp, das erleichtert bei mir so einiges. Das die Variante mit dem commit nicht ideal ist war mir auch klar, aber manchmal kann man es für quick & dirty Lösungen verwenden.