DevOps

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

Dove finiscono le variabili d’ambiente di un container Avvia un container con -e DB_PASSWORD=hunter2 ed esegui docker inspect sul container appena avviato: 1 2 docker run -d --name api -e DB_PASSWORD=hunter2 nginx:alpine docker inspect --format '{{json .Config.Env}}' api 1 ["DB_PASSWORD=hunter2","PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"] La password resta lì in chiaro, leggibile da chiunque abbia accesso al socket Docker, da docker exec api env e da qualsiasi processo in esecuzione dentro il container. Non è un bug: è esattamente a cosa servono le variabili d’ambiente. Il problema è usarle per valori che non dovrebbero mai essere così visibili. ...

Perché un’immagine Docker pesa dieci volte più dell’app Un servizio Node con poche centinaia di kilobyte di codice sorgente finisce in un’immagine da oltre 1 GB. È il risultato normale di una build che funziona, non un errore su una riga particolare. Il peso arriva da un’immagine base che porta con sé un intero sistema operativo, una toolchain di build che l’app in esecuzione non chiama mai, e una cache del package manager che nessuno ha detto alla build di cancellare. ...

Quanto costa un Dockerfile scritto male 1 2 3 4 5 6 FROM node:latest COPY . . RUN npm install CMD ["node", "server.js"] Quattro righe, e ognuna ti costa qualcosa. docker build riesegue npm install a ogni modifica al codice, perché COPY . . rompe la cache dei layer prima ancora che lo step di install possa essere riutilizzato. L’immagine finale porta con sé l’intera base Debian, l’intero albero di node_modules comprese le dipendenze di sviluppo e qualsiasi tool di build che npm install ha scaricato per compilare moduli nativi. Niente viene scartato. Il container gira come root, perché nulla gli dice di non farlo, e node:latest significa che l’immagine base può cambiare sotto di te tra una build e l’altra, senza che resti traccia di cosa hai effettivamente distribuito. ...

Il problema che Compose risolve Un’applicazione reale non è quasi mai fatta di un solo container. Un’API web ha bisogno di un database, il database ha bisogno di un volume perché i dati sopravvivano a un riavvio, e poi aggiungi una cache Redis e un worker in background. Sono quattro comandi docker run, ognuno con i suoi flag per porte, volumi, variabili d’ambiente e una rete condivisa. Nell’ordine giusto. Ogni volta che ti metti a lavorare. ...

Perché due container sullo stesso host non si vedono di default Avvia Postgres e la tua API con un semplice docker run e l’API non riesce a raggiungere il database, anche se entrambi i container girano sulla stessa macchina. 1 2 docker run -d --name db postgres:16 docker run -d --name api myapp Entrambi finiscono sulla bridge di default di Docker, quella su cui va a finire ogni container Docker se non specifichi altro. Ricevono un indirizzo IP. Quello che non ricevono è un modo per trovarsi a vicenda per nome: l’API dovrebbe quindi avere l’IP interno del database scritto a mano, un indirizzo che cambia ogni volta che il container riparte. ...