DevOps

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

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