sorb/axion1337.chat-gitops
1
0
Fork 0
Code Issues Pull Requests Packages Projects 1 Releases 24 Wiki Activity

[MEDIUM] Monitoring-Deploy: geaenderte Configs greifen nicht ohne --force-recreate (Inode-Falle bei Einzeldatei-Mounts) #52

New Issue
Closed
opened 2026-08-01 12:02:57 +00:00 by sorb · 1 comment
sorb commented 2026-08-01 12:02:57 +00:00
Owner
Copy Link
Copy Source

Beim Deploy von #47 aufgefallen, betrifft aber jede Config-Aenderung am Monitoring-Stack.

Symptom

cd /opt/threadnet-operating && git pull && cd monitoring && docker compose up -d aktiviert geaenderte Config-Dateien nicht. Nach dem Deploy von #47 liefen Scanner und Exporter, aber Prometheus hatte weder den neuen Scrape-Job cve_exporter noch die axion-cve-Regelgruppe geladen -- promtool fand 9 Regeln in der Datei, Prometheus kannte 6.

Ursache

prometheus.yml, alerts.yml und alertmanager.yml sind als einzelne Dateien gemountet. Docker haengt so einen Bind-Mount am Inode auf. git pull schreibt eine neue Datei und benennt sie um -- neuer Inode. Der Container zeigt weiter auf die alte Datei.

Zwei Effekte, die es schwer sichtbar machen:

  • docker compose up -d startet die Container nicht neu, weil die Service-Definition unveraendert ist. Es meldet Running und sieht erfolgreich aus.
  • Ein SIGHUP-Reload laedt brav neu -- nur eben den alten Inhalt. Kein Fehler im Log.

Auf der Platte steht also die neue Config, im Container die alte, und nichts meldet einen Fehler.

Nachweis

$ grep -c axion-cve monitoring/prometheus/alerts.yml            # 1
$ docker exec prometheus grep -c axion-cve /etc/prometheus/alerts.yml   # 0

Abhilfe

Nach jedem git pull, der eine dieser Dateien anfasst:

docker compose up -d --force-recreate prometheus alertmanager

Verifikation muss im Container stattfinden, ein Blick auf die Platte beweist nichts.

Nicht betroffen

Verzeichnis-Mounts (grafana/provisioning/, grafana/dashboards/) loesen ueber den Pfad auf und ziehen Aenderungen mit. Grafana liest Provider-Definitionen aber nur beim Start -- ein neuer Dashboard-Ordner braucht docker compose restart grafana. Dashboard-JSONs innerhalb eines bestehenden Providers werden laufend nachgezogen.

Moegliche Dauerloesung

Statt Einzeldateien die Verzeichnisse mounten (./prometheus:/etc/prometheus:ro), dann verschwindet die Inode-Falle. Dokumentiert ist der Fallstrick vorerst in monitoring/README.md (Commit 2b715ca).

Beim Deploy von #47 aufgefallen, betrifft aber **jede** Config-Aenderung am Monitoring-Stack. ## Symptom `cd /opt/threadnet-operating && git pull && cd monitoring && docker compose up -d` aktiviert geaenderte Config-Dateien **nicht**. Nach dem Deploy von #47 liefen Scanner und Exporter, aber Prometheus hatte weder den neuen Scrape-Job `cve_exporter` noch die `axion-cve`-Regelgruppe geladen -- `promtool` fand 9 Regeln in der Datei, Prometheus kannte 6. ## Ursache `prometheus.yml`, `alerts.yml` und `alertmanager.yml` sind als **einzelne Dateien** gemountet. Docker haengt so einen Bind-Mount am Inode auf. `git pull` schreibt eine neue Datei und benennt sie um -- neuer Inode. Der Container zeigt weiter auf die alte Datei. Zwei Effekte, die es schwer sichtbar machen: - `docker compose up -d` startet die Container nicht neu, weil die Service-Definition unveraendert ist. Es meldet `Running` und sieht erfolgreich aus. - Ein `SIGHUP`-Reload laedt brav neu -- nur eben den **alten** Inhalt. Kein Fehler im Log. Auf der Platte steht also die neue Config, im Container die alte, und nichts meldet einen Fehler. ## Nachweis ``` $ grep -c axion-cve monitoring/prometheus/alerts.yml # 1 $ docker exec prometheus grep -c axion-cve /etc/prometheus/alerts.yml # 0 ``` ## Abhilfe Nach jedem `git pull`, der eine dieser Dateien anfasst: ```bash docker compose up -d --force-recreate prometheus alertmanager ``` Verifikation muss **im Container** stattfinden, ein Blick auf die Platte beweist nichts. ## Nicht betroffen Verzeichnis-Mounts (`grafana/provisioning/`, `grafana/dashboards/`) loesen ueber den Pfad auf und ziehen Aenderungen mit. Grafana liest **Provider-Definitionen** aber nur beim Start -- ein neuer Dashboard-Ordner braucht `docker compose restart grafana`. Dashboard-JSONs innerhalb eines bestehenden Providers werden laufend nachgezogen. ## Moegliche Dauerloesung Statt Einzeldateien die Verzeichnisse mounten (`./prometheus:/etc/prometheus:ro`), dann verschwindet die Inode-Falle. Dokumentiert ist der Fallstrick vorerst in `monitoring/README.md` (Commit `2b715ca`).
sorb commented 2026-08-01 14:26:16 +00:00
Author
Owner
Copy Link
Copy Source

Migriert nach git.lab: axion1337.chat/axion1337.chat-gitops#50 (nur im Lab bzw. via VPN erreichbar — das Lab ist seit 2026-08-01 die Quelle der Wahrheit, siehe gitops#48). Weiterarbeit dort; dieses Gitea-Issue bleibt als Verweis stehen.

**Migriert nach git.lab**: [axion1337.chat/axion1337.chat-gitops#50](https://git.lab/axion1337.chat/axion1337.chat-gitops/-/issues/50) (nur im Lab bzw. via VPN erreichbar — das Lab ist seit 2026-08-01 die Quelle der Wahrheit, siehe gitops#48). Weiterarbeit dort; dieses Gitea-Issue bleibt als Verweis stehen.
sorb closed this issue 2026-08-01 14:26:16 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area:authentik
Authentik Identity Provider
 area:database
Database and backups
 area:element
Element and UI
 area:infrastructure
K3S and infrastructure
 area:security
Security hardening
 priority:critical
Critical - This week
 priority:high
High - 1-2 weeks
 priority:low
Low - nice to have
 priority:medium
Medium - ~1 month
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
sorb (ScrublordMcBad)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sorb/axion1337.chat-gitops#52