Nell'ultima parte di questa serie abbiamo mostrato come fonti dati apparentemente innocue all'interno di moduli Terraform possano trasformarsi in un serio problema di performance. Esecuzioni di terraform plan della durata di diversi minuti, pipeline instabili ed effetti di throttling delle API fuori controllo sono state le conseguenze.
Ma come si può evitare elegantemente e in modo sostenibile questa trappola di scalabilità?
In questa parte presentiamo pattern architetturali collaudati con cui centralizzare le Data Sources, iniettarle in modo efficiente dal punto di vista delle risorse e ottenere così esecuzioni Terraform rapide, stabili e prevedibili, anche con centinaia di istanze di moduli.
Inclusi: tre strategie scalabili, una guida passo-passo collaudata nella pratica e una checklist di Best Practices per moduli infrastrutturali pronti per la produzione.
Leggi tutto: Terraform @ Scale - Parte 4b: Best Practices per Data Sources scalabili
Le Data Sources di Terraform sono uno strumento molto usato per popolare dinamicamente le variabili con valori reali dell'ambiente cloud in uso. Tuttavia, il loro utilizzo in infrastrutture dinamiche richiede una certa lungimiranza. Basta ad esempio un innocuo data.oci_identity_availability_domains all'interno di un modulo - e all’improvviso ogni terraform plan impiega minuti anziché secondi. Perché 100 istanze del modulo significano 100 chiamate API, e il suo provider cloud inizia a limitare il traffico (throttling). Benvenuti nel mondo dell’amplificazione API indesiderata attraverso le Data Sources.
In questo articolo Le mostrerò perché le Data Sources nei moduli Terraform possono rappresentare un problema di scalabilità.
Leggi tutto: Terraform @ Scale - Parte 4a: le Data Sources sono pericolose!
Neanche l’architettura infrastrutturale più sofisticata può prevenire ogni errore. È quindi fondamentale monitorare in modo proattivo le operazioni Terraform - in particolare quelle che potrebbero avere effetti distruttivi. L’obiettivo è rilevare tempestivamente modifiche critiche e attivare automaticamente degli allarmi, prima che si verifichi un raggio d’azione incontrollato.
Certo – il suo System Engineer Le farà sicuramente notare che Terraform mostra l’intero piano prima dell’esecuzione di un apply e che tale esecuzione deve essere approvata manualmente digitando "yes".
Quello che però il suo Engineer non Le dice: in realtà non legge mai davvero il piano prima di eseguirlo.
«Andrà tutto bene.»
Leggi tutto: Terraform @ Scale - Parte 3c: Monitoraggio e allerta per eventi di Blast Radius
La Key/Value Secrets Engine è parte integrante di quasi ogni implementazione di Vault. Costituisce la base per la memorizzazione sicura di secrets statici ed è, nella pratica, utilizzata molto più frequentemente rispetto a molte engine dinamiche.
Dopo l’introduzione teorica nella parte 2a, in questo articolo ci dedichiamo al lavoro concreto con la KV Engine. Mostriamo come scrivere, leggere, aggiornare e cancellare secrets, analizzando in modo pratico le differenze tra la versione 1 e la versione 2 di KV. Il focus è sui comandi rilevanti per la produzione, sugli ostacoli realistici e su raccomandazioni concrete per l’operatività quotidiana, motivo per cui vi trasmetto queste conoscenze come una combinazione di tutorial e cheat-sheet.
Leggi tutto: HashiCorp Vault Deep Dive – Parte 2b: Lavoro pratico con la Key/Value Secrets Engine
Nonostante un'attenta minimizzazione del blast radius, la segmentazione degli state e l’uso di lifecycle guardrails, può prima o poi succedere: un terraform apply elimina per errore risorse produttive - oppure un terraform destroy colpisce più di quanto previsto.
Cosa fare quando il danno è ormai fatto?
Nell’ultimo articolo di questa serie ho spiegato come minimizzare il blast radius. In questa continuazione mostro tecniche comprovate per il ripristino di Terraform State danneggiati e per la limitazione dei danni dopo un incidente.
Leggi tutto: Terraform @Scale - Parte 3b: Strategie di recupero dal Blast Radius
