Concetti chiave
Last updated
Last updated
La documentazione ufficiale di Terraform descrive Leggila attentamente per capire il resto della sezione.
Questa sezione descrive i concetti chiave che sono usati nel libro.
Una risorsa è aws_vpc, aws_db_instance, ecc. Una risorsa appartiene a un provider, accetta argomenti, fornisce output, attributi e ha un ciclo di vita. Una risorsa può essere creata, recuperata, aggiornata e cancellata.
Un modulo di risorsa è una collezione di risorse che insieme eseguono un'azione comune (per esempio crea VPC, subnets, NAT gateway, ecc). Dipende dalla configurazione del provider, che può essere definito dentro il modulo oppure a un livello più alto della struttura (per esempio, in un modulo di infrastruttura).
Un modulo di infrastruttura è una collezione di moduli risorsa, che possono non essere logicamente connessi, ma nella situazione/progetto/setup servono lo stesso scopo. Definisce la configurazione per i providers, che è passata ai moduli risorsa e alle risorse nei moduli sottostanti. Normalmente è limitata al lavoro di una entità per separatore logico (per esempio, AWS Region, Google Project).
Per esempio, il modulo usa moduli risorse come e per amministrare l'infrastruttura richiesta per far girare su .
Un altro esempio è un modulo, dove moduli multipli di sono usati insieme per amministrare l'infrastruttura, cosí come le risorse Docker usano i comandi build, push, e deploy per le immagini Docker.
La Composizione è una collezione di moduli infrastruttura, che possono espandersi tra diverse aree separate (per esempio, AWS Regions, diversi accounts AWS ).
La Composizione è usata per descrivere un'infrastruttura completa richiesta per l'intera organizzazione o progetto.
Una composizione consiste di moduli infrastruttura, che consistono di moduli risorsa, che implementano risorse individuali.
Data source esegue una operazione di sola lettura ed è dipendente dalla configurazione del provider, viene usato in un modulo risorsa e in un modulo infrastruttura.
Il Data source terraform_remote_state agisce come colla per moduli di alto livello e composizioni.
Providers, provisioners, e pochi altri termini sono ben descritti nella documentazione ufficiale e sarebbe inutile ripeterli qui. Secondo me hanno poco a che fare con lo scrivere dei buoni moduli Terraform.
L'accesso ai dati tra le molecole (moduli risorsa e moduli infrastruttura) viene eseguito usando output dei moduli e il data sources.
Quando mettiamo in pratica i concetti descritti sopra una pseudo-relazione potrebbe apparire in questo modo:
Il data source permette a un programma di agire come un data source, esponendo dati arbitrari ad essere usati in qualche altra parte delle configurazione Terraform. Un esempio dal modulo dove il nome del file è calcolato chiamando un script python esterno.
Il data source fa delle chiamate HTTP GET a un dato URL e esporta le informazioni sulle risposte, questo metodo è spesso usato per prendere le informazioni da endpoint dove un provider Terraform nativo non esiste.
Moduli di infrastruttura e composizioni dovrebbero persistere in uno in una posizione remota dove possono essere recuperate da altri in maniera controllata (per esempio, specificando ACL, versionamento e con attivitá di log).
Mentre le risorse individuali sono come gli atomi nell'infrastruttura, i moduli di risorse sono come molecole. Un modulo è la più piccola unitá che si possa versionare e condividere. Ha una lista esatta di argomenti, implementa logiche di base per fare in modo che l'unitá esegua le funzionalitá richieste. Per esempio il modulo crea le risorse aws_security_group e aws_security_group_rule basandosi sul suo input. Questo modulo di risorse da solo puó essere usato insieme ad altri moduli per create moduli di infrastruttura.
L'accesso ai dati tra le composizioni viene spesso effettuato usando il data source di tipo remote state. Ci sono
