Beim Patchen und Betreiben von rund 30 Linux-Gästen sammelt man Erfahrungen, meistens auf die harte Tour. Hier eine Auswahl aus unseren Lessons Learned.
1. apt autoremove löscht Docker samt Daten
Bei einem Release-Upgrade lief apt autoremove --purge. docker.io war nur als Abhängigkeit installiert und wurde mitsamt /var/lib/docker entfernt. Gerettet hat uns ein Snapshot.
Heute: kein automatisches autoremove, Docker-Pakete vorher mit apt-mark manual markieren, und immer ein Snapshot vor Release-Upgrades.
2. MySQL 5.7 im Container und „unendlich“ offene Dateien
containerd startet Container mit LimitNOFILE=infinity. MySQL 5.7 reserviert daraufhin riesige Tabellen und wird vom OOM-Killer beendet.
Heute: default-ulimits für nofile in /etc/docker/daemon.json auf 65536 setzen.
3. „success“, obwohl nichts passiert ist
Ein Ansible-Lauf mit einem Zielnamen, der auf keinen Host passt, ergibt nur eine Warnung – und die Oberfläche meldet Erfolg.
Heute: Jedes Playbook prüft zuerst das Ziel und bricht mit Namensvorschlägen ab.
4. Basic Auth vor einer Anwendung mit eigener Anmeldung
Wiki.js setzt für seine API einen eigenen Authorization-Header. Mit Basic Auth im Reverse Proxy davor landet man in einer Passwort-Schleife.
Heute: Anwendungen mit eigener Anmeldung nicht hinter Basic Auth stellen, Gastzugriff in der Anwendung sperren und von außen in einem privaten Fenster prüfen.
5. Ein totes Zertifikat trennt alle WebSockets
Ein ungenutztes Let’s-Encrypt-Zertifikat scheiterte stündlich bei der Verlängerung, und der Reverse Proxy lud dabei jedes Mal nginx neu. Das trennte alle WebSocket-Verbindungen – die Monitoring-Oberfläche schien „ständig neu zu starten“.
Heute: nicht mehr benötigte Zertifikate sofort löschen und die Logs nach wiederholten „Renewing“-Einträgen durchsuchen.
6. WordPress-Umzug: verschlüsselte Plugin-Passwörter
Manche Plugins verschlüsseln Zugangsdaten mit den Schlüsseln aus wp-config.php, etwa das SMTP-Passwort. Nach dem Umzug mit neuen Schlüsseln ist es nicht mehr lesbar, und der Mailversand fällt still aus.
Heute: Bei jeder Migration Plugin-Geheimnisse prüfen und auf dem neuen Server neu verschlüsseln.
7. MySQL 5.7 auf MariaDB 11.4: Dump statt In-place
Wir migrieren per Dump und Restore in ein neues Volume. Wichtig: Erst warten, bis der Init-Prozess des neuen Containers fertig ist – er startet einmal neu, ein zu früher Import bricht ab. Im 11.x-Image heißen die Werkzeuge mariadb und mariadb-dump, mysql gibt es nicht mehr.
Fazit
Fast jede dieser Fallen ist heute in einem Playbook oder einer Prüfung abgefangen. Die wichtigste Regel bleibt trotzdem: vor jeder größeren Änderung ein Snapshot.