106 lines
4.6 KiB
Markdown
106 lines
4.6 KiB
Markdown
# Automatischer Unraid-Docker-Updateablauf
|
||
|
||
Stand: 24. August 2026
|
||
|
||
## Ziel
|
||
|
||
Ein ausdrücklich formulierter Auftrag wie „prüfe die Docker-Updates auf Unraid,
|
||
führe bestätigte Updates aus und kontrolliere das Ergebnis“ muss in Open WebUI
|
||
ohne manuelles Aktivieren von Werkzeugen vollständig ablaufen.
|
||
|
||
## Automatische Werkzeugwahl
|
||
|
||
Der `MikeAI Auto Tool Selector` unterscheidet zwischen Lesen und Ändern:
|
||
|
||
- reine Status- oder Updatefragen erhalten nur `mua-readonly-local`;
|
||
- eine in der aktuellen Nachricht ausdrücklich verlangte Unraid-Änderung erhält
|
||
`mua-readonly-local` und `mua` gemeinsam;
|
||
- Formulierungen wie „nur prüfen“ oder „keine Änderungen“ unterdrücken den
|
||
Verwaltungszugang;
|
||
- die bereitgestellten Verbindungen sind keine allgemeine Freigabe. Der Auftrag
|
||
muss die konkrete Änderung selbst enthalten.
|
||
|
||
Der vorgesehene Ablauf lautet immer:
|
||
|
||
1. Zustand und Kandidaten read-only erfassen.
|
||
2. Die engste gebündelte Änderung ausführen.
|
||
3. Das Ergebnis read-only oder durch die gebündelte technische Verifikation
|
||
kontrollieren.
|
||
|
||
## Verbindliches Batch-Werkzeug
|
||
|
||
MUA r019 stellt `unraid_docker_update_verified_batch` bereit. Das Werkzeug
|
||
akzeptiert 1 bis 25 exakte, mit `|` getrennte Containernamen.
|
||
|
||
Für jeden Container liest es zunächst Container-ID, Image-ID und Laufzustand.
|
||
Danach zieht es das im Unraid-Benutzertemplate konfigurierte Image und
|
||
vergleicht die unveränderliche lokale Image-ID. Bereits aktuelle Container
|
||
werden vollständig übersprungen – auch wenn Unraids Statuscache noch ein Update
|
||
meldet. Nur bei tatsächlich geänderter Image-ID wird neu erstellt. Laufend
|
||
bleibt laufend, gestoppt bleibt gestoppt.
|
||
|
||
Die kompakte Nachkontrolle enthält Container- und Image-ID-Änderung,
|
||
Endzustand, RestartCount und Healthcheck-Status. Templates, Ports, Volumes und
|
||
Netzwerke werden nicht verändert. Eine vorhandene Freigabe des bisherigen
|
||
Einzelwerkzeugs `unraid_docker_update` aktiviert nach dem Upgrade automatisch
|
||
auch die sicherere Batch-Variante.
|
||
|
||
## Idempotenz
|
||
|
||
Der Cache `/var/lib/docker/unraid-update-status.json` ist nur ein
|
||
Kandidatenhinweis. Er darf nie allein eine Neuerstellung auslösen. Autoritativ
|
||
ist der Image-ID-Vergleich nach dem Pull.
|
||
|
||
Die Unraid-Weboberfläche und mobile Ansichten lesen weiterhin diesen separaten
|
||
Cache. Ein technisch verifizierter Pull/Rebuild aktualisiert dessen Anzeige
|
||
nicht zwingend sofort. Deshalb kann dort weiterhin „Apply Update“ stehen,
|
||
obwohl der lokale Image-ID-Vergleich bereits `already-current` ergeben hat.
|
||
Für eine frische Anzeige muss Unraids eigener Statuslauf
|
||
`dynamix.docker.manager/scripts/dockerupdate check` abgeschlossen sein. Das ist
|
||
eine Aktualisierung der Anzeige und kein erneuter Container-Rebuild.
|
||
|
||
Auch nach diesem nativen Statuslauf kann Unraid einzelne Images weiterhin als
|
||
Update markieren, obwohl Container-Image-ID und lokale Tag-Image-ID identisch
|
||
sind. Das kommt insbesondere bei Registry-/Manifest- und Multiarch-Digest-
|
||
Vergleichen vor. In diesem Konfliktfall ist das Ergebnis von
|
||
`unraid_docker_update_verified_batch` nach dem Pull maßgeblich: identische
|
||
unveränderliche Image-IDs bedeuten `already-current`; ein weiterer Rebuild nur
|
||
zum Entfernen der GUI-Anzeige ist weder nötig noch erwünscht. Die GUI-Meldung
|
||
ist dann ausdrücklich als Fehlanzeige zu melden.
|
||
|
||
Ein wiederholter Lauf muss bei einem aktuellen Image folgendes melden:
|
||
|
||
```text
|
||
result: already-current
|
||
recreated: false
|
||
container_id_changed: false
|
||
image_id_changed: false
|
||
```
|
||
|
||
## Produktiver Regressionstest vom 24. August 2026
|
||
|
||
Ein neuer Open-WebUI-Chat erhielt ohne manuelle Werkzeugauswahl den Auftrag,
|
||
Unraid-Docker-Updates zu prüfen, bestätigt auszuführen und nachzukontrollieren.
|
||
|
||
- automatisch bereitgestellt: MUA read-only plus MUA-Verwaltung;
|
||
- zwei read-only-Aufrufe für Update-Status und Containerbestand;
|
||
- genau ein gebündelter Aufruf für fünf Kandidaten;
|
||
- alle fünf als `already-current` erkannt;
|
||
- null Neuerstellungen und null Container-/Image-ID-Änderungen;
|
||
- AirConnect blieb laufend; Virtual-DSM, AzuraCast, WindowsXP und Windows11
|
||
blieben gestoppt;
|
||
- `all_verified: true`.
|
||
|
||
Der vorherige Ablauf benötigte mehrere Benutzernachrichten und vier bis fünf
|
||
einzelne Update-Aufrufe. Dieser Pfad ist ersetzt.
|
||
|
||
## Recovery-Prüfung
|
||
|
||
1. MUA-Health muss r019 oder neuer melden.
|
||
2. Open WebUI muss den Auto Tool Selector 3.3.0 oder neuer enthalten.
|
||
3. „Gibt es Docker-Updates auf Unraid? Nur prüfen“ darf nur MUA read-only
|
||
bereitstellen.
|
||
4. Ein ausdrücklich schreibender synthetischer Auftrag muss beide MUA-Zugänge
|
||
bereitstellen und das Batch-Werkzeug wählen.
|
||
5. Ein Wiederholungstest mit aktuellem Image darf keine Neuerstellung auslösen.
|