Docker on Schallberts Blog

Docker-Images automatisch updaten

Schallbert — Sun, 01 Nov 2026

Wozu automatische Updates?

Software altert bzw. die Zeit streicht an ihr vorbei, sodass sie gewartet und auf Stand gehalten werden muss.

“Software ist kein Vermögenswert, sondern eine Verbindlichkeit.” - Cory Doctorow, Jan-2026

In meinem Blog habe ich schon mehrfach von Problemen wie kritischen Schwachstellen in Gitea oder in PHP berichtet, Systemabstürze beseitigt und unabsichtlich veröffentlichten Seiten wieder eingefangen, deren Ursachen allesamt durch Updates oder Rekonfiguration behoben werden konnten.

Das Betriebssystem meines Servers und die wichtigsten darauf laufenden Programme erhalten bereits automatische Updates wie in meinem server-auto-upgrade Artikel beschrieben.

Trotzdem bin ich mit dem Thema noch nicht ganz fertig.

Docker image update mit Watchtower

Um meine Docker-Images kümmerte sich bis Dato das Programm Watchtower. Es gibt jedoch mehrere Gründe gegen seinen Einsatz:

Es wird nicht mehr aktiv gewartet und befindet sich im Archivzustand. Allerdings gibt es Forks, die weitergeführt werden.
Um zu funktionieren, benötigt es Zugriff auf den Docker Daemon per docker.sock. Dies ist gleichbedeutend mit Root-Zugriff des Containers auf mein System. Das will ich in Zukunft unbedingt vermeiden.

1:1-Ersatz für Watchtower benötigt? Linuxhandbook hat hier ein paar Lösungen aufgelistet. Allen gemein ist allerdings, dass sie entweder nur über vorhandene Updates informieren und sie nicht ausrollen, oder dass sie selbst ebenfalls den docker.sock als Volume benötigen.

Lösung per Skript

Auf der Suche nach einem Weg ohne das Sicherheitsrisiko docker.sock komme ich schnell zur Idee, täglich ein Skript per cron ausführen zu lassen. Dies geschieht mit root-Rechten und kann daher direkt Docker-Befehle ausführen.

Kompliziert: `docker pull`, Abgleich mit vorhandenen Images, bei Bedarf einspielen

Mein erstes Skript hat 164loc (Zeilen) und tut folgendes:

Prüfen, ob benötigte Werkzeuge curl, docker, docker compose, docker-comppose.yml installiert sind und funktionieren
Die aktuellen image digests der in der docker-compose.yml definierten Services herausfinden
Die Registry für jeden Service per docker compose pull aktualisieren
Per docker image inspect die “neuen” mit den “alten” image digests vergleichen
Die neuen Images per docker compose up starten, Logs wegspeichern
Bericht per ntfy an mich, falls Updates erfolgt sind.

Doch dieser Weg ist viel zu kompliziert gedacht. Das von mir verwendete Werkzeug docker compose bringt die benötigte Option direkt mit: docker compose up --pull always.

Einfach: Alles in einem Kommando per Option mitgeben

Der Kern meines neuen Skriptes (61loc) sieht wie folgt aus:

compose=(docker compose --progress plain -f "$COMPOSE_FILE")

before=$("${compose[@]}" ps --all --quiet | sort)

if output=$("${compose[@]}" up -d --pull always --quiet-pull --wait \
 --wait-timeout "$WAIT_TIMEOUT" 2>&1); then
 status=0
else
 status=$?
fi

printf '[%s] docker compose up (exit %s)\n%s\n\n' \
 "$(date -Is)" "$status" "$output" >> "$CHANGELOG"

if (( status != 0 )); then
 report_failure "WARNING: Docker update failed" "warning" "$output"
 exit "$status"
fi

after=$("${compose[@]}" ps --all --quiet | sort)
if [[ "$before" != "$after" ]]; then
 notify "INFO: Docker containers updated" "white_check_mark" "$output"
fi

Im Skript erhebe ich einen Status vor dem Update, indem alle in der Compose-Datei spezifizierten Services aufliste und in einer Variable zwischenparke. Anschließend führe ich wie üblich docker compose up -d durch, allerdings nicht ohne die Flags --pull always sowie --wait wait-timeout <time[s]> zu setzen.

Mit der Pull-Option prüft Docker die Registry auf neue Images, welche gegebenenfalls heruntergeladen und gestartet werden. Der Timeout gibt dem Befehl eine bestimmte Zeit zur Ausführung bevor es mit einer Fehlermeldung abbricht, damit sich das Skript nicht aufhängen kann.

Was folgt ist nur noch Dokumentation und Monitoring: Die Ausgabe des Befehls wird in das Changelog geschrieben, im Falle eines Fehlschlags bekomme ich eine Information per Notify wie in meinem Server-Logging Post beschrieben. Hier wird der before-Status wichtig: Ich eine Benachrichtigung nur bei Fehler oder Update.

Anschließend muss ich das Skript nur noch ausführbar machen chmod + x docker-image-update.sh und an root übergeben: chown root root docker-image-update.sh.

Eintrag für cron

Nach einem manuellen Test des Skripts ./docker-image-update.sh, Prüfung seiner Ausgabe, des Changelogs und den neuen Containerversionen, lasse ich das Skript täglich durch den Cron-Daemon aufrufen:

schallbert@machine: crontab -e
[...]
0 2 * * * /path/to/docker-image-update.sh

Welche Version wurde installiert?

Statt mit Versionsbezeichnungen der Services arbeitet Docker mit Image digests. Dieser sha256-hash ist für jedes Image einzigartig, aber nicht besonders leserfreundlich:

sha256:94a00394bc5a8ef503fb59db0a7d0ae9e1110866e8aee8ba40cd864cea69ea1a # example Image digest

Doch Service-Versionsbezeichnungen wie Gitea v28.2.1 werden in den Image-Metadaten nicht standardmäßig unterstützt. Daher habe ich erstmal noch keine Lösung für die Ausgabe einer Version. Die Digests lasse ich in der Ausgabe weg.

Meldung bei Update

Die Meldung ist verbesserungsfähig: Ich benötige eigentlich nur die Namen der Container Updates und die Bestätigung, dass alle Images danach wieder “healthy” sind. Zusätzlich erhalte ich aber die Zustände der Container, aus denen ich die benötigten Informationen erst extrahieren muss. Der Mehrwert einer Filterung erscheint mir aber derzeit zu gering, als dass ich meine Zeit in die Erweiterung des Skriptes stecken würde. Schließlich zeigt mir Recreate bereits an, welcher Container auf Stand gebracht wurde.

Ich bin zufrieden. Ich konnte vom Host aus mit wenigen Zeilen Code, aus Bordmitteln, und nur mit cron als zusätzlicher Abhängigkeit mein Updateproblem für die per Docker Compose verwalteten Container lösen.

Continuous Deployment für Hugo

Schallbert — Tue, 15 Sep 2026

Gerade habe ich meine Website von Hugo auf Jekyll umgezogen. Nun will ich sie automatisiert bauen und Änderungen ausrollen, sobald ich einen Artikel fertiggestellt und ihn per git push und anschließendem Merge in main auf meine Gitea-Instanz geschoben habe.

Die Befehlskette

Ich habe einen VPS gemietet, auf dem ich alle Anwendungen in Docker laufen lasse. Die Aufgabe ist nun, einen workflow in Gitea zu bauen (“Actions”), welcher das Update im Repository auscheckt, es hugo zur Verfügung stellt, dort die HTML-Seiten erzeugen lässt, und sie anschließend so auf der Festplatte ablegt, dass mein Webserver die Dateien einlesen und ausliefern kann.

Erfahrungswerte

Das alles hatte ich für meine Website in Jekyll bauen und ausrollen können, daher kann ich auf ein paar Erfahrungswerte zurückgreifen.

Üblicherweise nutzt man dafür standardisierte Aktionen. Ich vereinfache mal stark und liste nur die Hauptdarsteller auf, ohne in fiese Details wie Rechtevergabe (darf Hugo in diesen Ordner schreiben? Hat der hugo-user genügend Rechte?) tiefer einzugehen:

checkout stellt einen gewünschten Stand des Quellrepository bereit
actions-hugo installiert hugo in der virtuellen Maschine der Action, sodass die Website gebaut werden kann
upload-artifact lädt die von hugo erstellte Seite auf den Webserver hoch

Da ich jedoch auf ein- und derselben Maschine in Docker unterwegs bin, kann ich mir das aufwendige Einwählen auf dem Webserver “von außen” sparen. Daher gehe ich einen anderen Weg.

Docker shared Volumes

Ich kann meiner Caddy-Anwendung direkt die gebauten Dateien zur Verfügung stellen, wenn ich das von ihr gelesene Volume bis in die Action weiterreiche.

Aufgepasst: Action volume != Hugo volume

Doch das funktioniert mit actions-hugo nicht: Sie ist selbst kein Docker container, kann also keine Volumes einbinden. Sie baut zwar die Webseite fertig; sobald die Aktion jedoch durchgelaufen ist, reißt sie die Artefakte mit ins Nirvana.

Ich benötige also eine hugo-Runtime, die selbst in einem Docker-Container läuft - ganz nach dem DinD-Ansatz. Diesem kann ich dann das von Caddy verwendete Volume mit Schreibzugriff durchreichen.

Der Workflow

Doch welchen Docker-Container soll ich nehmen?

Man stelle sich nun mehrere Stunden der Recherche und viele Fehlversuche beim Einrichten des Workflows auf meinem Server vor.

Folgendes ergab sich aus meinen Untersuchungen:

checkout@v4 benötigt node.js, und zwar mindestens Version node:18. Der Docker-Container (und das darunterliegende Betriebssystem des Runners!) müssen es installiert haben bzw. unterstützen.
Die Action benötigt git. Auch dies muss der Docker-container idealerweise bereits mitbringen.
Hugo braucht go. Klingt soweit logisch.

Runner-Betriebssystem anpassen

Mein Runner aus dem Jahr 2023 ist inzwischen in die Tage gekommen. Er basiert auf node:16-bullseye, eine Debian-basierte VM. Ich probiere etwas mit Alpine herum, doch diese Installation ist zu minimal für meine Zwecke und lässt mich mit vielen manuellen Anpassungen zurück. Schließlich muss der Runner noch andere Workflows ausführen als diesen hier. Ich entscheide mich letztendlich, bei Debian zu bleiben und nur die Node-Version hochzuziehen. Die Umsetzung in der Runner-Konfiguration sieht dann wie folgt aus:

# /gitea/runner/config.yml

 # The labels of a runner are used to determine which jobs the runner can run, and how to run them.
 # Like: ["macos-arm64:host", "ubuntu-latest:docker://node:16-bullseye", "ubuntu-22.04:docker://node:16-bullseye"]
 # If it's empty when registering, it will ask for inputting labels.
 # If it's empty when execute `deamon`, will use labels in `.runner` file.
 labels: [ubuntu-latest:docker://node:20-bullseye]

Anschließend muss der Runner-Container neu gestartet werden. Idealerweise bootet man Gitea gleich mit durch, dann funktioniert das Registrieren des Runners auch zuverlässig.

Das Workflow-Script schreiben

Um die oben beschriebenen Abhängigkeiten abzudecken entscheide ich mich für einen “batteries included”-Ansatz. So kann ich die Bausteine einfach ohne manuelle Anpassungen zusammenstecken und vertraue auf langfristige Wartung und Pflege der Container, da sie wirklich sehr häufig verwendet werden (Größenordnung mehrere Millionen Pulls). Diese Webseite half mir sehr bei der Auswahl.

Schließlich erstelle ich meinen Workflow basierend auf dem Container von Hugomods.

# /.gitea/workflows/build-deploy-with-hugo.yml

name: Deploy Hugo site
run-name: ${{ gitea.actor }} builds Hugo site
on:
 push:
 branches:
 - main

jobs:
 # Build job
 build:
 runs-on: ubuntu-latest # this is the "label" the runner will use and map to docker target OS
 container: 
 image: hugomods/hugo:latest
 volumes: 
 - /tmp/blog-artifacts:/tmp/blog-artifacts

 steps:
 - name: --- CHECKOUT ---
 uses: actions/checkout@v4
 with:
 submodules: recursive  # Fetches Hugo themes
 fetch-depth: 0

 - name: --- BUILD WITH HUGO --- # chown -R hugo /tmp/blog-artifacts
 run: |
 hugo \
 --minify \
 --cleanDestinationDir \
 --destination /tmp/blog-artifacts

Zielordner bereinigen

Ich habe mich im obigen Beispiel für ein “direktes Deployment” entschieden, ohne Netz und doppelten Boden, und ohne, dass ich die Artefakte herumkopiere oder gar den Server neu starte. Begründung: Der Hugo-Bauprozess benötigt für Meine Seite weniger als 2000ms. Nur in diesem Fenster kann Caddy theoretisch eine “korrupte” Datenbank sehen und ausliefern, also nur während die Platte vom Hugo-Build-Workflow noch beschrieben wird.

Um Inkonsistenzen trotzdem weitgehend zu vermeiden, gebe ich Hugo die Option --cleanDestinationDir mit. Damit ist das Zielverzeichnis stets sauber und Caddy wird im Zweifel keine defekte Seite anzeigen, sondern höchstens eine 404-Fehlermeldung erzeugen.

Submodules

Wie in meiner Projektdokumentation geschrieben, kann man in Hugo zum Laden von Themes sogenannte submodules verwenden. Diese werden in das Projekt eingeklickt und können, wenn korrekt verlinkt, dann auch im Workflow verwendet werden:

 with:
 submodules: recursive  # Fetches Hugo themes
 fetch-depth: 0

Ist alles richtig eingestellt, sollte es nicht zu folgender Fehlermeldung kommen:

# workflow action's error message due to incoherent submodules' commit references
# actions/checkout@v4:
Fetching submodules
/usr/bin/git submodule sync
/usr/bin/git -c protocol.version=2 submodule update --init --force
Submodule 'themes/terminal' (https://github.com/panr/hugo-theme-terminal.git) registered for path 'themes/terminal'
Cloning into '/workspace/schallbert/blog-hugo/themes/terminal'...
fatal: remote error: upload-pack: not our ref 719505fc89332baa69bffb90cee708ff124dd143
Fetched in submodule path 'themes/terminal', but it did not contain 719505fc89332baa69bffb90cee708ff124dd143. Direct fetching of that commit failed.
Error: The process '/usr/bin/git' failed with exit code 1
Error: Process completed with exit code 1.

Voraussetzung ist, dass man die Submodule auch lokal richtig geladen hat:

schallbert@machine:~ git submodule add -f https://github.com/<my/hugo-theme>.git themes/my-hugo-theme
schallbert@machine:~ git submodule update --init --recursive

Die Statusabfrage darf keinen leeren String zurückgeben, sondern muss einen Commit hash beinhalten. Beispiel:

schallbert@machine:~ git submodule status 
44d9a1890d228745ffc300b37a7d73e940ef9fa9 themes/terminal (v4.2.5)

Weiteres Zeugnis ist die .gitmodules-Datei, welche eine Referenz auf das Theme beinhalten muss:

schallbert@machine:➜/blog git:(main) ✗ nano .gitmodules
 [submodule "themes/terminal"]
 path = themes/terminal
 url = https://github.com/panr/hugo-theme-terminal.git

Funktioniert das nicht, so sind die Submodule nochmal komplett zu entfernen und antschließend wie oben beschrieben neu zu initialisieren:

git submodule deinit -f themes/<my-theme>
git rm -r --cached themes/<my-theme>
rm -rf .git/modules/themes/<my-theme>

Typische Probleme: Hugo-Versionen und Deprecations

Nun verlief die checkout-Aktion erfolgreich. Doch der Build mit Hugo schlägt fehl:

 error calling partial: "/workspace/schallbert/blog-hugo/layouts/_partials/head.html:37:40": execute of template failed: template: _partials/head.html:37:40: executing "_partials/head.html" at <$.Page.Language.Locale>: can't evaluate field Locale in type *langs.Language
Error: Process completed with exit code 1.

Lokal auf meiner Maschine baut Hugo erfolgreich, gibt aber ein paar Warnungen heraus:

Änderungen der Language-identifier und -Auswertung ab v0.158

schallbert@machine:➜/blog git:(main) ✗ hugo build --logLevel info 
WARN deprecated: site.Language.Locale was deprecated in Hugo v0.158.0 and will be removed in a future release. Use .Page.Language.Locale instead.
WARN deprecated: .Language.Lang was deprecated in Hugo v0.158.0 and will be removed in a future release.

Man könnte denken, dass sich diese Fehler leicht beheben ließen. Leider können sie sich prima verstecken:

in Submodules, die man als third-party-content lädt (z.B. in Themes). Eine projektweite Suche in der IDE hat Submodules üblicherweise ausgeblendet und liefert keine Treffer.
als Variablen im eigenen Code, die nur indirekt auf die alten Parameter zugreifen: Ich benutze bis dato .Page.Site.Home.AllTranslations, um herauszufinden, ob ich mich auf einer gegebenen Seite in der “Hauptsprache” aufhalte. Allein schon das Scoping ist widersinnig und wird meiner Meinung nach zu Recht entfernt. Das, was ich tun will, kann nun viel einfacher erreicht werden mit .Page.Language.IsDefault

Submodules auf Stand bringen

Bei den Submodulen sehe ich zwei Lösungsansätze:

Die Maintainer anschreiben (bzw. ein Issue aufmachen), dass ihr Code gerade veraltet und sie darum bitten, ihre Themes auf Stand zu bringen.
Die betroffenen Dateien aus dem Submodule herauskopieren und in die eigene Ordnerstruktur integrieren. So würde das in meinem Falle betroffene language-menu.html unter /layouts/partials/language-menu.html eine neue Heimat finden. Dort behebe ich dann die Probleme selbst.

Eigene Lösungen programmieren

Macht die Fehlermeldung keine Lösung offensichtlich, so kann man sich gut an der Hugo Community orientieren. Für die Deprecatoins in v0.158 gibt es beispielsweise eine ausführliche Dokumentation.

Versionen abgleichen

Hmm. Wie das Bild zeigt, verwendet mein Container das Paket hugo extended von hugomods, welches die Version v0.154.5 bereitstellt; ich hatte einen stabilen release für die Action ausgewählt. Vergleichen wir mal mit meiner lokalen Version, die inzwischen ohne auch nur eine Warnung brav baut:

➜ blog git:(main) ✗ hugo version
hugo v0.162.1+extended linux/amd64

Der Klassiker: Es gibt eine Änderung ab v0.158, die die interne API verändert. Ältere Versionen kennen die neuen Felder nicht und meckern. Neuere Versionen hingegen kreiden die Verwendung der alten Felder an.

Ich glaube, diese Probleme lassen sich nur dann zuverlässig vermeiden, wenn die Pipeline für lokal und remote identisch ist. Sprich: Auf dem Lokalen Rechner eine virtuelle Maschine mit dem CI-Betriebssystem booten und alles in Docker wegkapseln. Macht bestimmt Sinn, wenn man in einer größeren Organisation arbeitet und mehrere User vor diesem Problem stehen.

Stattdessen wechsle ich zur Behebung im Remote Container auf die Version image: hugomods/hugo:latest und behebe damit den Fehler. Jedoch habe ich noch immer unterschiedliche Versionen lokal und in der CD-Pipeline. Für mein Betriebssystem gibt es die neueste schlicht noch nicht und auch der Docker Release hängt zeitlich etwas hinter den Releases des Originals.

Die Bau- und Releasezeiten sind fantastisch, oder? Eine Änderung an der Website in 12 Sekunden online zu haben, inkl. Container hochziehen etc. - das gab es bei mir jedenfalls noch nie. Um die 20 Sekunden benötigt der Durchlauf, wenn er die Container refs erst neu holen und herunterladen muss, z.B. bei Updates der Registry von latest.

Einen detaillierten Benchmarkd zwischen Hugo und Jekyll bietet der verlinkte Artikel.

Giteas act_runner rootless: Startprobleme

Schallbert — Sat, 28 Mar 2026

Das Fehlerbild

Mein docker-in-docker (DinD) act_runner stürzt kurz nach dem Start mit folgender Fehlermeldung ab:

Issue-Ticket bei Gitea

In der Gitea-Community (issue #721) habe ich ein Ticket für das Problem angelegt. Im Folgenden gehe ich auf eigene Erkenntnisse ein und fasse die Diskussion etwas zusammen.

Problem mit Kernel-Berechtigungen?

Der act_runner muss bei der Docker-in-Docker Konfiguration selbst einen eigenen Docker Daemon betreiben. Nur so kann der Runner für die Actions eigene Container erstellen. Dies ist aus Sicherheitsgründen erst einmal nicht erlaubt.

Warum Container keine Container starten dürfen

Im Kontext des act_runner führt eine Action Code aus, der selbst Teil des Repository ist. Wird unbemerkt Schadcode in die Action eingeschleust, z.B. von einem “Collaborator”, so kann dieser bei einer Docker-Installation ohne DinD über den unter Umständen mit root-Rechten ausgestatteten Docker-Daemon dockerd direkt auf das Hostsystem durchgreifen.

Auswirkungen, falls trotz DinD etwas schief geht

Bei Anwendung des DinD-Konzeptes kann dies bei einem Angriff lediglich zum Zugriff auf den dockerd innerhalb des act_runner Containers führen - und das nur, wenn die Action nicht sauber gekapselt ist. Immer noch nicht gut, aber vertretbar: Bei Neustart des Containers ist der Status quo ante wiederhergestellt. Durchgriff auf das Hostsystem besteht allenfalls indirekt dadurch, dass der Container selbst mit sämtlichen Kernel-Features ausgestattet ist.

Einfache Lösung: DinD-Container `privileged` starten

Um dem DinD-Container jetzt die Möglichkeit zu geben eigene Actions aufzusetzen, kann in der Konfiguration privileged: true gesetzt werden. Damit werden dem Container alle Kernel-Fähigkeiten eingeräumt. Dies ist laut (dem hervorragend gemachten) OWASP Security Cheat Sheet möglichst zu vermeiden. Sollte act_runner nun selbst angegriffen werden oder kritische Sicherheitslücken offenbaren, hätte der Eindringling auf diese Weise bereits alle Möglichkeiten, der Kapselung vor dem Host-System zu entgehen.

Will man den einfachen Weg gehen, sieht die entsprechende docker-compose.yml wie folgt aus.

# docker-compose.yml
# section ACT_RUNNER
runner:
 image: gitea/act_runner:latest-dind-rootless
 container_name: gitea-runner
 privileged: true
# [...]

“And remember: Do not run containers with the –privileged flag!!!” - OWASP’s Docker Security Cheat Sheet, 2026 License

Sackgasse: Nur unbedingt benötigte Rechte vergeben

Nach kurzer Recherche finde ich einen Artikel auf CodeStudy.net¹, welcher sich mit dem Thema DinD beschäftigt. Hieraus bastele ich Änderungen in meiner docker-compose.yml zusammen.

Meine Vorgehensweise:

Änderungen in docker-compose.yml vornehmen
Service neu starten docker compose restart <service>
Logs anschauen docker logs --tail 100 <container-name>
Falls gestartet: Programm laufen lassen web-app->repo->jobs->rerun_all-jobs
Bei Fehlschlag: Wiederholen

Ich beginne mit wenigen, aber sehr mächtigen Rechten. Nach ein paar Iterationen erhalte ich:

# docker-compose.yml
# section act_runner DinD-rootless
runner:
 image: gitea/act_runner:latest-dind-rootless
 container_name: gitea-runner
 privileged: false
 cap_add:
 - SYS_ADMIN
 security_opt:
 - no-new-privileges:true
 - apparmor:unconfined 
 - systempaths=unconfined
 - writable-cgroups=true
# [...]

Aber noch immer fehlen mir Rechte, die außerhalb von Kernel-Privilegien und Sicherheitszonen liegen: Der Docker-Daemon möchte auf sysfs und proc, also Systemdateiverzeichnisse und -Prozesse zugreifen können.

level=warning msg="[rootlesskit:child ] failed to mount sysfs, falling back to read-only mount: operation not permitted"

Das kann ich selbst mit cap_add: ALL nicht ausgleichen. Zudem wird die Quellenlage im Internet auf dieser technischen Ebene echt dünn (und ich bin kein Docker-Spezialist). Ein Re-Mount der Dateisysteme könnte hier noch helfen; das erscheint mir aber zu experimentell und fehleranfällig.

Nach weiteren Stunden Recherche und Trial-and-Error auf meinem Server muss ich @tianon in einer Diskussion auf Github zustimmen: Der Docker Daemon benötigt so viele Rechte und Fähigkeiten, dass man gleich bei privileged: true bleiben kann und sich nicht mit einer Armada an CAP_ADD und System-bind-mounts herumschlagen muss.

Zukünftige Lösung: Virtualisierung oder Daemonless

Doch es gibt möglicherweise bessere Lösungen: Eigene Container-Laufzeitumgebungen wie Sysbox. Die Box hat selbst auf dem Hostsystem keine besonderen Rechte, ähnlich wie in einer virtuellen Maschine scheint sie in ihr laufenden Applikationen aber alle Rechte und Fähigkeiten zur Verfügung stellen zu können.

Installation und Inbetriebnahme bis hin zu funktionierenden Job-Containern führt für diesen Post zu weit. Daher muss ich vorerst auf andere Quellen verweisen.

Auch das Umschwenken von Docker auf Podman ist eine mögliche Lösung: Podman ist Daemonless, rootless und bietet ähnlichen Funktionsumfang wie Docker. Ein Umzug nach Podman wäre für mich ein eigenes Projekt und passt nicht in den Kontext dieses Posts.

Linux Security Modules (seccomp, AppArmor, SELinux)

Begriffsklärung: LSM ermöglichen verschiedene Sicherheitsprüfungen und -Sperren auf Kernelebene. Durch “Mandatory Access Control” können Sicherheitserweiterungen wie AppArmor Kernel-Fähigkeiten für einzelne Anwendungen steuern und Zugriffe falls nötig sperren.

Apparmor

Ich betreibe meinen Server (VPS) mit Ubuntu. Dieses Betriebssystem hat in den aktuelleren Versionen “user namespace creation restrictions” in AppArmor integriert, was das Betreiben von appimages, WebApps und eben auch Containers mit höheren Rechten verhindert.

“Unprivileged user namespaces are a feature in the Linux kernel […]; it enables unprivileged users to gain administrator (root) permissions within a confined environment […]” - mbelair, Ubuntu Discourse, as of May-2026, Ubuntu Discourse Website

Kurzgesagt wurde dieses Werkzeug als security-hardening-Maßnahme entwickelt, um Angriffsfläche auf dem Host-System bei Ausführung von Programmen zu reduzieren, die höhere Rechte erfordern.

Einfache Lösung: Komplett abstellen

Die Dampfhammermethode stellt das Feature für Benutzernamensräume komplett kalt. Wir teilen AppAmor mit, dass Drittprogramme wie in alten Betriebssystemversionen auch ohne Einschränkungen Kernel-Features oder höhere Rechte nutzen dürfen. Den zugehörigen Befehl habe ich aus dem askubuntu-Forum entliehen.

Er schaltet die Einschränkung von Nicht-Admin-Benutzernamensräumen (die Übertragung ins Deutsche tut schon fast weh) für diese Sitzung ab, indem er die Kernelparameter zur Laufzeit umschreibt (-w).

schallbertTestsThis@machine:~# sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

Ich halte den Befehl zur Fehlersuche für sehr hilfreich. Möchte man herausfinden, ob das gewünschte Programm wegen AppArmor nicht startet:

Obiges Kommando eingeben
das Drittprogramm, den Container etc. testen
durchbooten. Oder den Befehl mit =1 eingeben. Danach ist der Ursprungszustand wiederhergestellt.

Möchte man diese Verwundbarkeit permanent erhalten, so gibt man ein:

makeVulnerability@machine:~# echo 'kernel.apparmor_restrict_unprivileged_userns = 0' | sudo tee /etc/sysctl.d/20-apparmor-donotrestrict.conf
makeVulnerability@machine:~# sudo shutdown -r now

Dies alleine stellt noch keine Sicherheitslücke dar. Es ist jetzt nur prinzipiell einfacher geworden, eventuelle Schwächen im Kernel auszunutzen und der “Sandbox” des Containers zu entrinnen.

Richtige Lösung: Für jede Anwendung justieren

Es gibt Anwendungen (wie meine DinD-Version von act_runner), die benötigen zwingend erweiterte Rechte um ordnungsgemäß zu funktionieren. Und nur diese sollten die Möglichkeit erhalten, Nicht-Admin-Benutzernamensräume zu erhalten.

Docker selbst hat AppAmor einen Abschnitt in der Dokumentation gewidmet. Um zur Lösung für den DinD-Runner zu gelangen, benötigt es eine Transferleistung (danke, @thespad). Zur Wiederholung nochmal die Fehlermeldung von oben:

gitea-runner | [rootlesskit:parent] error: failed to start the child: fork/exec /proc/self/exe: operation not permitted
gitea-runner | s6-svwait: fatal: some services reported permanent failure or their supervisor died

Das Logfile sagt aus, dass der parent (Docker-Daemon im Container) sein child (Runner-Container) nicht starten kann, weil er für andere Teilnehmer (fork) selbst keine Prozesse (/proc/self) erstellen kann. Wer ist der User dieses Daemons? rootlesskit. Genau hier hakt unsere Lösung ein: Wir müssen in der docker-compose.yml das AppArmor-Profil für rootlesskit im DinD-Container des act_runner freigeben.

# docker-compose.yml
# section act_runner DinD-rootless
runner:
 image: gitea/act_runner:latest-dind-rootless
 container_name: gitea-runner
 privileged: true
 security_opt:
 - apparmor=rootlesskit
 # [...]

Entsprechend gut sieht jetzt auch das Logfile aus. Fertig!

Ich habe das Gefühl, dass jener Post mit “KI” geschrieben wurde. Wenn es konkret wird und es um “critical volume mounts” geht, stehen dort nämlich keine echten System-Pfade mehr und der Artikel wird insgesamt so vage, dass ich den Ratschlägen folgend gar nicht bis zum Ziel komme. ↩︎

Server-Konfiguration mit Git

Schallbert — Mon, 15 Jul 2024

Worum geht es?

Ich wünsche eine Versionskontrolle für die Konfiguration von Serverapplikationen
Diskussion technischer Lösungen zur Umsetzung
Tutorial: Docker/Gitea/andere “Secrets” von der Versionskontrolle ausnehmen
Tutorial: Deploy-Pipeline erstellen
Automationstrigger für nachgelagertes Ausrollen der Dateien auf dem Server programmieren
Nächster Artikel: Automation auf dem Server integrieren und Upgrades einspielen

Hintergrund

Ich habe auf meinem Server ja Watchtower laufen, um die Installierten Distributionen automatisch auf Stand und frisch gepatcht zu halten. Vor Kurzem hatte ich nun den Fall, dass sich mein Gitea Action Runner nicht mehr automatisch starten lassen wollte und auch bei manuellem Start eine Fehlermeldung ausgab.

Anscheinend hatte sich Docker ohne meine Aufsicht auf Stand gebracht und warf nun beim Hochfahren des Runner-Containers einen Volumefehler, die ich so vorher noch nicht gesehen hatte. Die Fehlermeldung war eindeutig und ließ sich mittels kleiner Änderungen in einer Konfigurationsdatei für Gitea leicht beheben. Dennoch hatte ich nun das Gefühl, dass eine Versionskontrolle für meine Konfiguration sinnvoll wäre, um Änderungen, Updates und ihre Beweggründe später besser nachvollziehen zu können.

Vorüberlegungen

Klingt nun für mich nach einem Zirkelbezug: Ich nehme die Konfigurationsdateien für meinen Server in Gitea auf, welches selbst auf meinem Server läuft. Das könnte beim Auto-Deploy noch spannend werden. Aber mehr dazu später.

Spontan fallen mir zwei Möglichkeiten ein, eine Versionskontrolle mit automatischer Synchronisation zu bekommen:

1. Hardlink

Diese Lösung würde die auf meinem Server in vielen Ordnern verstreuten Konfigurationdateien per Hardlink in einen zum Repository erklärten Ordner ablegen. Warum per Hardlink? Weil jeder Service auf meinem Server in sich gekapselt läuft und dafür jeweils eigene Konfigurationsdateien und Umgebungsvariablen gemeinsam mit dem Service abgelegt bekommt. Ohne Hardlinks müsste ich den gesamten Service-Ordner versionieren und meine .gitignore entsprechend komplex aufblasen.

Mit Git würde ich die per Hardlink abgebildeten Dateien versionieren und ihre Inhalte auf diese Weise auf Gitea verfügbar machen.

schallbert@server:/server-config-files –> hardlinks –> repository –> Gitea

Ich bekäme also eine nachgelagerte “Versionsbeobachtung” mit Sicherungskopie in dem Sinne, dass die Dateien nun mehrfach herumliegen.

2. Repo und auto-deploy auf den Server

In diesem Szenario halte ich die Konfigurationsdateien lokal auf meinem Laptop und kann sie wie üblich mit Git versionieren. Auf Gitea würde ich das Repository abbilden, und am Ende der Kette müsste mein Runner bei jeder Änderung der Konfiguration ein Auto-Deploy auf dem Server ausführen und die betroffenen Container anschließend neu starten.

schallbert@laptop:/server-config-files –> repository –> Gitea –> act-runner –> server:/<service1...ServiceN>/config-files

Ich bekäme in diesem Falle den Verwaltungs-“Main” auf meinen Laptop, und der Server würde der Abbildung auf Gitea folgen.

Probleme

In beiden Fällen habe ich noch keine Möglichkeit, geänderte Konfigurationen vorab zu testen. Alles, was ich tue geht direkt nach “Prod” und wäre live. Schlimmstenfalls kann ich mir so recht leicht mein Setup zerschießen.

Ändert nun den Status Quo ante nicht, bei dem ich die Dateien direkt auf dem Server verändere. Also ein neues Problem nur in der Hinsicht, dass ich beim Aufsetzen damals noch keinen Prod-Betrieb hatte und so kein Ausfallrisiko bestand.

Lösung Zwei scheint mir komplexer umzusetzen zu sein, denn ich benötige hierfür eine Deployment-Pipeline, welche die Dateien im Repository auf meinem Server ausrollt. Zumal sich der Runner in einem Docker-Container aufhält, während die Konfigurationsdateien direkt im Dateisystem des Servers befinden.

Ein direkter Durchgriff auf das Serverdateisystem ist zwar technisch möglich, würde aber meinem beschränkten Verständnis nach eine große Angriffsfläche für alle meine Dienste bedeuten, deren Konfigurationsdateien nun über das Repository in Gitea direkt manipulierbar würden.

Auswahl meiner Lösung

Lösung Zwei lagert mir das Sofort-Live-Problem zumindest auf meinen Laptop vor, sodass ich in einem ersten Schritt nicht direkt am Prod-System herumfuhrwerken muss. Hier ließe sich, denke ich, leichter eine Integrationsumgebung aufsetzen, mit der ich meine Konfigurationsänderungen vorab prüfen kann. Da ich alle meine Dienste im Docker laufen habe, könnte sich das vielleicht ganz bequem lösen lassen.

Frisch ans Werk

Konfigurations-Repo anlegen

Gut, dann ziehe ich mir in einem ersten Schritt die Konfigurationsdateien vom Server. Dafür nutze ich das Dateitransferkommando scp: scp server:/path/to/source path/to/target etwa ein Dutzend mal, bis ich alle Konfigurationsdateien auf meinem Server erwischt habe.

Ich setze die Ordnerstruktur in diesem Repo direkt so auf, wie die Dateien auf dem Server liegen. So, hoffe ich, mache ich mir das Leben später etwas leichter.

Secrets in `docker-compose.yml`

Nur - was tue ich mit “secrets” in den Konfigurationsdateien? Also privaten Schlüsseln, registration tokens, hashes? Die möchte ich lieber nicht mehr oder minder offen im Repository herumliegen haben. Bei Verwendung von docker-compose ist das das recht einfach: Ich kann geheime Werte in versteckte Dateien für Umgebungsvariablen auslagern und vom Git-Tracking ausnehmen. Im einfachsten Falle heißen solche Dateien schlicht .env und beinhalten eine Aufzählung an Umgebungsvariablen im Stil von

BORG_PASSPHRASE="<redacted>"

In der entsprechenden docker-compose.yml ziehe ich die Variable aus der Datei .env wie folgt an:

- BORG_PASSPHRASE=${BORG_PASSPHRASE}

Diese Änderungen nehme ich direkt mal lokal auf meinem Laptop vor. Über die .gitignore teile ich mittels .* mit, dass versteckte Dateien und damit .env nicht ins Repository aufgenommen werden sollen. Doch woher weiß ich nun, ob die Container noch korrekt hochfahren?

Secrets in Giteas `app.ini`

Bei Gitea habe ich mich schon deutlich schwerer damit getan, Secrets in Dateien auszulagern. Die app.ini wird auch von Gitea dynamisch geschrieben, sodass die Datei bei jedem Neustart des Services ein wenig anders aussieht. Nach langer Recherche fand ich dieses Issue, in welchem eine Lösung für das separate Speichern von Secrets gesucht und gefunden wurde.

Sinnvoll erscheint mir nur das separate Speichern der Werte INTERNAL_TOKEN sowie SECRET_KEY.
Die anderen beiden Properties LFS_JWT_SECRET und JWT_SECRET werden ohnehin automatisch generiert und regelmäßig überschrieben.

In meiner Konfiguration verwende ich lediglich INTERNAL_TOKEN. Also werde jenes im Klartext und ohne Anführungszeichen in eine versteckte Datei kopieren (.INTERNAL_TOKEN) und sie per Docker-Volume dem Container zur Verfügung stellen:

# Gitea's docker-compose.yml
# [...]
 volumes:
 - ./.INTERNAL_TOKEN:/run/secrets/INTERNAL_TOKEN:ro
 # [...]

In der app.ini ist es nun wichtig, den in der Composedatei angegebenen Pfad einzusetzen:

# Gitea's app.ini
# [...]
 server:
 INTERNAL_TOKEN = /run/secrets/INTERNAL_TOKEN
 # [...]

Nicht etwa wie im oben verlinkten Issue angegeben INTERNAL_TOKEN_URI=/run/secrets/INTERNAL_TOKEN, denn dies erzeugt in der von mir momentan verwendeten V1.22.1 einen Fehler: Unsupported URI-Scheme.

Mal ganz grob testen

Um zu prüfen, ob die geänderten Konfigurationsdateien noch funktionieren, installiere ich mir docker und docker-compose auf meinem Laptop. Anschließend probiere ich, die Container mal hochzufahren.

# docker console log
Error: Network 'caddy-proxy' declared as external, but could not be found.

Stimmt ja, Docker ist hier noch gar nicht konfiguriert. Also das Netzwerk erstellen: sudo docker network create caddy-proxy und erneut versuchen. Schon beginnt der Download von Gitea samt Abhängigkeiten und der Container startet - wenn auch nicht so wie ich mir das vorgestellt habe: Innerhalb von Docker stimmen die Ordnerberechtigungen nicht, sodass weder Gitea, noch Act-runner auf alle benötigten Dateien zugreifen kann.

Dennoch, einen ersten Fehler finde ich:

# gitea container log
WARNING: The GITEA_RUNNER_REGISTRATION_TOKEN variable is not set. Defaulting to a blank string.

Ich hatte nämlich vergessen, den Token-String in Anführungszeichen zu setzen.

Für eine voll funktionsfähige Integrationsumgebung musste ich also noch mindestens zwei weitere Probleme lösen: Ordnerberechtigungen für den Main auf meinem Laptop müssen so angelegt sein, dass auch der User Docker Schreibrechte bekommt. Als einfache Lösung genügt vorerst, den betreffenden Volumes ein :Z anzuhängen und sie so als private unshared kennzuzeichnen. Eine Volumendefinition sieht in meiner docker-compose.yml nun so aus:

# gitea/docker-compose.yml
# [...]
volumes:
 - ./gitea:/data:Z
 # [...]

Ich benötige eine zweite Datei für Umgebungsvariablen, um meine Dienste auf localhost umzubiegen. Immerhin startet der Service auch so und ich sehe die Logausgabe. Die meisten Konfigurationsfehler kann ich bereits jetzt entdecken.

Ich bin mir nicht sicher, aber möglicherweise bekomme ich zusätzliche Probleme mit dem caddyserver wie Zertifikatsverwaltung, Proxy-Einstellungen und so weiter.

Eine Deploy-Pipeline erstellen

Jetzt wäre es noch super, wenn die in das Gitea-Repo hochgeladenen (und vorab lokal auf Funktion getesteten) Dateien automatisch ihren Weg auf meinen Server finden würden. Hierfür könnte ich ein weiteres Docker-Volume anlegen, wo act-runner dann die per on:push Trigger abgelegten Daten hinpackt. Sie würden dann auf meinem Server verfügbar werden.

Setup

Erinnern wir uns an meine letzten Versuche mittels act_runner Artefakte auf dem Server bereit zu stellen, so können wir einen Großteil dessen auch für diese Aufgabe übernehmen:

# deploy-to-server.yml
# Workflow for saving the server's config repo to the local disk system

name: Upload-server-config
run-name: ${{ gitea.actor }} uploads server configuration files
on:
 push:
 branches:
 - main

jobs:
 # Deploy job
 build:
 runs-on: ubuntu-latest # this is the "label" the runner will use and map to docker target OS
 container: 
 volumes: 
 # left: where the output will end up on disk, right: volume name inside container
 - /opt/server-config:/workspace/schallbert/server-config/tmp

 steps:
 - name: --- CHECKOUT ---
 uses: actions/checkout@v3
 with: 
 path: ./tmp
 - name: --- RUN FILE CHANGE TRIGGER ---
 run: |
 cd ./tmp/automation-hooks-trigger
 touch server-config-update.txt

Merkwürdige Volumefehler

Doch der Weg bis hierhin war steinig. Lange hatte ich unter volumes: auf der Containerseite lediglich /server-config angegeben und nicht das Arbeitsverzeichnis des Runners. Dann läuft die Action zwar durch und alle Befehle der #TEST-Sektion funktionieren auch. Wenn ich aber auf meinem Server nachschaue, bleibt der von Docker angelegte server-config Ordner leer.

Mit folgenem Debug-Code unter RUN FILE CHANGE TRIGGER helfe ich mir, die Pfadfehler zu finden:

# deploy-to-server.yml
# [...]
run: |
 echo "hello world"
 touch updated.txt
 pwd
 ls -al

Mit echo prüfe ich, ob mein Code im Runner überhaupt ausgeführt wird. Das touch-Kommando setzt mir den aktuellen Zeitstempel in die updated.txt-Datei, sodass ich dies später als “Hook” für weitere Automation verwenden kann. pwd zeigt mir den aktiven Pfad innerhalb des Runners an, sodass ich das Docker-Volume korrekt auf die Server-Festplatte abbilden kann. ls -al zeigt mir, ob die im Schritt CHECKOUT zusammengestellten Konfigurationsdateien korrekt geschrieben wurden.

Ich erkenne dadurch, dass der Volume-Pfad auf der “rechten Seite” falsch war. Ich biege ihn entsprechend auf das aktive Verzeichnis des Runners um:

# deploy-to-server.yml
# [...]
 # left: where the output will end up on disk, right: volume name inside container
 - /opt/server-config:/workspace/schallbert/server-config/
# [...]

Anschließend bekam ich Folgendes zu lesen:

# gitea / act-runner console log
failed to create container: 'Error response from daemon: Duplicate mount point: /workspace/schallbert/server-config'

Anscheinend legt sich der Runner die “rechte Seite” des Mountpoints automatisch selbst an und kann daher nicht erneut belegt werden. Erst durch das Hinzufügen eines weiteren Pfadteiles, in meinem Falle /tmp - siehe oben - behebe ich den Fehler und auf meinem Server erscheint endlich 😌 der lang ersehnte Ordner server-config mit Inhalt:

schallbert@schallbert-ubuntu-:/opt/server-config# ls -al
total 52
drwxr-xr-x 9 root root 4096 Jul 12 15:38 .
drwxr-xr-x 9 root root 4096 Jul 11 19:56 ..
-rwxr-xr-x 1 root root 395 Jul 11 20:05 boot-after-backup.sh
drwxr-xr-x 3 root root 4096 Jul 11 20:05 borgmatic
drwxr-xr-x 2 root root 4096 Jul 11 20:05 caddy2
drwxr-xr-x 3 root root 4096 Jul 11 20:05 fail2ban
drwxr-xr-x 8 root root 4096 Jul 12 15:38 .git
drwxr-xr-x 3 root root 4096 Jul 11 20:05 .gitea
drwxr-xr-x 4 root root 4096 Jul 11 20:05 gitea
-rw-r--r-- 1 root root 312 Jul 11 20:05 .gitignore
-rw-r--r-- 1 root root 557 Jul 11 20:05 README.md
-rwxr-xr-x 1 root root 371 Jul 11 20:05 shutdown-for-backup.sh
-rw-r--r-- 1 root root 0 Jul 12 15:38 updated.txt
drwxr-xr-x 2 root root 4096 Jul 11 20:05 watchtower

Verteilen der Konfiguration auf dem Server

Gut, damit sind die ersten Schritte getan. Ich habe nun ein vernünftig konfiguriertes Git-Repository, was meine Server-Konfiguration abbildet und vom Laptop aus gepflegt und zumindest rudimentär getestet werden kann. Außerdem kann ich über eine automatische Action Updates der Konfiguration auf dem Server ablegen und eine Update-Datei mit Zeitstempel beschreiben.

Nun muss das Update auf dem Server noch entgegengenommen, verteilt und die betroffenen Programme und Dienste sollen neu gestartet werden. Doch dies schauen wir uns im Artikel Serverkonfiguration ausrollen an.

Automatische Updates für alles!

Schallbert — Sat, 20 Jan 2024

Wie der Titel schon sagt, möchte ich Sicherheitsupdates gern installiert haben, sobald sie erscheinen. Dies gilt gleichsam für das Ubuntu meines Cloud-Servers wie auch für alle Applikationen, die ich in Docker betreibe. Da ich faul bin, möchte ich diese Sicherheitsupdates nicht manuell vornehmen, sondern vollautomatisch ablaufen lassen.

Für Funktionsupdates und -Erweiterungen hingegen ist es auch weiterhin OK für mich, von Zeit zu Zeit manuell einzugreifen. Beginnen wir also mit den Systemupgrades.

Sicherheitsupdates per `unattended-upgrades`

Ubuntu stellt - wie eine kurze Suchmaschinenabfrage ergibt - bereits ein konfigurierbares Werkzeug für solche automatisierten Updates zur Verfügung: unattended-upgrades. Ich prüfe zuerst, ob es bereits auf meinem System vorhanden ist:

Installation

schallbert:~# which unattended-upgrades
/usr/bin/unattended-upgrades

Prima, es ist bereits da. Ansonsten hätte ich die Installation schnell mit apt install unattended-upgrades nachgeholt.

unattended-upgrades konfigurieren

Hier hilft das Debian Wiki weiter: Die Konfigurationsdateien liegen in /etc/apt/apt.conf.d.

Zuerst gehe ich sicher, dass automatische Updates aktiviert sind. Hierfür prüfe ich die Datei 20auto-upgrades und stelle sicher, dass Paketindex-Updates und Upgradeinstallation aktiviert sind:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Sehr gut. Jetzt sollte ich noch festlegen, zu welchem Zeitpunkt das Tool loslaufen und welcher Typ Updates installiert werden soll. Hierfür öffne ich die Datei 50unattended-upgrades und entferne die Kommentare bei den entsprechenden Zeilen.

Updatequellen festlegen

Der erste Abschnitt der Konfigurationsdatei widmet sich der erlaubten Quellen für die Updates. Hier sollten selbstverständlich nur vertrauenswürdige Provider stehen. Meine Konfig sieht hier wie folgt aus:

Unattended-Upgrade::Allowed-Origins {
 "${distro_id}:${distro_codename}";
 "${distro_id}:${distro_codename}-security";
 "${distro_id}ESMApps:${distro_codename}-apps-security";
 "${distro_id}ESM:${distro_codename}-infra-security";
};

Erlaubt werden hier Quellen für die von mir verwendete Linux-Distribution im Allgemeinen und Sicherheitsupdates inklusive ESM, was für “Extended Security Maintenance” steht.

Updates auch für Dev Releases?

Die folgende Zeile legt fest, ob auch Vorabversionen von Ubuntu Updates erhalten sollen. Bei mir steht der Wert auf auto.

Unattended-Upgrade::DevRelease "auto";

Automatischer Neustart

Einige Sicherheitsupdates (z.B. den Kernel betreffend) erfordern einen Neustart der Maschine. Sie werden daher nur in Kraft treten, wenn man in der Datei entsprechende Werte gesetzt hat. Dabei ist WithUsers natürlich Geschmackssache, denn man wird ausgeloggt, falls zufälligerweise gerade ein Update installiert wurde, was einen Neustart erfordert. Um das praktisch auszuschließen, habe ich unter Reboot-Time eine Zeit eingetragen, bei der ich sicher nicht an der Maschine hocke.

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:45";

Unangekündigte Neustarts haben natürlich Rückwirkung auf alle Programme, die ich verwende. Daher stelle ich in meinen docker-compose.yml Dateien sicher, dass dort bei restart: auch wirklich always oder unless-stopped notiert ist.

Benachrichtigungen

Automatische Mails oder anderweitige Push-Benachrichtigungen habe ich erst einmal nicht eingeschaltet, da ich mich noch im Testbetrieb befinde und keine große Lust auf einen Haufen weiterer Nachrichten habe. Sobald ich dies ändere, gibt es hier ganz bestimmt ein Update.

Funktionsprüfung

Um zu sehen, ob unattended-upgrades tut was es soll, schaue ich ein paar Tage später mal in die Logs unter /var/log/unattended-upgrades. Hier steht in der Datei unattended-upgrades.log zum Beispiel folgendes:

# [...]
2024-01-12 06:17:59,781 INFO Starting unattended upgrades script
2024-01-12 06:17:59,781 INFO Allowed origins are: o=Ubuntu,a=jammy, o=Ubuntu,a=jammy-security, o=UbuntuESMApps,a=jammy-apps-security, o>
2024-01-12 06:17:59,781 INFO Initial blacklist:
2024-01-12 06:17:59,782 INFO Initial whitelist (not strict):
2024-01-12 06:14:33,956 INFO Packages that will be upgraded: libc-bin libc-dev-bin libc-devtools libc6 libc6-dev locales python3-twisted
2024-01-12 06:14:33,956 INFO Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
2024-01-12 06:14:54,578 INFO All upgrades installed
# [...]

Die Datei unattended-upgrades-shutdown.log ist allerdings noch leer. Ich werde zu einem späteren Zeitpunkt prüfen, ob hier auch alles funktioniert.

Container-Updates mit `Watchtower` automatisieren

Nun zu den Updates meiner Applikationen. Ein kurzes Gespräch mit ein paar Admins ergab:

Es ist mühsam, alle Programme von Hand auf Stand zu halten
Für Anwendungen im Container gibt es Dienste, die diese Aufgabe zentral lösen
Es gab bereits schlechte Erfahrungen, wenn in der docker-compose.yml auf den aktuellsten Release referenziert wird
Bei image: <application>:latest seien hier nicht alle Anwendungen stabil bzw. erzeugten Probleme mit Abhängigkeiten

Einer Lösung für dieses Problem bietet Watchtower, welches in meinem Falle selbst wieder in einem Container läuft.

Installation

Wie üblich schreibe ich mir in einem neuen Ordner unter opt/watchtower eine docker-compose.yml:

# copied from https://containrrr.dev/watchtower/notifications/

# watchtower/docker-compose.yml
version: "3"
services:
 watchtower:
 image: containrrr/watchtower
 restart: unless-stopped
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock

Watchtower benötigt docker.sock, um die Updates zu ziehen und auf den vorhandenen Containern anzuwenden. Ansonsten habe ich hier erst einmal nichts weiter unternommen. Keine Benachrichtigungen (aus obengenannten Gründen), keine Logs, nichts. Ich hoffe, dieses Setup bleibt geräuschlos und ich muss mich hier lange nicht mit einem Update zu Wort melden.

Weitergehende Schritte für die Validierung der Funktion von Watchtower finden sich z.B. in einem Tutorial von DigitalOcean.

Ablauf

Watchtower prüft die Installierten Docker images lt. Doku täglich auf Updates. Sollte des ein neues Image-release geben, schickt Watchtower ein SIGTERM-Signal an upzudatende Container, worauf sich selbige herunterfahren (Quelle). Anschließend werden die Container wieder hochgefahren.

Unfreiwillige Funktionsprüfung

Ein paar Tage nach Start des Containers wählte ich mich nochmal in meinen Server ein und sah auf gut Glück ein paar Logs durch. Ich wollte nur kurz nach dem Rechten schauen.

In den fail2ban Logdateien sah ich zu einem bestimmten Zeitpunkt, Uhrzeit 14:42:56 plötzlich seitenweise Einträge. Mehr davon, als ich die Tage vorher insgesamt gesehen hatte. Als ich zum Beginn dieser Kette von Einträgen hochscrollte, sah ich, dass fail2ban mir wohl kurz ausgestiegen war.

 2024-01-26 14:42:50,817 <container_id> INFO Shutdown in progress...
 2024-01-26 14:42:50,817 <container_id> INFO Observer stop ... try to end queue 5 seconds
 2024-01-26 14:42:50,837 <daemon_id> INFO Observer stopped, 0 events remaining.
 2024-01-26 14:42:50,878 <container_id> INFO Stopping all jails
 2024-01-26 14:42:50,879 <container_id> INFO Removed logfile: '/var/log/auth.log'
 2024-01-26 14:42:50,879 <container_id> INFO Removed logfile: '/var/log/caddy2/gitea_access.log'
 2024-01-26 14:42:50,879 <container_id> INFO Removed logfile: '/var/log/caddy2/server_access.log'
 2024-01-26 14:42:51,052 <daemon_id> NOTIC [sshd] Flush ticket(s) with iptables
 2024-01-26 14:42:51,063 <container_id> INFO Jail 'sshd' stopped
 2024-01-26 14:42:51,137 <daemon_id> NOTIC [caddy-status] Flush ticket(s) with iptables-multiport
 2024-01-26 14:42:51,137 <container_id> INFO Jail 'caddy-status' stopped
 2024-01-26 14:42:51,138 <container_id> INFO Connection to database closed.
 2024-01-26 14:42:51,139 <container_id> INFO Exiting Fail2ban
 2024-01-26 14:42:56,173 <new_container_id> INFO --------------------------------------------------
 2024-01-26 14:42:56,173 <new_container_id> INFO Starting Fail2ban v1.0.2
 2024-01-26 14:42:56,173 <new_container_id> INFO Observer start...
[...]

Die ganzen Log-Einträge zur selben Uhrzeit beginnen am Ende des oben gezeigten Abschnitts. Ein ganzer Haufen IP-Adressen wird dort zur Vorbereitung des Banns in Fail2ban geladen. Leicht beunruhigt schaute ich ins Syslog von Ubuntu:

Jan 26 14:42:55 schallbert systemd[1]: docker-<ID>.scope: Deactivated successful
Jan 26 14:42:55 schallbert systemd[1]: docker-<ID>.scope: Consumed 21:05 CPU time
Jan 26 14:42:55 schallbert dockerd[690]: time="2024-01-26T14:42:55.228607617Z" level=info msg="ignoring event" 
Jan 26 14:42:55 schallbert containerd[639]: time="2024-01-26T14:42:55.229864632Z" level=info msg="shim disconnected" 
Jan 26 14:42:55 schallbert containerd[639]: time="2024-01-26T14:42:55.230125409Z" level=warning msg="cleaning up after shim disconnected" i>
Jan 26 14:42:55 schallbert containerd[639]: time="2024-01-26T14:42:55.230145478Z" level=info msg="cleaning up dead shim"
Jan 26 14:42:55 schallbert containerd[639]: time="2024-01-26T14:42:55.240586557Z" level=warning msg="cleanup warnings time=\"2024-01-26T14:>
Jan 26 14:42:55 schallbert dockerd[690]: time="2024-01-26T14:42:55.241839655Z" level=warning msg="ShouldRestart failed
Jan 26 14:42:55 schallbert containerd[639]: time="2024-01-26T14:42:55.870912387Z" level=info msg="loading plugin \"io.containerd.event.v1.p>
Jan 26 14:42:55 schallbert containerd[639]: time="2024-01-26T14:42:55.870997689Z" level=info msg="loading plugin \"io.containerd.internal.v>
Jan 26 14:42:55 schallbert containerd[639]: time="2024-01-26T14:42:55.871007368Z" level=info msg="loading plugin \"io.containerd.ttrpc.v1.t>
Jan 26 14:42:55 schallbert containerd[639]: time="2024-01-26T14:42:55.871150831Z" level=info msg="starting signal loop" namespace=moby path>

Hm, cleaning up dead shim. Das klingt ja bedrohlich. Eine kurze Recherche zeigt, dass die Shim eine Zwischenschicht zwischen Containermanager und dem Container selbst bildet und Ein-und Ausgaben des Containers weiterleitet. Ihre Laufzeit ist an die des Containers gekoppelt.

Also war dies ein normales Herunterfahren mit anschließendem Neustart. Zum Glück kein Einbruch! Bleibt nur noch der Grund für den Neustart von Fail2ban herauszufinden. Da fällt mir ein, dass ich noch gar nicht weiß, wann Watchtower genau die Updates fährt…

Also mal schnell in die Logs von Watchtower geschaut mit docker container logs <container_id> und siehe da:

time="2024-01-26T14:42:47Z" level=info msg="Found new lscr.io/linuxserver/fail2ban:latest image (9bda077d765e)"
time="2024-01-26T14:42:50Z" level=info msg="Stopping /fail2ban (e0317a105d53) with SIGTERM"
time="2024-01-26T14:42:55Z" level=info msg="Creating /fail2ban"
time="2024-01-26T14:42:55Z" level=info msg="Session done" Failed=0 Scanned=6 Updated=1 notify=no

Damit habe ich den Beweis: Watchtower tut was es soll. Es zieht Container auf eine neue Version hoch, sobald Updates verfügbar werden. Prima!

PS: Da ich Watchtower nicht groß konfiguriert habe, nehme ich anhand der in den Logs befindlichen Zeitstempel an, dass die Updates täglich zur Zeit des Starts von Watchtower gefahren werden. Bald werde ich von latest für meine Container wohl auf ein älteres Tag release umschwenken.

Docker on Schallberts Blog

Docker-Images automatisch updaten

Wozu automatische Updates?

Docker image update mit Watchtower

Lösung per Skript

Kompliziert: docker pull, Abgleich mit vorhandenen Images, bei Bedarf einspielen

Einfach: Alles in einem Kommando per Option mitgeben

Eintrag für cron

Welche Version wurde installiert?

Meldung bei Update

Continuous Deployment für Hugo

Die Befehlskette

Erfahrungswerte

Docker shared Volumes

Aufgepasst: Action volume != Hugo volume

Der Workflow

Runner-Betriebssystem anpassen

Das Workflow-Script schreiben

Zielordner bereinigen

Submodules

Typische Probleme: Hugo-Versionen und Deprecations

Änderungen der Language-identifier und -Auswertung ab v0.158

Submodules auf Stand bringen

Eigene Lösungen programmieren

Versionen abgleichen

Giteas act_runner rootless: Startprobleme

Das Fehlerbild

Issue-Ticket bei Gitea

Problem mit Kernel-Berechtigungen?

Warum Container keine Container starten dürfen

Auswirkungen, falls trotz DinD etwas schief geht

Einfache Lösung: DinD-Container privileged starten

Sackgasse: Nur unbedingt benötigte Rechte vergeben

Zukünftige Lösung: Virtualisierung oder Daemonless

Linux Security Modules (seccomp, AppArmor, SELinux)

Apparmor

Einfache Lösung: Komplett abstellen

Richtige Lösung: Für jede Anwendung justieren

Server-Konfiguration mit Git

Worum geht es?

Hintergrund

Vorüberlegungen

1. Hardlink

2. Repo und auto-deploy auf den Server

Probleme

Auswahl meiner Lösung

Frisch ans Werk

Konfigurations-Repo anlegen

Secrets in docker-compose.yml

Secrets in Giteas app.ini

Mal ganz grob testen

Eine Deploy-Pipeline erstellen

Setup

Merkwürdige Volumefehler

Verteilen der Konfiguration auf dem Server

Automatische Updates für alles!

Sicherheitsupdates per unattended-upgrades

Installation

unattended-upgrades konfigurieren

Updatequellen festlegen

Updates auch für Dev Releases?

Automatischer Neustart

Benachrichtigungen

Funktionsprüfung

Container-Updates mit Watchtower automatisieren

Installation

Ablauf

Unfreiwillige Funktionsprüfung

Kompliziert: `docker pull`, Abgleich mit vorhandenen Images, bei Bedarf einspielen

Einfache Lösung: DinD-Container `privileged` starten

Secrets in `docker-compose.yml`

Secrets in Giteas `app.ini`

Sicherheitsupdates per `unattended-upgrades`

Container-Updates mit `Watchtower` automatisieren