De monitoring mag niet vallen met wat hij bewaakt
Circa 94 containers op een NAS, met een Mac als tweede host. Wat er hoort te draaien staat in een manifest; monitoring vergelijkt de werkelijkheid daarmee. De belangrijkste keuze is wat er níét in Docker draait — die keuze komt uit een crash die we zelf hebben meegemaakt.
Het manifest bepaalt, de werkelijkheid wijkt af
Monitoring die alleen kijkt of een container draait, mist wat er ontbreekt. Door de werkelijkheid te vergelijken met een vastgelegde lijst wordt "er hoort hier iets te draaien" een meetbaar feit — en draait die monitoring zelf buiten de stack die hij controleert.
Wat er misging, en wat er daarna veranderde
Een verkeerd commando raakte een home-directory waarin een SSH-sleutel stond. Tijdens het herstel bezweek het bestandssysteem. De huidige inrichting is geen ontwerp op papier — het is wat er is overgebleven nadat dit fout ging.
Toen
- Alles draaide in dezelfde Docker-stack, ook de monitoring
- Een verkeerd commando raakte een home-directory met een SSH-sleutel erin
- Tijdens het herstel bezweek het bestandssysteem
- De laag die had moeten meekijken lag zelf plat
- Wat er hoorde te draaien stond nergens vastgelegd
Nu
- Kritieke diensten draaien native op het host-systeem (systemd)
- Valt de containerlaag om, dan blijven monitoring, logboek en uitvoering werken
- Een manifest legt vast welke containers er horen te draaien
- Monitoring vergelijkt de werkelijkheid met dat manifest en meldt de afwijking
- Backup met tijdstempel vóór elke wijziging; eerst verifiëren, dan handelen
Zes keuzes die uit ervaring komen
Kritiek draait niet in de stack
Drie diensten zijn bewust uit Docker gehaald en draaien native onder systemd op het host-systeem. Ze bewaken de containerlaag, dus ze mogen er niet van afhangen. Valt Docker om, dan blijven monitoring, logboek en de uitvoerende laag gewoon bereikbaar.
Manifest als bron van waarheid
Een "desired containers"-manifest legt vast welke containers er horen te draaien. Monitoring vergelijkt dat met de werkelijkheid op beide hosts. Een container die ontbreekt is een afwijking, geen interpretatie — en een container die bewust uit staat, staat als zodanig in het manifest.
Werkregels uit een echte crash
Geen recursieve verwijderingen of rechtenwijzigingen op home-directories of volume-roots. Die regel is niet theoretisch: precies daar ging het mis. De SSH-sleutel die de toegang tot het systeem verzorgde, stond in de directory die geraakt werd.
Backup vóór elke wijziging
Elk bestand dat aangeraakt wordt, krijgt eerst een kopie met tijdstempel naast het origineel. Geen apart backupmoment, geen uitzonderingen voor "kleine" wijzigingen. Terugdraaien is daarmee altijd een kwestie van één bestand hernoemen.
Eerst verifiëren, dan handelen
Lees het bestand, check de poort, lees de log — vóór het commando, niet erna. De meeste incidenten in een homelab van deze omvang komen niet uit complexe fouten, maar uit aannames over de staat van het systeem.
Data hoort niet op de systeempartitie
De systeempartitie van het NAS-besturingssysteem is klein (circa 8 GB). Applicatiedata schrijft altijd naar het datavolume. Loopt die partitie boven ongeveer 70% vol, dan is dat geen capaciteitsvraag maar een signaal dat er iets op de verkeerde plek landt.
Draait jouw monitoring in de stack die hij bewaakt?
We beheren circa 94 containers over twee hosts en hebben de architectuur aangepast nadat het één keer echt misging. Die ervaring is bruikbaar voor jouw omgeving.