Da Docker Compose su una VM a Kubernetes con Talos OS: come abbiamo rifatto il nostro ambiente di sviluppo

Il punto di partenza: una VM, Docker Compose, e tanta buona volontà

Per anni il nostro ambiente di sviluppo interno è vissuto su una singola macchina virtuale, robusta sulla carta ma sempre più stanca nei fatti. Sopra ci girava Docker, e tutto — dico tutto — partiva via docker compose up -d dentro le cartelle dei vari progetti. Funzionava. Ha funzionato per un bel pezzo, in effetti.

Poi i progetti sono cresciuti. LoginMaster, Data Alchemy, Jarvis, più una pletora di servizi accessori: gateway, database di sviluppo, broker, motori di parsing, frontend in vari stadi di rifattorizzazione. A regime ci ritrovavamo con circa 60 container attivi contemporaneamente, con picchi di 80 quando qualcuno faceva il branch di una feature pesante o stava testando un nuovo microservizio.

E qui è iniziato il problema.

I sintomi del decadimento

Chi ha vissuto un ambiente del genere li riconosce subito. I segnali sono sempre gli stessi:

• Immagini obsolete che si accumulavano come polvere. Ogni rebuild lasciava dietro layer dangling, immagini taggate <none>, vecchie versioni che nessuno aveva il coraggio di cancellare “perché magari serve”. Un docker system prune settimanale era diventato rituale, ma non bastava: gli sviluppatori facevano build durante la giornata e la VM si riempiva comunque.
• Risorse mangiate senza criterio. Nessun limite serio per container, nessun QoS. Bastava un container Java un po' permaloso o un parser che andava in loop e il resto rallentava. La parola “noisy neighbor” l'abbiamo imparata a furia di prenderla sui denti.
• Ambiente confuso. Network Docker che si moltiplicavano, volumi orfani, porte mappate a caso sull'host per evitare collisioni, file docker-compose.override.yml con configurazioni personali di ciascuno. Onboarding di un nuovo collega: due giorni buoni di “ma a me non parte”.
• Zero parità con la produzione. La nostra produzione gira su Scaleway, su Kubernetes managed, con tutto quello che ne consegue: HPA, network policy, secret nativi, ingress controller, observability. In sviluppo invece avevamo Docker Compose e basta. Il classico “sulla mia VM funziona” che diventa “in produzione no”.

Il punto non è che Docker Compose sia uno strumento sbagliato — è ottimo per quello per cui è nato. Il punto è che lo stavamo usando per fare il lavoro di un orchestratore, e a un certo punto il giocattolo si rompe.

Kubernetes in casa, allineato alla produzione

La produzione è su Scaleway (e ne siamo molto soddisfatti — un provider europeo ci dà garanzie di sovranità del dato che con gli hyperscaler americani semplicemente non si ottengono, e per i nostri clienti enterprise italiani è un argomento che pesa). Volevamo però un cluster di sviluppo on-premise, integrato con il nostro vSphere esistente e con gli storage che avevamo già in casa.

Tre requisiti non negoziabili:

1. Allineamento con la produzione: stesse API, stessi manifest, stessi pattern operativi.
2. Autoscaling vero: sia a livello di pod (HPA) che a livello di nodi (cluster autoscaler che spinge nuove VM su vSphere quando serve).
3. Manutenzione minima: non volevamo un altro mestiere a tempo pieno. Il team è di una decina di persone, non possiamo permetterci un sysadmin Kubernetes dedicato.

Da qui la scelta di Talos OS come sistema operativo dei nodi.

Perché Talos

Talos è un Linux minimale, immutabile, pensato esclusivamente per far girare Kubernetes. Niente shell, niente SSH, niente pacchetti da aggiornare a mano. Tutta la configurazione passa via API gRPC e file YAML versionati. Per chi viene dal mondo “logghiamoci e sistemiamo a mano” è uno shock culturale; per chi ha già sofferto le conseguenze di quei “sistemiamo a mano”, è liberazione pura.

Vantaggi pratici che abbiamo toccato con mano:

• Superficie d'attacco minima. Nessun servizio in più, nessuna porta aperta che non serva.
• Upgrade dichiarativi. Si aggiorna un campo nel config, si applica, il nodo si reinstalla. Stop.
• Boot rapido. Una VM Talos è pronta in pochi secondi, il che è fondamentale quando il cluster autoscaler deve aggiungere capacità.
• Cattiveria zero con vSphere. Gli OVA ufficiali Talos si importano in vSphere senza giri strani, e l'integrazione con il cloud provider vSphere di Kubernetes funziona out of the box.

L'integrazione con vSphere

Il cluster è esposto a vSphere in modo nativo grazie al vsphere-cloud-provider e al vsphere-csi-driver. Questo significa due cose:

• Storage persistente reale. I PersistentVolumeClaim si trasformano automaticamente in VMDK sui nostri datastore. Niente più bind mount su path che variavano da macchina a macchina. Storage class diverse per workload diversi: SSD per i database di sviluppo, capacity HDD per i log e gli artefatti di build.
• Autoscaling dei nodi. Quando l'HPA scala i pod e i nodi esistenti non bastano, il cluster autoscaler dialoga con vSphere e tira su una nuova VM Talos già configurata per joinare il cluster. Quando il carico cala, le VM in eccesso vengono spente e rimosse. Il tutto senza che nessuno apra la console vSphere.

Per chi viene dal mondo Compose questo è il punto in cui scatta il “ah, ecco la differenza”. Non è più “ho una macchina, la riempio finché regge”. È “ho un pool elastico di capacità, e Kubernetes la usa come gli serve”.

Come è cambiato il lavoro degli sviluppatori

Una precisazione importante, perché spesso quando si parla di Kubernetes si pensa che gli sviluppatori debbano imparare un mestiere nuovo: non è cambiato granché per loro, a livello locale.

Sulla macchina di ogni sviluppatore, per ogni progetto, c'è ancora il suo bravo docker-compose.yml con il suo bravo .env. Quando lavori su una feature, alzi i servizi che ti servono, fai il tuo loop di sviluppo, committi. Questo non lo abbiamo toccato perché funziona benissimo per il ciclo rapido di chi scrive codice. Non c'è motivo di costringere uno sviluppatore frontend a scrivere manifest Kubernetes per girare un Vite dev server.

Il salto avviene a partire dall'ambiente di dev integrato, quello condiviso, quello su cui giravano i 60–80 container. Lì siamo passati al cluster Talos, e con questo è cambiato come gestiamo configurazione e segreti:

• Niente più file .env taggati su una VM condivisa. Tutte le credenziali di sviluppo vivono in Secret Kubernetes, sincronizzati con un vault e ruotabili senza dover rifare il deploy a mano.
• ConfigMap per la configurazione non sensibile. Endpoint, feature flag, parametri di tuning: tutto versionato, tutto rivedibile in pull request.
• Namespace per progetto e per branch. Ogni feature branch importante può avere il suo namespace effimero, con il suo subset di servizi, isolato dagli altri. Quando il branch viene mergiato o chiuso, il namespace viene distrutto e con lui tutte le sue risorse. Addio container fantasma.
• Manifest identici alla produzione. Stesso Helm chart, stessi valori di base, solo override per ambiente. Quando una cosa funziona in dev, ha probabilità altissime di funzionare in produzione su Scaleway. E quando non funziona in produzione, riusciamo a riprodurre il problema in dev senza inventare nulla.

Vantaggi concreti

Provo a riassumere senza romanticismi, perché il “prima era peggio” è facile ed i numeri sono più onesti:

Concludendo...

Tre cose, da portarsi a casa se siete nella situazione in cui eravamo noi sei mesi fa.

Primo: Docker Compose non è il nemico. Il nemico è usarlo per un lavoro che non è il suo. Per il loop di sviluppo locale rimane perfetto, e non abbiamo nessuna intenzione di toglierlo agli sviluppatori. È quando lo si usa come orchestratore di un ambiente condiviso con decine di servizi che inizia a scricchiolare.

Secondo: scegliere bene il sistema operativo dei nodi cambia la vita. Talos OS ci ha tolto un'intera categoria di problemi — quelli del “qualcuno ha fatto qualcosa sul nodo e nessuno sa cosa”. L'immutabilità non è una moda, è igiene operativa.

Terzo: l'allineamento dev/prod si paga adesso o si paga dopo. Avere lo stesso orchestratore in sviluppo e in produzione costa qualcosa in setup iniziale. Non averlo costa molto di più, tutti i giorni, in bug strani, deploy ansiogeni e fiducia erosa nel processo.

Se anche voi state guardando il vostro docker compose ps con quella faccia un po' rassegnata, sappiate che si può uscire. E si può farlo senza vendere l'anima a un hyperscaler americano.

P.s. Grazie Claude per avermi aiutato nella stesura di questo articolo, hai trasformato 1 pagina scritta a mano in un articolo strutturato.