Chiedi a un LLM generico qual è la politica di reso della tua azienda o cosa dicono i ticket di supporto della settimana scorsa, e otterrai o un “non lo so” o una risposta inventata ma plausibile. La sua conoscenza si ferma a quello che c’era nei dati di addestramento. Non ha mai visto i tuoi documenti e non può andare a cercarli a metà conversazione. La retrieval-augmented generation (RAG) risolve proprio questo: prima che il modello risponda, un passaggio separato trova il testo rilevante nei tuoi dati e lo passa al modello come parte del prompt. ...

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

Cosa fa Docker in concreto Docker è una piattaforma open source che impacchetta un’applicazione con tutto ciò che le serve per funzionare — codice, librerie, runtime, configurazione — in un container che si comporta allo stesso modo su qualsiasi macchina. Il trasloco rende concreto il compromesso. Hai due opzioni: Portare tutti i tuoi oggetti sfusi, sperando che arrivino intatti Mettere tutto in scatole organizzate, etichettate e facili da spostare Docker fa esattamente questo con le applicazioni software: le “impacchetta” in container che contengono tutto il necessario per funzionare. ...

Cosa fa Kubernetes Un container Docker su una sola macchina lo gestisci a mano senza problemi. Cinquanta container su dieci macchine — riavviarli quando crashano, spostarli quando una macchina muore, ripartire il traffico tra loro, aggiornarli senza downtime — no. Kubernetes (abbreviato in K8s) è il sistema che se ne occupa al posto tuo. Cos’è Kubernetes? Kubernetes è una piattaforma open source per l’orchestrazione di container. È stato creato da Google nel 2014 basandosi su 15 anni di esperienza nella gestione di container su larga scala, ed è ora mantenuto dalla Cloud Native Computing Foundation (CNCF). ...