Le levenscyclus van een stack¶

Machinevertaling van het Franse origineel.

Creëren¶

Creëer 10-stacks/<nom>/ in de vault, met README.md en decisions.md.
Schrijf /opt/docker/<nom>/docker-compose.yml op de host, volgens de conventies.
Valideren: docker compose -f /opt/docker/<nom>/docker-compose.yml config.
Starten: docker compose -f /opt/docker/<nom>/docker-compose.yml up -d.
Als de service op het web wordt geëxposeerd → Publiceer een nieuwe service.
Op vm-docker en vm-compute-01, registreer de stack in /opt/docker/scripts/stack-waves.conf — anders verdwijnt deze bij de eerste herstart (zie hieronder).
Commit de vault en pushen naar beide remote repositories.

Wijzigen¶

Elke wijziging in de configuratie wordt, onmiddellijk, gevolgd door een vermelding in 10-stacks/<nom>/decisions.md: wat is veranderd, waarom, en hoe kan men terugkeren.

Dit is geen bureaucratie. Het is het enige kanaal dat alle werkzaamheden herlezen: een bericht dat luiduit wordt gecommuniceerd of een notitie in het geheugen, hebben elk een stille foutmodus, decisions.md heeft dit niet.

Starten bij opstart¶

Op vm-docker en vm-compute-01, starten de services restart: on-failure:5, nooit always.

docker-staggered.service is de enige autoriteit bij opstart. Het leest /opt/docker/scripts/stack-waves.conf, monteert projecten in fases en wacht tussen elke fase.

sequenceDiagram
    autonumber
    participant S as systemd
    participant D as dockerd
    participant G as docker-staggered
    participant C as conteneurs

    S->>D: docker.service
    D-->>S: prêt
    S->>G: After=docker.service
    loop vagues 0 à 5, 15 s d'écart
        G->>C: compose up -d (projets de la vague)
    end
    Note over S,G: à l'arrêt, l'ordre s'inverse :<br/>staggered-stop tourne PENDANT que dockerd est encore debout

Waarom deze mechaniek bestaat:

op vm-compute-01, is het probleem de lock xtables — elke implementatie van iptables-regels duurt 20 tot 28 seconden, en dockerd blokkeert meer dan tien minuten;
op vm-docker, is het probleem de I/O-wacht — 80 containers op een virtuele schijf met ~1,4 ms per willekeurige leesactie, zorgt voor een belasting van 85.

stateDiagram-v2
    [*] --> running: compose up -d
    running --> crash: le processus meurt<br/>(exit ≠ 0)
    crash --> running: on-failure:5 relance
    crash --> abandonne: 5 échecs d'affilée

    running --> arrete: staggered-stop<br/>(exit 0, arrêt PROPRE)
    arrete --> running: docker-staggered au boot,<br/>SI le projet est dans stack-waves.conf
    arrete --> oublie: sinon, personne ne le rallume

    note right of oublie
        exited · ExitCode=0 · RestartCount=0
        aucune erreur, aucune alerte
        et le vhost Caddy répond en 502
    end note

on-failure:5 dekt alleen de linker tak. De rechter tak heeft geen automatische commit: het is het wave-bestand, en niets anders.

Een stack die ontbreekt in stack-waves.conf, wordt niet hersteld, en er wordt er niets over gerapporteerd

Dit is een direct gevolg van on-failure:5: een container die correct wordt gestopt (code 0) wordt niet opnieuw opgestart door Docker. Of, precies wat staggered-stop doet voordat de host opnieuw wordt opgestart: een correcte stop.

Als het project niet in stack-waves.conf staat, wordt het niet automatisch opnieuw opgestart bij het opstarten. De container blijft exited met ExitCode=0, RestartCount=0, zonder fouten in de logs, zonder waarschuwingen: het is niet gecrasht, het is uitgeschakeld en nooit opnieuw opgestart.

Dit gebeurde op 2026-08-30 op homelab-docs, werd de avond ervoor in gebruik genomen en ontbreekt in het bestand: een correcte stop om 01:45 tijdens de nachtelijke patch-herstart, tot het werd opgespoord. De vhost Caddy reageerde echter wel — met een 502-fout.

De controle, na de inzet:

grep -c '<nom-du-projet>' /opt/docker/scripts/stack-waves.conf   # doit rendre 1

Controleer of een container daadwerkelijk voldoet aan de aangegeven beleid

docker inspect <conteneur> \
  --format '{{.HostConfig.RestartPolicy.Name}}:{{.HostConfig.RestartPolicy.MaximumRetryCount}}'

Dit moet worden vergeleken met restart: in het Compose-bestand. Een verschil betekent dat een up -d --force-recreate het oude beleid opnieuw heeft geactiveerd.

Diagnostiseren van¶

Volgorde van controle, van het goedkoopste naar het duurste:

docker ps — draait de container, en sinds wanneer?
RestartCount — start het in een lus?
docker logs --since 1h — wat zegt het zelf?
Status — maar zie de waarschuwing hieronder.
Netwerk, volumes, geheugen.

healthy betekent niet 'de service werkt'

De status is wat de image zelf heeft gekozen om te testen, niets meer. Er zijn hier enkele concrete gevallen: een gesloten poort terwijl de container healthy is, een secundaire service die zonder effect is, een interval van 15 minuten die de status onbruikbaar maakt tijdens een incident.

Een gevolg voor monitoring: falen op unhealthy, nooit op starting.

Een sonde kan iets anders meten dan de service

Een single-process service dat zijn status op schijf synchroon schrijft, blokkeert zijn gebeurtenisloop tijdens het schrijven – 20 tot 30 seconden voor een graaf van 45.000 knopen. De sonde stopt, maar de container is nooit opnieuw gestart. De oplossing ligt bij de supervisie (langere tijd, drempel voor opeenvolgende fouten), niet bij het service zelf.

Uitschakelen¶

Stoppen en verwijderen docker compose -f /opt/docker/<nom>/docker-compose.yml down.
Het blok verwijderen uit het Caddyfile, van beide Caddy's als het service publiekelijk was.
Het domeinnaam verwijderen uit de lijst met certificaatuitgifte.
De entry stack-waves.conf verwijderen van de georkestreerde hosts.
Het vault-dossier archiveren in plaats van te verwijderen, en sluit decisions.md af met een datum.

Een gepubliceerd naam aan de edge met een geldig certificaat is een open deur

Het blok Caddy achterlaten na het stoppen van de container doet "niets": wanneer iemand een container met dezelfde service-naam start, wordt deze onmiddellijk publiekelijk, zonder dat er een review nodig is. Er zijn blokken verwijderd om precies deze reden tijdens de audit van 2026-07-22.

Dernière vérification de cette page : 2026-08-30