Docker

Ogni chiamata a un’API LLM ospitata manda il tuo prompt sul server di qualcun altro e ti fattura per token. Se perdi la connessione di rete, smette di rispondere. Ollama toglie di mezzo entrambi i problemi: scarica un modello open-weight sulla tua macchina e lo serve tramite un’API REST su localhost:11434. Un solo binario fa da gestore dei modelli, client di chat e server. Cosa fa davvero Ollama Ollama avvolge llama.cpp e motori di inferenza simili, così non devi mai toccare un flag del compilatore o un percorso di libreria CUDA. ollama pull llama3.2 scarica un file di modello quantizzato (formato GGUF) dal registro di Ollama invece che da Hugging Face, anche se può importare file GGUF anche da lì. Quando esegui il modello, quei pesi passano a un server in background: li carica in RAM (o in VRAM, se trova una GPU compatibile), li tiene residenti per qualche minuto dopo l’ultima richiesta così la successiva è veloce, e li scarica non appena smetti di fare domande. ...

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

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

Perché un container perde i dati quando si riavvia Scrivi una riga su un database in esecuzione in un container Docker, fermi il container, lo riavvii: la riga non c’è più. Ogni container riceve il suo filesystem dall’immagine, nuovo, a ogni avvio. Tutto ciò che il container scrive — file del database, upload, log — finisce in uno strato scrivibile che viene buttato via quando il container viene rimosso. Un volume Docker è il modo per tenere quei dati fuori dal container, dove sopravvivono. ...

Docker e Podman eseguono le stesse immagini con gli stessi comandi. A separarli è l’architettura: Podman non ha un daemon in background e gira rootless di default, mentre Docker porta con sé strumenti più maturi, Docker Desktop e un supporto a Compose di prima classe. Qui sotto, le differenze che incidono davvero sul tuo lavoro: daemon, root, Compose e pod. Cos’è Podman? Podman (Pod Manager) è uno strumento per gestire container e pod, sviluppato da Red Hat come alternativa open source a Docker. La sua caratteristica principale? Non ha bisogno di un daemon in esecuzione. ...