Perché Maison Code ne parla

In Maison Code Paris, agiamo come la coscienza architettonica dei nostri clienti. Spesso ereditiamo stack “moderni” costruiti senza una comprensione fondamentale della scala.

Discutiamo di questo argomento perché rappresenta un punto di svolta critico nella maturità ingegneristica. Implementarlo correttamente differenzia un MVP fragile da una piattaforma resiliente di livello aziendale.

Il server “Snowflake” e il disastro di ClickOps

Ai vecchi tempi della cultura SysAdmin, un server era un animale domestico. L’hai chiamato “Gandalf” o “Zeus”. Uno sviluppatore dovrebbe accedere tramite SSH al server, eseguire apt-get install nginx, modificare un file di configurazione utilizzando vi, riavviare il servizio e magari modificare un parametro del kernel (sysctl.conf) per ottimizzare il throughput della rete. Lo farebbero per 5 anni. Il server è diventato un Fiocco di neve. Unico. Bellissimo. Fragile. Se “Gandalf” moriva (guasto hardware), ne seguiva il panico. “Come lo ricostruiamo?” “Non lo so, Bob l’ha fondata nel 2018 e ha lasciato l’azienda.” “Qual era la configurazione?” “Era sul disco rigido che è appena bruciato.” Si tratta di ClickOps (configurazione tramite console/GUI) e amministrazione manuale. È un disastro in attesa di accadere. Nell’era del cloud, i server sono bestiame, non animali domestici. Li chiami “web-worker-01”, “web-worker-02”. Se uno si ammala, gli spari e ne generi uno nuovo. Infrastructure as Code (IaC) è la metodologia che consente tutto ciò. Definisci la tua infrastruttura in file di testo (.tf). Li impegni su Git. Li rivedi. Li applichi utilizzando una CLI. La macchina costruisce il server. Idealmente, nessun essere umano entrerà mai più in una macchina tramite SSH.

Perché Maison Code parla di Terraform

Noi di Maison Code gestiamo l’infrastruttura per molteplici clienti in forte crescita. Un cliente gestisce le vendite flash (picchi di traffico 100x). Un altro gestisce i dati medici (conformità HIPAA, crittografia rigorosa). Non possiamo fare affidamento sulla memoria umana per garantire che questi ambienti siano corretti. “Ho abilitato la crittografia su quel bucket S3?” Se ti affidi alla memoria, la risposta è “Forse”. Usiamo Terraform per garantire che la risposta sia “Sì, è nella riga 42 di storage.tf”. Costruiamo Moduli riutilizzabili. Disponiamo di un modulo standard “Maison Code Safe Bucket” che applica crittografia, registrazione e controllo delle versioni. Lo usiamo per ogni cliente. Ciò garantisce la standardizzazione e la sicurezza su larga scala. Non risolviamo lo stesso problema due volte. Lo risolviamo una volta in Terraform e lo distribuiamo ovunque.

Lo strumento: HashiCorp Terraform

Terraform è il gold standard perché è Cloud Agnostic. Puoi usarlo per gestire AWS, Google Cloud, Azure, Cloudflare, GitHub e persino il tuo ordine di Domino’s Pizza (sì, c’è un fornitore). Confrontalo con CloudFormation (solo AWS) o ARM Templates (solo Azure). Imparare Terraform ti dà un superpotere in tutto il settore. Utilizza HCL (HashiCorp Configuration Language). È dichiarativo. Descrivi la destinazione, non il viaggio. “Voglio 5 server.” (Terraform capisce come passare da 2 a 5). Invece di “Crea 3 server”. (Imperativo).

Esempio: creazione di un bucket S3

fornitore "aws" {
  regione = "noi-est-1"
}

risorsa "aws_s3_bucket" "risorse" {
  bucket = "maison-code-assets-prod"
  
  tag = {
    Ambiente = "Produzione"
    Progetto = "Maison"
    ManagedBy = "Terraforma"
  }
}

risorsa "aws_s3_bucket_public_access_block" "blocco" {
  bucket = aws_s3_bucket.assets.id
  
  block_public_acls = vero
  block_public_policy = vero
  ignore_public_acls = vero
  restring_public_buckets = vero
}

risorsa "aws_s3_bucket_versioning" "versioning" {
  bucket = aws_s3_bucket.assets.id
  versione_configurazione {
    stato = "Abilitato"
  }
}

Questo codice è Documentazione. Chiunque lo legga sa: “Abbiamo un bucket. È esplicitamente privato. Il controllo delle versioni è abilitato (quindi possiamo recuperare i file eliminati).” Questo è meglio di un documento Word di 50 pagine che descrive la configurazione del server (che è sempre obsoleto).

Il file di stato: il cervello di Terraform

Terraform tiene traccia di ciò che ha creato in un file chiamato “terraform.tfstate”. Si tratta di un file JSON che mappa le risorse del codice (“resource “aws_instance” “app”) a identificatori reali (i-0a1b2c3d4e5f`). Stato attuale vs Stato desiderato. Quando esegui “terraform plan”, Terraform:

Legge il tuo codice (stato desiderato).
Legge il file di stato (ultimo stato noto).
Aggiorna lo stato (controlla le API AWS per vedere se le cose sono cambiate).
Calcola il “Delta” (Diff). Quindi ti dice: “Ho intenzione di aggiungere 1 risorsa, modificare 2 risorse e distruggere 0 risorse”. Pericolo: il file di stato contiene segreti (password, chiavi private) in testo semplice. Best Practice: non eseguire mai il commit di terraform.tfstate su Git. Utilizza un backend remoto. Archivia lo stato in un bucket S3 con la crittografia lato server abilitata. Utilizza una tabella DynamoDB per il Blocco dello stato. Ciò impedisce a due sviluppatori di eseguire “terraform apply” contemporaneamente e di corrompere lo stato.

Moduli: Il principio NON RIPETIRTI (ASCIUTTO).

Se copi e incolli il blocco “aws_instance” 10 volte per 10 server, stai sbagliando. Crea un Modulo.

Definizione del modulo (modules/web-server/main.tf):

variabile "dimensione" { 
  tipo = stringa
  predefinito = "t2.micro" 
}
variabile "nome" { tipo = stringa }

risorsa "aws_instance" "app" {
  ami = "ami-12345678"
  tipo_istanza = dimensione_var
  tag = {
    Nome = nome.var
  }
}

Utilizzo (main.tf):

modulo "frontend" {
  sorgente = "./modules/server web"
  dimensione = "t3.piccolo"
  nome = "Frontend-01"
}

modulo "backend" {
  sorgente = "./modules/server web"
  dimensione = "m5.grande"
  nome = "API backend"
}

Se decidi di modificare l’ID AMI (aggiorna la versione di Ubuntu), lo cambi in un posto (il modulo) e aggiorna tutti i server.

Rilevamento della deriva: il controllo della realtà

Cosa succede se uno sviluppatore non autorizzato accede alla console AWS e modifica manualmente il gruppo di sicurezza per aprire la porta 22 (SSH) al mondo? Questa è la deriva della configurazione. La Realtà non corrisponde più al Codice. La prossima volta che esegui “terraform plan”, Terraform lo vedrà. “Output: regola di ingresso del gruppo di sicurezza modificata dalla porta 22 (0.0.0.0/0) a NULL.” Proporrà di riparare l’ambiente riportandolo allo stato definito nel codice. Ciò impone la disciplina. Le modifiche “ClickOps” sono temporanee e verranno cancellate dalla successiva distribuzione.

Aree di lavoro Terraform: multiambiente

Hai bisogno di sviluppo, staging e produzione. Non replicare le strutture delle cartelle (/dev, /prod). Utilizza Aree di lavoro. “Nuova messa in scena dello spazio di lavoro Terraform”. “Area di lavoro Terraform, nuovo prodotto”. Utilizzi gli stessi file .tf, ma file di stato diversi (terraform.tfstate.d/staging, terraform.tfstate.d/prod). Nel tuo codice, puoi usare la logica: count = terraform.workspace == "prod"? 5:1. Prod ottiene 5 server. Dev ottiene 1.

Politica come codice (Sentinel/OPA)

Nelle grandi organizzazioni, si vuole evitare che gli sviluppatori commettano errori. “Nessuno può creare un bucket S3 pubblico.” “Nessuno può effettuare il provisioning di un’istanza più grande di large (troppo costosa).” Puoi utilizzare Open Policy Agent (OPA) o HashiCorp Sentinel. Viene eseguito prima di “terraform apply”. Se il piano viola la policy, ne blocca l’implementazione. Questa è la Governance automatizzata.

Il punto di vista dello scettico

“È troppo standard. Posso semplicemente fare clic sul pulsante più velocemente.” Contropunto: Fare clic è più veloce una volta. Ma devi mantenerlo per sempre. Se è necessario replicare l’ambiente in un’altra regione (Disaster Recovery), fare clic richiede giorni ed è soggetto a errori. Terraform richiede pochi minuti (region = "eu-west-1"). Inoltre, “ClickOps” non può essere sottoposto a revisione del codice. Non è possibile aprire una richiesta pull con un clic del mouse. Non è possibile ripristinare un clic del mouse (facilmente). Il codice è verificabilità. Il codice è sanità mentale.

Domande frequenti

D: Terraform vs Ansible? R: Terraform fornisce l’infrastruttura (l’hardware: VPC, EC2, RDS). Ansible configura il software (il software: Apache, MySQL Config, Utenti). Nel moderno mondo delle “Infrastrutture immutabili” (Docker), Ansible è meno necessario. Inseriamo il software nell’immagine Docker. Terraform distribuisce il servizio contenitore (ECS/EKS). Utilizza Terraform per il cloud. Utilizza Ansible per il sistema operativo (se non utilizzi i contenitori).

D: Cos’è main.tf, variables.tf, outputs.tf? R: È una convenzione. Terraform legge tutti i file “.tf” nella directory.

main.tf: le risorse.
variables.tf: argomenti di input.
outputs.tf: cosa stampare alla fine (ad esempio, URL del bilanciatore di carico).

D: Azioni Terraform Cloud e Jenkins/GitHub? R: Terraform Cloud offre funzionalità interessanti:

Gestione remota dello stato (integrata).
Registro dei moduli privati.
Stima dei costi (“Questa modifica aumenterà la fattura di € 50”). Tuttavia, puoi eseguire la CLI Terraform all’interno di GitHub Actions utilizzando un backend S3 gratuitamente. Terraform Cloud è a pagamento (per utente). Di solito iniziamo con GitHub Actions e aggiorniamo se necessario.

Conclusione

Infrastructure as Code trasforma “Ops” in “Dev”. Porta la disciplina dell’ingegneria del software (controllo della versione, revisione del codice, test, CI/CD) nel mondo dell’hardware. Se non è in Git, non esiste. Smettila di costruire fiocchi di neve. Inizia a costruire i Lego.

Fare clic manualmente sui pulsanti?

Se la tua infrastruttura è un delicato fiocco di neve che hai paura di toccare, Maison Code può terraformarla. Effettuiamo il reverse engineering della configurazione “ClickOps” esistente e la codifichiamo in moduli Terraform robusti e riutilizzabili. Implementiamo flussi di lavoro State Locking, Drift Detection e Disaster Recovery.

Assumi i nostri architetti.