Dockerode-Label für Container-Updates

Hallo,

Ich bin auf ein kleines Problem gestoßen, das meiner Meinung nach schnell gelöst werden kann. Wenn man Gladys auf einem bereits bestehenden System mit einem bereits aktiven Watchtower installiert, der die Container jedoch standardmäßig nur durch Label-Filterung aktualisiert (Container selection - Watchtower), werden die von Gladys erstellten Container in einem solchen System nicht aktualisiert.

Das gilt unter anderem für die Container Mosquitto und Zigbee2Mqtt.

Ich habe nicht herausgefunden, wie man ein Label über Dockerode hinzufügen kann, aber es wäre interessant, das Label « com.centurylinklabs.watchtower.enable=true » standardmäßig zu setzen.

Hallo @Albenss! :blush:

Kannst du uns ein bisschen mehr über deine Installation erzählen?

  • Wie startest du Gladys?
  • Warum verwendest du diese Label-Filter?
  • Warum verwendest du keine Ausschlussfilter, falls du „sensible“ Container hast, die du nicht aktualisieren möchtest, aber einen „Standard“-Filter, in dem du die Container ohne Tags aktualisierst?
  • Warum filterst du nicht nach Namen im Startbefehl von Watchtower?

Ich frage das, weil es ein spezifischer Fall ist. Ich weiß nicht, ob wir in Gladys so spezifische Variablen für deinen Fall einbauen wollen.

Ja, standardmäßig nutzt watchtower keine Labels. Das ist custom, aber ich stimme dir zu, es kostet nichts, wenn wir es hinzufügen.

Was die Installation betrifft, habe ich Gladys auf einem kleinen, benutzerdefinierten NAS (OMV, hauptsächlich für Docker verwendet) installiert.

Da ich Watchtower für das gesamte NAS verwende (etwa 50 verschiedene Container mit einigen Datenbanken), habe ich mich für das Update nur ausgewählter Container entschieden. Watchtower läuft also im Modus „Fully exclude“ und wenn ich möchte, dass sich ein Container wie Gladys aktualisiert, verwende ich das Label „com.centurylinklabs.watchtower.enable=true “.

Dadurch kann ich unter anderem Updates für kritische Container vermeiden und nur ausgewählte Container freigeben.

Tatsächlich, wie @VonOx sagt, ändert das Label das klassische Verhalten von Watchtower im normalen Modus (ohne Unterscheidung) nicht, aber bei etwas benutzerdefinierteren Konfigurationen wird es ermöglichen, Updates für von Gladys erstellte Container (hauptsächlich Zigbee2Mqtt bei mir) anzuwenden.

Ich habe es getestet: Wenn ein Benutzer Gladys auf einem Host mit bereits laufendem Watchtower im Modus Fully exclude ausprobiert, ist der einzige Weg, um zu aktualisieren, Z2M in Gladys zu deaktivieren, den Container zu löschen, ein Pull der neuen Version durchzuführen und dann Z2M in Gladys wieder zu aktivieren, damit es den Container neu erstellt. Das ist eine ziemliche Last.

Der Nutzen/Risiko-Vorteil meines Vorschlags ist positiv, er ermöglicht eine bessere Integration von Gladys in komplexere Umgebungen und ändert streng genommen nichts für die klassischen Benutzer.

Ok, ich verstehe besser, aber sind wir uns einig, dass du Watchtower startest?

Watchtower kann Argumente annehmen, und als Argument kannst du ihm die Liste der Container übergeben, die du aktualisieren möchtest. :blush:

Beispiel:

Warum startest du Watchtower nicht und gibst ihm die Liste der Container, die du aktualisieren möchtest?

Watchtower habe ich vor über einem Jahr gestartet und seitdem nicht mehr angerührt. Es läuft im Daemon-Modus und startet alle 24 Stunden. Die einzige Konfiguration, die sich ändert, ist direkt auf den Containern, auf denen ich das automatische Update über dieses berühmte Label aktivieren oder deaktivieren möchte.

Es ist zwar eine Workaround-Lösung, die du mir vorschlägst, einen neuen Watchtower mit einer Liste von Containern zu starten, aber das bedeutet, ein bereits bestehendes System zu umgehen.

Was ich mit meiner Lösung eines Labels in der Erstellungskonfiguration von Gladys vorschlage, ist, in der Standardkonfiguration oder in der restriktiven Konfiguration das automatische Update zu ermöglichen.

Genau das ist die Frage, ob es Sinn macht, die Anwendungen zu ändern, die du verwendest, anstatt deine Watchtower-Konfiguration zu ändern, da das, was du tust, doch recht spezifisch für deine Installation ist.

Wenn jemand zu uns kommt und genau das Gegenteil verlangt (Zigbee2mqtt nicht aktualisieren, um Instabilitäten zu vermeiden), sind wir ein bisschen blockiert…

Warum machst du nicht einfach:

docker stop watchtower && docker rm watchtower

Dann starte Watchtower mit deiner Konfiguration:

docker run -d \
  --name watchtower \
  --restart=always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower \
  --cleanup --include-restarting gladys gladys-z2m-mqtt gladys-z2m-zigbee2mqtt

Das ist ein guter Punkt, ich dachte nur, da Watchtower standardmäßig in der RPI-Image von Gladys aktiviert ist, sollten sich alle Container auf die gleiche Weise aktualisieren wie Gladys, und man sollte daher etwas weiter denken als die Standardkonfiguration von Watchtower.

Deshalb werde ich tatsächlich auf manuelle Aktualisierung umstellen, wenn es nötig ist.

Die Lösung könnte sein (wie ich glaube, schon irgendwo gelesen zu haben), dass man über das System-Tab die Kontrolle über die verschiedenen installierten Container hat.
Zum Beispiel:

Zigbee2mqtt | Status AN | Neustarten | Aktualisieren

So etwas in der Art, sodass jeder seine Updates nach Belieben durchführen kann.

@guim31 Das ist ein anderes Thema, die Updates sind ohnehin standardmäßig automatisch, niemand macht die Updates sonst :slight_smile:

Für eine gestartete Container-Verwaltungsfunktion, warum nicht, ich wäre bereit, dass du eine Feature-Anfrage im Forum erstellst, wenn das etwas ist, das du in Gladys sehen möchtest?