Docker container update tipp

1

Hi zusammen,

ich bin ja auch ziemlich unbedarft in der container-geschichte.
Ab und zu muss man wg. verschiedenster Sicherhietslücken (apt, mysql, php) auch mal die docker-container updaten - dachte ich.
Als ich es mit “collabora/code” tat, war das beim ersten Mal super - die Basis scheint jetzt ein 6.0 libreoffice zu sein. Gestern habe ich es nochmal versucht upzudaten und jetzt tat der Container nicht mehr was er sollte (irgendwie SSL-Fehler im log).

Jetzt geht es mir gar nicht ums debuggen oder die Frage, ob und wann man container updaten muss. Sondern darum, wie ich mit upgrades umgehe.

Ich habe für mich jetzt folgendes gemacht:
ich tagge die images, die ich verwenden will mit “:working”, also z.B.

docker tag 896b770bb440 collabora/code:working

und starte in meiner “docker-compose.xml” das “:working” image, dann sieht ein docker images bei mir so aus:

REPOSITORY                               TAG                 IMAGE ID            CREATED             SIZE
python                                   3-slim              0769b568426a        2 days ago          143MB
hgkvplan/linuxmuster-vplan               2.01                35fdb27ac414        2 days ago          303MB
hgkvplan/linuxmuster-vplan               latest              35fdb27ac414        2 days ago          303MB
collabora/code                           latest              2f454ff26962        3 days ago          1.56GB
jrcs/letsencrypt-nginx-proxy-companion   latest              c79a3bc1675a        4 days ago          85.8MB
nginx                                    stable              047429a05f4c        5 days ago          109MB
hgkvplan/linuxmuster-vplan               1.9                 fb69da404ec7        3 weeks ago         302MB
python                                   <none>              f9c1866f07ea        4 weeks ago         143MB
nginx                                    <none>              3f55d5bb33f3        4 weeks ago         109MB
jrcs/letsencrypt-nginx-proxy-companion   <none>              274e964f3005        4 weeks ago         85.5MB
collabora/code                           working             896b770bb440        5 weeks ago         1.56GB
portainer/portainer                      latest              a01958db7424        6 weeks ago         72.2MB
jwilder/nginx-proxy                      latest              1e3c23efda58        2 months ago        148MB

(zur erläuterung: alle ohne Tag (<none>) kann ich z.B. jetzt löschen.
Ähnlich kann ich auch alle, die ich jetzt verwende mit “:working” taggen, bisher hab ich das nur mit collabora gemacht. “python/3-slim” ist so basic, dass ich das nicht taggen werde, weil das wohl immer funktionieren sollte.")

Dann kann ich beim upgrade eines containers schauen, ob “:latest” noch funktioniert und falls nicht, bleibt das alte Image halt “:working”. Falls doch, bekommt das neue Image “:working”.

Habt ihr eine bessere Strategie?

VG, Tobias

2

Ein Problem mit dieser Strategie: “:working” ist kein Tag, den es upstream, d.h. auf dockerhub gibt, d.h. wenn ich im Verzeichnis “docker-compose pull” mache, werden natürlich dann keine neuesten Images mehr gezogen.

Aber das ist evtl. ein anderes Thema: “Wie bleibe ich bei den Images auf dem neuesten Stand, d.h. erfahre von updates und lade sie automatisiert runter?”

3

LXD :slight_smile:

4

Auch hier wärme ich mal das Thema auf:

docker mit watchtower up-to-date halten

ich habe jetzt (zunächst privat) mal watchtower (containerrr/watchtower) laufen lassen. Die Strategien sind hier:

  • „immer und sofort updaten, wenn es neue docker container gibt.“
  • benachrichtigt werden
  • die Zeiträume in denen gecheckt und upgedatet wird, flexibel einstellen können.

Vorbedingung

  • docker compose pull darf keine echten Fehler werfen. Das passiert dann, wenn man z.B. einen eigenen Dockercontainer erstellt hat und diesen nicht nach dockerhub oder ein anderes repository hochlädt.

Gerade letzterer Strategiepunkt funktioniert nicht so, wie ich es gerne hätte. Ich dokumentiere mal, wie ich es bisher mache:

scoping, um mehrere watchtower-instanzen laufen zu lassen:

scheduling, um watchtower nur zu bestimmten Zeitpunkten laufen zu lassen

docker-compose.yml watchtower-Anteil:

##
## Watchtower every week and restart
  watchtower-weekly:
    image: containrrr/watchtower
    container_name: watchtower-weekly
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      #WATCHTOWER_MONITOR_ONLY: 'true'
      #WATCHTOWER_POLL_INTERVAL: 604800       # one week
      WATCHTOWER_SCHEDULE: 0 20 20 ? * 0   # every Sunday, every month, at 20:20:00, regardless of the day of month
      WATCHTOWER_SCOPE: weekly_and_restart
      WATCHTOWER_NOTIFICATIONS: email
      WATCHTOWER_NOTIFICATION_EMAIL_FROM: watchtower@meinedomain.de
      WATCHTOWER_NOTIFICATION_EMAIL_TO: mich@meinedomain.de
      WATCHTOWER_NOTIFICATION_EMAIL_SERVER: mail.meinedomain.de
      WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT: 25

##
## Watchtower daily and restart
##
  watchtower:
    image: containrrr/watchtower
    container_name: watchtower
    restart: always
    <snip>
    environment:
      WATCHTOWER_SCOPE: daily_and_restart
      WATCHTOWER_SCHEDULE: 0 35 20 ? * * # every day, every month, at 20:35:00
    <snip>

docker-compose.yml Container-Anteil

Die Container, die ich überwachen lassen will, versehe ich hier mit einem label:

  office:
    image: collabora/code:latest
    <snip>
    labels: [ "com.centurylinklabs.watchtower.scope=daily_and_restart" ]

  peertube:
    image: chocobozzz/peertube:production-bookworm
    <snip>
    labels: [ "com.centurylinklabs.watchtower.scope=weekly_and_restart" ]
  peertube-db:
    image: postgres:13-alpine
    <snip>
    labels: [ "com.centurylinklabs.watchtower.scope=daily_and_restart" ]
  peertube-redis:
    image: redis:alpine
    <snip>
    labels: [ "com.centurylinklabs.watchtower.scope=daily_and_restart" ]
  peertube-postfix:
    image: mwader/postfix-relay
    <snip>
    labels: [ "com.centurylinklabs.watchtower.scope=daily_and_restart" ]

(eigentlich keine) Probleme

Wer bis hierher gelesen hat, fragt sich, warum ich das dokumentiere, wenn es doch Probleme geben soll… Die Probleme sind, dass ich nicht genau verstehe, wann sich die watchtower-Container gegenseitig killen oder nicht hochfahren.

  • Ich mache überhaupt erst verschiedene scopes und damit verschiedene watchtower-Instanzen auf, weil ich es unsäglich finde, dass in peertube die Hauptimages täglich aktualisiert werden und dann täglich 500-1000MB heruntergeladen werden. Gleichzeitige watchtower-Instanzen funktionieren nur mit „scopes“
  • Wenn ich das ignorieren würde, dann gibt es nur einen watchtower, dann würde es eben tägliche updates von peertube geben mit entsprechendem traffic und vielleicht ist dann das kill-Problem keins mehr.
  • Andererseits:es gibt z.B. mailcow. Die haben ihre eigene watchtower instanz. Es gibt vielleicht docker-basierte Software mit eigener watchtower-Instanz. Damit die nicht interferieren, muss man sie vielleicht zusammenfassen oder scopes festlegen.
  • Dazu kommt, dass beim manuellen Start der beiden watchtower-Instanzen beide starten, wenn aber ubuntu docker-ce updated oder es andere Gründe für einen restart gibt, dann laufen die Instanzen entweder beide oder nur einer nicht.

Fazit:

Ich finde die Situation für

  • auf öffentlichen Repo-Hubs veröffentlichte
  • und dort aktuell gehaltene Docker-Images
  • die bei updates keine Breaking-changes einführen (z.B. nextcloud:28 statt nextcloud:latest)

tragbar und eine ganz stressfreie Methode.

Wer docker images pflegt, der sollte sich einen workflow ausdenken, die images neu zu bauen, wenn es upstream neue Basisimages gibt.

Alternativen:

  • ich habe newreleases.io getestet und mir in etwa eingestellt, was ich an docker-images laufen habe. Ist aber nur manuell und eine Erinnerungshilfe.
  • ich habe ansible nicht getestet, sollte es da Rezepte geben, her damit.

VG, Tobias

EDIT:

  • mailcow hat gar keine watchtower-Instanz von containerrr, sondern ein watchdog…
  • ich hatte restart: always oder ähnliches vergessen, weswegen sich das fehlende Hochfahren von watchtower nach reboot/docker-daemon-reload erklärt.
1 „Gefällt mir“