La terraforma destroy
è necessaria prima di Terraform apply
? In caso contrario, qual è il flusso di lavoro che segui quando aggiorni l'infrastruttura esistente e come decidi se è necessario lo destroy
?La terraform distrugge prima che sia applicata la terraforma?
risposta
Questo sarebbe piuttosto non standard, a mio parere. Terraform destroy
viene utilizzato solo nei casi in cui si desidera cancellare completamente l'infrastruttura. Una delle maggiori caratteristiche di terraform è che può fare un delta intelligente dell'infrastruttura desiderata e dell'infrastruttura esistente e apportare solo le modifiche necessarie. Eseguendo un refresh
, plan
e apply
è possibile garantire che Terraform:
refresh
- ha una comprensione up-to-date la propria infrastruttura corrente. Questo è importante nel caso in cui qualcosa è stato modificato manualmente, al di fuori del tuo script terraform.plan
- Prepara una lista per la revisione di ciò che terraform intende modificare o eliminare (o lasciare da solo).apply
- Esegue le modifiche previste nel piano.
Eseguendo questi 3 comandi in sequenza terraform eseguirà solo le modifiche necessarie, nell'ordine richiesto, per allineare gli ambienti con eventuali modifiche al file terraform.
Dove trovo che distruggere sia utile è in ambienti non di produzione o nei casi in cui si sta eseguendo una ristrutturazione così invasiva che partendo da zero garantirebbe una build più sicura.
* Ci sono anche casi limite in cui terraforme potrebbe non riuscire a capire l'ordine corretto delle operazioni (devo modificare prima un gruppo di sicurezza o una regola del gruppo di sicurezza?), O si troverà in un ciclo di dipendenze e non sarà in grado per eseguire un'operazione. In questi casi, tuttavia, l'esecuzione di distruggere è una soluzione nucleare. In generale, eseguirò il problema manualmente (tramite riga di comando o Console AWS, se sono in AWS), per spostarlo e quindi eseguire una sequenza refresh
, plan
, apply
per tornare in linea.
Altri commenti dopo la risposta di @ mwielbut.
Invece di opzione apply
+ destroy
, è necessario eseguire terraform
con l'opzione taint
+ apply
Normalmente non abbiamo bisogno di correre terraform destroy
a tutti. È un'opzione davvero pericolosa, soprattutto per un ambiente di produzione.
con l'opzione plan
e apply
, è sufficiente aggiornare l'infrastruttura con il codice.
Ma se hai bisogno di distruggere alcune risorse e ricostruire qualcosa che è già stato creato, puoi usare l'opzione taint
, che è la risposta giusta per la tua domanda, è così importante e mancata nella risposta di @ mwielbut .
Il comando di contaminazione terraform segna manualmente una risorsa gestita da Terraform come macchiata, forzandola a essere distrutta e ricreata alla successiva domanda.
Questo comando non modificherà l'infrastruttura ma modifica il file di stato per contrassegnare una risorsa come contaminata. Una volta che una risorsa è contrassegnata come contaminata, il prossimo piano mostrerà che la risorsa verrà distrutta e ricreata e la prossima applicazione implementerà questa modifica.
consultare:
comando taint: https://www.terraform.io/docs/commands/taint.html
un campione di un'opzione taint
: https://www.terraform.io/docs/modules/usage.html
Si può sempre distruggere manualmente le istanze, dopo solo esegue il terraform apply
. Quindi quando si esegue terraform apply
verranno create nuove istanze senza lo terraform destroy
.
No terraform destroy
non necessario prima terraform apply
.
La configurazione di Terraform (*.tf
e *.tfvars
) descrive lo stato desiderato dell'infrastruttura. Dice "questo è il modo in cui voglio che la mia infrastruttura sia".
Si utilizza lo strumento terraform
per pianificare e applicare le modifiche per portare l'infrastruttura nello stato desiderato che si è descritto. È possibile apportare queste modifiche in modo incrementale senza distruggere nulla.
Un flusso di lavoro tipico potrebbe essere:
- apportare modifiche al
.tf
e.tfvars
file - aggiornamento di stato
- piano cambia
- revisione dei cambiamenti previsti
- applicare tali modifiche
Se volessi distruggere completamente quell'infrastruttura, useresti terraform plan -destroy
per vedere cosa intende distruggere Terraform. Se sei soddisfatto, usa terraform destroy
per distruggerlo.
In genere, destroy
viene utilizzato raramente, a meno che non si esegua il provisioning dell'infrastruttura per uno scopo temporaneo (ad es. Build) o si verifichi la possibilità di eseguire il provisioning da una lavagna pulita con parametri diversi. Anche in questo caso, è possibile utilizzare un parametro count
sulle risorse per eseguire temporaneamente il provisioning delle risorse aumentando il conteggio, quindi diminuendolo nuovamente quando non è più necessario.
Terraform destroy distrugge tutte le risorse e non è necessario se si desidera applicare modifiche incrementali. Destroy deve essere utilizzato solo se si desidera distruggere l'intera infrastruttura.
Uno può (o dovrebbe) anche indirizzare un modulo e non l'intera infrastruttura mentre si usa 'destroy' Qualcosa come questo. 'terraform destroy -target = module.
Non conoscevo il comando di aggiornamento ... Grazie per la bella spiegazione del flusso;] –
Quando rivedi i tuoi script di terraform e l'ambiente, scoprirai che se continui a utilizzare destroy, si verificano alcune implicite implicazioni. Ad esempio, a meno che non elimini in modo esplicito i volumi su destroy in AWS e crei istanze, lasceranno dei volumi indietro. Mentre i volumi si trovano in AWS, ti vengono addebitati. – DrM
Terraform è progettato per gestire lo stato, distrugge solo le cose se necessario per ottenere la nuova configurazione. Pianifica automaticamente l'aggiornamento dei dati, mostra le modifiche ed è possibile eseguirlo tutte le volte che vuoi. Il sommario, ovunque indichi che "le forze cambiano" si riferisce a te che qualcosa che stai facendo farà sì che le cose vengano ricreate invece che modificate. Ho faticato e imparato che i documenti non trasmettono tutte queste informazioni, ma la ricerca di gil e problemi su GitHub mi ha aiutato a trovare soluzioni che non erano presenti nei documenti, incluso il motivo per cui qualcosa non ti aspetti di forzare un cambiamento . – DrM