{"id":8907,"date":"2022-06-16T15:09:23","date_gmt":"2022-06-16T13:09:23","guid":{"rendered":"https:\/\/u-labs.de\/portal\/?p=8907"},"modified":"2023-08-01T00:04:26","modified_gmt":"2023-07-31T22:04:26","slug":"docker-container-automatisch-mit-watchtower-aktualisieren-alles-was-du-zu-haendischen-manuellen-updates-von-docker-containern-images-wissen-solltest","status":"publish","type":"post","link":"https:\/\/u-labs.de\/portal\/docker-container-automatisch-mit-watchtower-aktualisieren-alles-was-du-zu-haendischen-manuellen-updates-von-docker-containern-images-wissen-solltest\/","title":{"rendered":"Docker Container automatisch mit Watchtower aktualisieren: Alles was du zu manuellen & automatischen Updates von Docker-Containern\/Images wissen solltest"},"content":{"rendered":"

Veraltete Softwarekomponenten finden sich auch 2021 unter den Top 10 der Einfallstore f\u00fcr Angriffe<\/a>. Wer Software betreibt, sollte sie regelm\u00e4\u00dfig auf den aktuellen Stand bringen. Vor allem f\u00fcr Anwendungen die im Internet erreichbar sind, ist das sehr wichtig, damit Sicherheitsl\u00fccken schnell geschlossen werden. Das gilt grunds\u00e4tzlich – unabh\u00e4ngig davon, ob man einen Raspberry Pi Zuhause oder einen Server in der Cloud verwendet. Doch gerade bei Docker gibt es keine automatischen Updates. Wie man Docker-Container aktualisiert und welche wichtigen Besonderheiten es dort zu beachten gibt, zeigt dieser Beitrag. Daf\u00fcr werfen wir einen Blick auf die Grundlagen der Semantischen Versionierung und wie sie uns vor allem f\u00fcr automatische Aktualisierungen helfen kann.<\/p>\n

Das Problem: Der Lebenszyklus von Docker<\/h2>\n

Wenn ihr einen Container zum ersten Mal startet und das Image nicht auf eurem Pi oder Server liegt, l\u00e4dt Docker das Image herunter. Aber: Docker pr\u00fcft danach nie wieder auf Aktualisierungen! Dies geschieht nur, wenn ihr h\u00e4ndisch einen Pull durchf\u00fchrt. Das im Container laufende Programm wird daher schnell veralten und kann ein Sicherheitsrisiko darstellen.<\/p>\n

Die Docker Images<\/h2>\n

Ein Image setzt sich aus der Registry zusammen, dem Name eines Image und dem Tag. Die Registry ist optional, standardm\u00e4\u00dfig wird vom Docker-Hub ausgegangen. Auch der Tag muss nicht zwingend angegeben werden. Der Standard lautet hier „latest“, diesen speziellen Tag schauen wir uns sp\u00e4ter noch ein. Ein einfaches Beispiel ist der Webserver Nginx, hier existiert ein gleichnamiges Image im Hub von Docker<\/a>.<\/p>\n

Was sind „Aliase“?<\/h2>\n

Alle verf\u00fcgbaren Tags werden im Reiter „Tags“<\/a> aufgelistet. \u00dcbersichtlicher ist aber meist die Liste in der Beschreibung, die von vielen Images angeboten wird. Hier sieht man sofort, dass es Aliase gibt – also verschiedene Tags f\u00fcr das gleiche Image, die in einer Zeile dargestellt werden. Im markierten Bereich k\u00f6nnen wir wahlweise stable<\/strong>, 1.20<\/strong> oder 1.20.2<\/strong> nutzen und erhalten das gleiche Image. Name des Image und Tag trennt man per Doppelpunkt, etwa nginx:1.20.2<\/strong> um Version 1.20.2 von Nginx zu erhalten.<\/p>\n

\n
\"\"<\/a><\/figure>\n<\/div>\n

Durch die Aliase kann man Aktualisierungen leichter einspielen: Entscheiden wir uns beispielsweise f\u00fcr den exakten Tag 1.20.2<\/strong>, m\u00fcssen wir bei einer neueren Version (z.B. 1.20.3<\/strong>) den Tag von Hand \u00e4ndern. 1.20.2 wird die neue Version nicht erhalten – denn ein gro\u00dfer Vorteil in der Entwicklung mit Docker ist ja die Reproduzierbarkeit: nginx:1.20.2<\/strong> soll sich \u00fcberall gleich Verhalten.<\/p>\n

Wie kann ich mir die semantische Versionierung zunutze machen?<\/h2>\n

Vor allem kleinere Aktualisierungen m\u00f6chte man in der Praxis aber oft gerne automatisch einspielen. Zumindest wenn man die Software nur nutzt, statt aktiv an ihr zu entwickeln. Hier bieten sich Tags an, die nur einen Teil der Version enthalten: 1.20<\/strong> wird beispielsweise automatisch alle Aktualisierungen der letzten Versionsnummer enthalten. Derzeit 1.20.2<\/strong>, zuk\u00fcnftig aber auch 1.20.3, 1.20.4<\/strong> und so weiter. <\/p>\n

Hier kann man sich die sogenannte semantische Versionierung<\/a> zunutze machen, vorausgesetzt die Software nutzt diese: Bei 1.20.2<\/strong> ist 1<\/strong> die Hauptversion, sie wird bei gr\u00f6\u00dferen \u00c4nderungen erh\u00f6ht, die evtl. nicht abw\u00e4rtskompatibel sind. Die Nebenversionsnummer .20<\/strong> steht f\u00fcr neue Funktionen, die bereits vorhandene nicht einschr\u00e4nken sollten. Dagegen ist die Revisionsnummer (.2<\/strong>) f\u00fcr korrigierte Fehler oder Sicherheitsaktualisierungen vorgesehen. Teils gibt es auch noch Buildnummern. Das ist eine fortlaufende Zahl, die bei jedem kompilieren erh\u00f6ht wird und meist mit Minus von der restlichen Version getrennt. Sie ist aber eher f\u00fcr Test- und Entwicklerversionen.<\/p>\n

Der Tag 1.20<\/strong> erh\u00e4lt also alle Fehlerkorrekturen. Weniger restriktiv k\u00f6nnte man auch den Tag 1<\/strong> nutzen, um zus\u00e4tzlich neue Funktionen zu erhalten. Dies w\u00fcrde ich aber nur mit Bedacht empfehlen. Zumal man nicht sicher gehen kann, dass jede Versionsangabe den semantischen Regeln folgt. <\/p>\n

Lebenszyklus: Wann und Wie wird ein Docker-Container aktualisiert?<\/h2>\n

Wichtig ist, den Lebenszyklus zu verstehen: Beim ersten Start eines Containers l\u00e4dt Docker das per Tag angegebene Image einmalig aus dem Internet. Danach findet keine <\/strong>automatische Aktualisierung statt! Wenn ihr etwa den Tag nginx:1.20<\/strong> nutzt, derzeit ist 1.20.2<\/strong> die aktuellste Version und morgen erscheint 1.20.3<\/strong>, werdet ihr die neue Version also nie erhalten. Hierf\u00fcr sind zwei Schritte n\u00f6tig:<\/p>\n

    \n
  1. Das jeweilige Image neu pullen<\/em>, dadurch wird die aktuellste Version aus der Docker Registry geladen – z.B. docker pull nginx:1.20<\/em><\/li>\n
  2. Den Container neu erstellen. Neu heruntergeladene Images werden auch nicht auf laufende Container angewendet! Neu erstellt werden kann ein Container z.B. mit docker compose up -d<\/em>.<\/li>\n<\/ol>\n

    Wie kann ich meine per Docker bereitgestellten Anwendungen automatisch aktualisieren?<\/h2>\n

    Beide Schritte m\u00fcssen allerdings h\u00e4ndisch ausgef\u00fchrt werden. Gerade um Sicherheitsl\u00fccken schnell zu schlie\u00dfen, m\u00f6chte man zumindest Fehlerkorrekturen m\u00f6glichst automatisiert einspielen. Man k\u00f6nnte daf\u00fcr einen entsprechenden Tag verwenden (im Beispiel etwa nginx:1.20<\/strong>), per Skript automatisch nach neuen Images pullen und den Container neu starten. Mit dem Projekt Watchtower gibt es jedoch bereits eine fertige L\u00f6sung, die genau das macht. Ein Watchtower-Container \u00fcberwacht eure laufenden Docker-Container, pr\u00fcft regelm\u00e4\u00dfig auf aktualisierte Image und startet in diesem Falle nicht nur den betroffenen Container neu. Er kann auch Abh\u00e4ngigkeiten ber\u00fccksichtigen, wenn z.B. der zu aktualisierende Nginx Webserver zu einer PHP-FPM Installation geh\u00f6rt. Oder Datenbanken f\u00fcr eine Anwendung im Spiel sind.<\/p>\n

    Dazu legt ihr in einem frei w\u00e4hlbaren Verzeichnis eine docker-compose.yml<\/strong> an:<\/p>\n

    services:\n  watchtower:\n    image: containrrr\/watchtower:1.4.0\n    container_name: watchtower\n    mem_limit: 128MB\n    restart: always\n    # Prueft alle 4h nach neuen Images\n    command: --interval 21600\n\n    volumes:\n      - \/var\/run\/docker.sock:\/var\/run\/docker.sock\n    environment:\n      - "TZ=Europe\/Berlin"<\/code><\/pre>\n
    Startet den Container mit docker compose up -d<\/strong> im Hintergrund. In den Logs seht ihr, wie Watchtower konfiguriert ist und wann die n\u00e4chste Pr\u00fcfung durchgef\u00fchrt wird:<\/p>\n
    watchtower  | time="2022-05-10T21:53:31+02:00" level=info msg="Watchtower 1.4.0"\nwatchtower  | time="2022-05-10T21:53:31+02:00" level=info msg="Using no notifications"\nwatchtower  | time="2022-05-10T21:53:31+02:00" level=info msg="Checking all containers (except explicitly disabled with label)"\nwatchtower  | time="2022-05-10T21:53:31+02:00" level=info msg="Scheduling first run: 2022-05-11 03:53:31 +0200 CEST"\nwatchtower  | time="2022-05-10T21:53:31+02:00" level=info msg="Note that the first check will be performed in 5 hours, 59 minutes, 59 seconds"<\/code><\/pre>\n
    Wird ein neues Image erkannt, protokolliert Watchtower dies und startet die betroffenen Container entsprechend neu:<\/p>\n
    time="2022-02-25T21:36:27+01:00" level=info msg="Found new mariadb:latest image (539871f8c20e)"<\/code><\/pre>\n
    Damit habt ihr f\u00fcr viele F\u00e4lle eine L\u00f6sung, die sich automatisch um kleinere Aktualisierungen k\u00fcmmert. Was ihr allerdings regelm\u00e4\u00dfig per Hand pr\u00fcfen solltet, sind Updates der Nebenversion oder – je nach Tag – zumindest die Hauptversion. <\/p>\n
    Sonderfall #1: „latest“ Tag<\/h2>\n
    Wenn man keinen Tag angibt (z.B. nur nginx <\/strong>statt nginx:1.20<\/strong>), setzt Docker standardm\u00e4\u00dfig „latest“. Dieser Tag steht oft f\u00fcr die aktuellste, stabile Version. Allerdings nur per Konvention – man kann daher nicht davon ausgehen, dass er f\u00fcr alle Images existiert! Generell w\u00fcrde ich den „latest“ Tag meiden: Da er keinerlei R\u00fccksicht auf m\u00f6gliche Inkompatibilit\u00e4ten nimmt, kann es zu Problemen kommen. Das gilt ebenfalls f\u00fcr Tags, die zwar anders hei\u00dfen, aber einen \u00e4hnlichen Zweck erf\u00fcllen – etwa „stable“ im Falle von Nginx. <\/p>\n
    Schlussendlich k\u00f6nnen solche Tags auch einen der Vorteile von Docker zunichte machen, n\u00e4mlich die Konsistenz und Reproduzierbarkeit. Daf\u00fcr w\u00e4re eine exakte Version am besten geeignet. Mit Tags wie latest<\/em> steigt die Wahrscheinlichkeit mit zunehmendem Alter, dass sich ein so erzeugter Container auf einem anderen System auch anders verh\u00e4lt.<\/p>\n
    Ich w\u00fcrde mindestens eine Hauptversion als Tag angeben, sofern m\u00f6glich. Besser sind Haupt- und Nebenversion. Wobei dies nur eine Faustformel ist. Man sollte sich die Art der Versionierung des jeweiligen Programms anschauen und sich entsprechend entscheiden. Manche Projekte halten sich nicht an die semantische Versionierung, sodass z.B. auch Nebenversionen m\u00f6glicherweise inkompatibel mit vorherigen Versionen sind.<\/p>\n
    In seltenen F\u00e4llen wird leider gar keine oder nur eine sehr rudiment\u00e4re Auswahl an Tags angeboten. In diesem Falle kann man Watchtower anweisen, nur auf neue Images zu pr\u00fcfen, ohne automatische Aktualisierungen durchzuf\u00fchren:<\/p>\n
    com.centurylinklabs.watchtower.monitor-only=true<\/code><\/pre>\n
    Damit man von den Aktualisierungen erf\u00e4hrt, m\u00fcssen Benachrichtigungen eingerichtet werden<\/a>. Ansonsten bleibt nur das unbequemere regelm\u00e4\u00dfige Pr\u00fcfen bzw. Filtern der Protokolle. Hier sollte aber klar sein, dass diese Variante weniger Wartungsfreundlich ist – und man regelm\u00e4\u00dfig von Hand auf Aktualisierungen pr\u00fcfen sollte, damit die Software nicht veraltet.<\/p>\n
    Sonderfall #2: Selbst gebaute Images<\/h2>\n
    Der per Watchtower gezeigte Weg funktioniert nur, wenn der Container direkt mit einem Image aus dem Docker-Hub gestartet wird. Selbst gebaute Images per Dockerfile finden keine Ber\u00fccksichtigung. Hierf\u00fcr m\u00fcsste das Basis-Image gepullt und das selbst erstellte Image neu gebaut werden. Die Vernk\u00fcpfung zum Dockerfile fehlt Watchtower, weswegen er das selbst gebaute Image f\u00e4lschlicherweise im Docker-Hub sucht und dort nat\u00fcrlich nicht findet:<\/p>\n
    time="2022-05-10T03:39:59+02:00" level=warning msg="Reason: registry responded to head request with \\"401 Unauthorized\\", auth: \\"Bearer realm=\\\\\\"https:\/\/auth.docker.io\/token\\\\\\",service=\\\\\\"registry.docker.io\\\\\\",scope=\\\\\\"repository:library\/u-img_u-img_php:pull\\\\\\",error=\\\\\\"insufficient_scope\\\\\\"\\"" container=\/u-img_php image="u-img_u-img_php:latest"<\/code><\/pre>\n
    Hier muss man die regelm\u00e4\u00dfige Neu-Erstellung des eigenen Images automatisieren. Im technisch besten Falle kommt eine CI\/CD Pipeline zum Einsatz, die z.B. als n\u00e4chtliche Aufgabe (Nightly Build) automatisch das Image neu baut. Einsteiger k\u00f6nnen sich aber auch mit zwei Zeilen in einem Skript behelfen (jeweils im Verzeichnis ausgef\u00fchrt, in dem das Dockerfile liegt):<\/p>\n
    docker pull $(egrep ^FROM Dockerfile | awk '{print $2}')\ndocker compose up -d<\/code><\/pre>\n
    Der erste Befehl lie\u00dft Image + Tag aus dem Dockerfile aus und pullt das Image. Falls es hier Neuerungen gibt, erscheint Downloaded newer image for xx<\/em> in der Ausgabe, ansonsten Image is up to date for xx<\/em>. Docker Compose ist mittlerweile so intelligent, dass up<\/em> nur Container neu startet, bei denen sich etwas in der Konfiguration – wie unter anderem das Image – ge\u00e4ndert hat. <\/p>\n
    Zus\u00e4tzlich w\u00fcrde ich Watchtower \u00fcber folgendes Label f\u00fcr einen Container der selbst gebaute Images nutzt komplett deaktivieren. Funktionell ist das zwar nicht n\u00f6tig. Aber es vermeidet die oben gezeigten „falsche Fehler“, wenn Watchtower vergeblich versucht, das Image in der Docker-Registry zu finden:<\/p>\n
    com.centurylinklabs.watchtower.enable=false<\/code><\/pre>\n
    Au\u00dferdem hat Docker vor einiger Zeit Limitierungen f\u00fcr Nutzer eingef\u00fchrt, die kein kostenpflichtiges Abo besitzen. Vor allem mit einer gr\u00f6\u00dferen Anzahl an Container sollte es daher auch im eigenen Sinne sein, unn\u00f6tige Anfragen m\u00f6glichst zu vermeiden.<\/p>\n
    Hinweis: Beachtet bei einer automatischen Ausf\u00fchrung per Cron, dass dort i.d.R. kein vollst\u00e4ndiger $PATH zur Verf\u00fcgung steht! Pr\u00fcft daher mit which docker<\/strong>, wo eure Binary liegt (meist \/usr\/bin\/docker) und gebt den vollst\u00e4ndigen Pfad im Skript an, etwa so:<\/p>\n
    \/usr\/bin\/docker compose up -d<\/code><\/pre>\n
    Letzte aktualisierte Container anzeigen (MOTD beim Login)<\/h2>\n
    Je nachdem welche und wie viele Container man nutzt, f\u00fchrt Watchtower in einigen Tagen bis Wochen die ersten Aktualisierungen durch. In den Protokollen des Containers wird dies mit Found new XYZ image<\/em> vermerkt:<\/p>\n
    docker logs watchtower --tail all 2>&1 | grep "Found new"<\/code><\/pre>\n
    Praktisch finde ich, wenn man beim Einloggen auf dem Server die zuletzt aktualisierten Images aufgelistet bekommt. Das kann mit der Message of the Day<\/em> umgesetzt werden: Sie f\u00fchrt bestimmte Shellskripte nach der Anmeldung aus und zeigt deren Ausgabe an. Sie liegen unter Ubuntu im Ordner \/etc\/update-motd.d<\/strong> und werden nach dem Name sortiert ausgef\u00fchrt. Daher gibt es ein zweistelliges Pr\u00e4fix, um die Reihenfolge unabh\u00e4ngig vom alphabetischen Name definieren zu k\u00f6nnen. Im Beispiel lege ich 30-docker-container-updates<\/strong> an:<\/p>\n
    sudo vim \/etc\/update-motd.d\/30-docker-container-updates<\/code><\/pre>\n
    Hierbei handelt es sich um ein normales Shell-Skript, in diesem Fall Bash. Es filtert wie oben gezeigt die neu heruntergeladenen Images und entfernt unn\u00f6tige Inhalte, sodass uns nur Zeitstempel und Image angezeigt werden:<\/p>\n
    #!\/bin\/bash\nprintf "Letzte Container-Updates\\n"\ndocker logs watchtower --tail all 2>&1 | grep "Found new" |\n        gawk 'match($0, \/time="([^"]+)" level=info msg="Found new (.*) image \\((.*)\\)\/, a) {print "[" a[1] "] " Image a[2] " (" a[3] ")"}' |\n        tail -10\nprintf "\\n"<\/code><\/pre>\n
    Skript ausf\u00fchrbar machen:<\/p>\n
    \/etc\/update-motd.d\/30-docker-container-updates<\/code><\/pre>\n
    Ergebnis bei der n\u00e4chsten Anmeldung:<\/p>\n
    Letzte Container-Updates\n[2022-05-18T03:53:37+02:00] nginx:1.21-alpine (b1c3acb28882)\n[2022-05-24T01:08:10+02:00] mariadb:10.7 (fb8f6c175bee)\n[2022-05-25T00:13:47+02:00] traefik:v2.6 (22c6901de2be)\n[2022-06-07T06:18:10+02:00] mariadb:10.7 (7e5b7dee917c)<\/code><\/pre>\n
    Fazit<\/h2>\n
    Gerade weil Docker keinerlei automatische Aktualisierungen vorsieht, ist es um so wichtiger, dass man diese Prozesse kennt und entsprechend selbst f\u00fcr Aktualisierungen sorgt. Watchtower kann einem hier viel Arbeit abnehmen, in dem ein Gro\u00dfteil (oder sogar alle, je nach verwendeter Software) aller Images zusammen mit den dazugeh\u00f6rigen Containern automatisiert aktualisiert werden.<\/p>\n
    Wer vorsichtiger agieren m\u00f6chte, kann auch auf automatische Aktualisierungen verzichten und sich auf verschiedenen Wegen informieren lassen. <\/p>\n
    Man darf aber nicht vergessen: Watchtower ist ein Hilfsmittel. Es ersetzt nicht<\/strong>, dass ihr euch mit neuen Nebenversionen (oder zumindest Hauptversionen) sowie deren \u00c4nderungen auseinander setzt – und im Falle von nicht abw\u00e4rtskompatiblen Ver\u00e4nderungen eure Konfiguration entsprechend anpasst. Bei vielen Programmen ist das aber eher selten, sodass sich trotzdem viel Arbeit einsparen l\u00e4sst. Auf der anderen Seite werden Aktualisierungen schnell eingespielt, was sicherheitstechnisch definitiv sinnvoll ist.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Veraltete Softwarekomponenten finden sich auch 2021 unter den Top 10 der Einfallstore f\u00fcr Angriffe. Wer Software betreibt, sollte sie regelm\u00e4\u00dfig auf den aktuellen Stand bringen. Vor allem f\u00fcr Anwendungen die im Internet erreichbar sind, ist das sehr wichtig, damit Sicherheitsl\u00fccken schnell geschlossen werden. Das gilt grunds\u00e4tzlich – unabh\u00e4ngig davon, ob man einen Raspberry Pi Zuhause …<\/p>\n","protected":false},"author":5,"featured_media":9108,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[671],"tags":[912,497,387,870],"class_list":["post-8907","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-raspberry-pi","tag-container","tag-docker","tag-update","tag-updates"],"_links":{"self":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/8907","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/comments?post=8907"}],"version-history":[{"count":8,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/8907\/revisions"}],"predecessor-version":[{"id":10805,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/8907\/revisions\/10805"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media\/9108"}],"wp:attachment":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media?parent=8907"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/categories?post=8907"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/tags?post=8907"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}