DevOps

La test suite è verde da tre settimane. Oggi npm test fallisce su un’asserzione che non ha niente a che fare con quello che hai appena modificato, e git log v1.4.0..HEAD mostra 340 commit di quattro persone dall’ultima release, di cui qualcuno era sicuro che funzionasse. Leggere ogni diff ti costa una giornata. Fare checkout di commit a caso è più veloce, ma resta comunque non un piano. git bisect trasforma tutto questo in una ricerca binaria. Gli dai un commit che sai essere buono e uno che sai essere rotto; lui fa il checkout del commit a metà tra i due e aspetta che tu lo testi e riporti il risultato. Ogni risposta dimezza l’intervallo. 340 commit si risolvono in al massimo 9 test, perché 2^9 = 512. ...

Cosa fa davvero il DNS a ogni richiesta Ogni richiesta verso example.com inizia con una ricerca che non ha niente a che fare con la tua applicazione: qualcosa deve trasformare quel nome in un indirizzo IP prima che un solo pacchetto TCP lasci la macchina. Quella traduzione è il DNS, il Domain Name System, e gira a ogni richiesta, che il client sia un browser, curl, o un servizio backend che ne contatta un altro tramite hostname. ...

Cosa protegge davvero TLS su una connessione HTTPS Carica una pagina in http:// puro su una rete che non controlli, un aeroporto o il router di un bar, e tutto quello che invii viaggia come testo leggibile. Il percorso dell’URL, i cookie, i campi del form, la password in un POST di login: chiunque su quella rete con uno sniffer di pacchetti li legge mentre passano. TLS, Transport Layer Security, è il protocollo che blocca questo scenario. Si inserisce tra TCP e il protocollo applicativo, quindi quando HTTP inizia a parlare la connessione è già cifrata e legata a un’identità server verificata. HTTPS è semplicemente HTTP eseguito su quella connessione invece che su una in chiaro. ...

Un endpoint di checkout che ridimensiona l’immagine di un prodotto, invia un’email di conferma e aggiorna un motore di raccomandazione prima di rispondere con 200 OK è veloce quanto il suo passaggio più lento. Se anche uno solo va in timeout, l’intera richiesta fallisce. Una coda di messaggi permette all’endpoint di passare quel lavoro come messaggi e rispondere subito, mentre worker separati lo prendono in carico con i propri tempi. ...

Ogni risorsa cloud che hai mai creato cliccando in una console web (una VM, un load balancer, un record DNS) si può descrivere anche in un file di testo e creare con un solo comando. Il file vive nel repository git, passa da una pull request, e riproduce lo stesso setup su un secondo account senza che nessuno debba ricordare quali nove impostazioni ha cambiato a mano. È questo che fa Terraform. ...

Una query che impiega 200ms sul tuo database impiega 200ms anche alla milionesima esecuzione, e ogni esecuzione compete per le stesse connessioni, lo stesso I/O su disco e la stessa CPU. Redis tiene la risposta in memoria, su un server che non fa altro, così la milionesima lettura costa un round trip di rete invece di un piano di query. Cosa fa davvero Redis come cache Redis è un key-value store in memoria. I valori vivono in RAM, quindi letture e scritture si misurano in tempi sotto il millisecondo invece delle decine o centinaia di millisecondi che costa una query relazionale una volta che entrano in gioco join, indici sotto pressione o un connection pool occupato. Si affianca al tuo database, non lo sostituisce: la tua applicazione interroga prima Redis e va al database solo quando Redis non ha la risposta. ...

Cosa c’è tra il browser e la tua app Punta il browser su example.com e la richiesta non tocca mai il processo che esegue il tuo codice. Incontra prima qualcos’altro: un server che legge la richiesta, decide quale backend deve rispondere, la inoltra lì e rimanda indietro la risposta come se l’avesse prodotta lui stesso. Quel server è un reverse proxy. Nginx, Caddy, Traefik e HAProxy fanno tutti questo lavoro, così come il load balancer davanti a un cluster Kubernetes. La disposizione non cambia mai: i client parlano con il proxy e con nient’altro. I server reali restano dietro, in qualunque numero e ovunque girino. ...

Fai il pull dell’ultimo main e Git si blocca con CONFLICT (content): Merge conflict in checkout.js. Risolvi il conflitto e nel log compare un commit chiamato Merge branch 'main' into feature/checkout, appoggiato sopra i tre commit che avevi effettivamente scritto tu. Quattro commit, una sola modifica reale. Un collega che legge quella storia il mese prossimo non riesce più a distinguerli. git merge e git rebase rispondono alla stessa domanda: come allineo il mio branch alle modifiche fatte altrove. Lasciano tracce molto diverse, e scegliere quello sbagliato su un branch condiviso causa danni reali. ...

docker build && docker push dal tuo portatile funziona finché qualcun altro non deve pubblicare la stessa immagine, oppure finché non deve succedere a ogni merge senza che tu sia davanti alla tastiera. GitHub Actions esegue quella build sui runner di GitHub, tagga l’immagine in base a cosa ha scatenato il workflow e la pubblica su un registry da cui il tuo step di deploy può fare il pull. Niente gira in locale. ...

Esegui kubectl run nginx --image=nginx:1.27 e Kubernetes crea esattamente un Pod di nome nginx. Cancellalo con kubectl delete pod nginx e sparisce per sempre — nessuno se ne accorge, nessuno lo sostituisce. Un Pod è l’unità minima distribuibile in Kubernetes: uno o più container che condividono un namespace di rete e un insieme di volumi, schedulati insieme su un singolo nodo. Quel Pod isolato è un vicolo cieco in produzione. Se il container al suo interno crasha, il kubelet lo riavvia sul posto. Se il nodo si riavvia, o qualcuno cancella il Pod, nulla lo ricrea. Di un Pod nudo, nessuno si ricorda che dovrebbe esistere. ...