Il problema reale
Quando Terraform cresce oltre pochi moduli e pochi ambienti, i problemi non nascono dalla sintassi ma dalla gestione dello state. Lock non rilasciati, backend non protetti, modifiche manuali in portale e pipeline eseguite in parallelo rendono lo state una fonte di verità sempre meno affidabile.
Indicatori tipici
- Apply bloccati o forzati — se il team usa spesso
force-unlock, c'è un problema di processo o backend da risolvere. - Drift ricorrente — i plan mostrano ogni volta modifiche inattese perché qualcuno cambia risorse fuori Terraform o i moduli non rappresentano più la realtà.
- State condiviso troppo ampio — un solo state per molte risorse critiche aumenta blast radius e conflitti tra team.
- Secret gestiti male — output sensibili, variabili locali o pipeline poco segregate moltiplicano il rischio.
Quando non è un problema di lock
Se il plan è stabile ma i deploy falliscono solo a valle, il problema può stare nella pipeline, nei permessi cloud, in moduli difettosi o in dipendenze esterne non ancora pronte. Il locking va trattato come una spia, non come spiegazione unica.
Controlli utili da fare subito
- Verifica come viene gestito il backend remoto e chi può intervenire manualmente.
- Controlla se esistono apply paralleli sullo stesso state.
- Riduci il blast radius separando ambienti o domini funzionali.
- Confronta i drift ricorrenti con le modifiche manuali realmente avvenute.
Cosa migliorare
Serve un backend remoto robusto, separazione per ambiente o dominio funzionale, policy di review sui plan, pipeline serializzate dove necessario e una disciplina netta sulle modifiche manuali. L'obiettivo non è solo far girare Terraform, ma renderlo prevedibile e auditabile.
Errori che portano fuori strada
Il più frequente è usare spesso force-unlock come scorciatoia. Un altro errore è tenere uno state monolitico per comodità, salvo poi scoprire che ogni change tocca troppa superficie.
Domande frequenti
Il drift si elimina del tutto?
No, ma si può ridurre drasticamente quando ownership, backend e processo di apply sono coerenti.
Serve rifare tutti i moduli da zero?
Non necessariamente. Spesso il primo salto di qualità arriva da separazione dello state, review del processo e correzione dei punti più fragili.