Terraform Operations: Difference between revisions
(44 intermediate revisions by the same user not shown) | |||
Line 11: | Line 11: | ||
terraform --help | terraform --help | ||
terraform <''command''> --help | terraform <''command''> --help | ||
=Verbose Output and Debugging= | |||
{{External|https://www.terraform.io/docs/internals/debugging.html}} | |||
Set <code>TF_LOG</code> environment variable to one of: | |||
* <code>TRACE</code> | |||
* <code>DEBUG</code> | |||
* <code>INFO</code> | |||
* <code>WARN</code> | |||
* <code>ERROR</code> | |||
This will send debug output to stderr. | |||
To write to file, set <code>TF_LOG_PATH</code>. Note that even when <code>TF_LOG_PATH</code> is set, <code>TF_LOG</code> must be set in order for any logging to be enabled. | |||
=Logs= | |||
/tmp/terraform-log402289911 | |||
=Initialization= | =Initialization= | ||
The initialization operation initializes various local settings that will be used by subsequent commands. The command also downloads [[Terraform Concepts#Provider|provider]] binaries. The command needs to be re-run if new modules are set or changed, or backend configuration changes. | The initialization operation initializes various local settings that will be used by subsequent commands. Without additional arguments, it uses the current directory as [[Terraform_Concepts#Root_Module|root module]] and creates a [[Terraform_Concepts#.terraform_Directory|.terraform]] directory, which contains a "plugins" sub-directory. The command also downloads [[Terraform Concepts#Provider|provider]] binaries and, if any modules are used, the [[Terraform_Concepts#Module_Initialization|module source]]. The command needs to be re-run if new modules are set or changed, or backend configuration changes. | ||
<syntaxhighlight lang='text'> | |||
terraform init | |||
Initializing the backend... | |||
Initializing provider plugins... | |||
- Checking for available provider plugins... | |||
- Downloading plugin for provider "aws" (hashicorp/aws) 2.49.0... | |||
The command | The following providers do not have any version constraints in configuration, | ||
so the latest version was installed. | |||
To prevent automatic upgrades to new major versions that may contain breaking | |||
changes, it is recommended to add version = "..." constraints to the | |||
corresponding provider blocks in configuration, with the constraint strings | |||
suggested below. | |||
* provider.aws: version = "~> 2.49" | |||
Terraform has been successfully initialized! | |||
You may now begin working with Terraform. Try running "terraform plan" to see | |||
any changes that are required for your infrastructure. All Terraform commands | |||
should now work. | |||
If you ever set or change modules or backend configuration for Terraform, | |||
rerun this command to reinitialize your working directory. If you forget, other | |||
commands will detect it and remind you to do so if necessary. | |||
</syntaxhighlight> | |||
==-upgrade== | |||
The <code>-upgrade</code> option will additionally check for any newer versions of existing modules and providers that may be available. | |||
==-from-module== | |||
<code>-from-module</code> is a useful option when we want to avoid creating transient metadata, such as the [[Terraform_Concepts#.terraform_Directory|.terraform]] directory, inside a module directory. A common use case is when we run provisioning off modules maintained in a Git repository. While using it, be aware of the following idiosyncrasy: the <code>--from-module=</code> argument must not include ~. | |||
<syntaxhighlight lang='bash'> | |||
mkdir ~/tmp/pseudo-root-module | |||
cd ~/tmp/pseudo-root-module | |||
terraform init --from-module=../../playground/hashicorp/terraform/simplest-module | |||
</syntaxhighlight> | |||
The command makes a physical copy of the configuration in the current directory. [[#Apply|terraform apply]] can then be executed in that directory. | |||
=Configuration File Formatting= | =Configuration File Formatting= | ||
Line 25: | Line 84: | ||
Formats all .tf in the current directory. It aligns equals, etc. Formatting enables standardization. | Formats all .tf in the current directory. It aligns equals, etc. Formatting enables standardization. | ||
=Validation= | |||
terraform validate | |||
=Get= | |||
Pull dependencies of the module the command is run against from their repositories and store a copy locally in the [[Terraform_Concepts#.terraform_Directory|.terraform directory]]. | |||
terraform get | |||
=Plan= | |||
The plan is created based on the [[Terraform_Concepts#State|state]] maintained locally or remotely by Terraform. By default, before each plan operation, Terraform sync all resources in its [[Terraform Concepts#State|state]]. | |||
=Apply= | =Apply= | ||
{{External|https://www.terraform.io/docs/commands/apply.html}} | {{External|https://www.terraform.io/docs/commands/apply.html}} | ||
<syntaxhighlight lang='bash'> | |||
terraform apply | |||
</syntaxhighlight> | |||
When the first apply operation is executed, state file [[Terraform_Concepts#terraform.tfstate|terraform.tfstate]] is created. By default, before each apply operation, Terraform sync all resources in its [[Terraform Concepts#State|state]]. | |||
The output shows the execution plan, in a format similar to diff. | The output shows the execution plan, in a format similar to diff. | ||
Line 122: | Line 199: | ||
aws_instance.terraform-test-01: Creation complete after 24s [id=i-afbbc2c4a789ab871] | aws_instance.terraform-test-01: Creation complete after 24s [id=i-afbbc2c4a789ab871] | ||
</syntaxhighlight> | </syntaxhighlight> | ||
==Apply Options== | |||
===-auto-approve=== | |||
Skip interactive approval of plan before applying. | |||
=Show= | =Show= | ||
<syntaxhighlight lang='bash'> | |||
terraform show | |||
</syntaxhighlight> | |||
Shows the [[Terraform_Concepts#State_Operations|state]]. It contain interesting information obtained after installation, such as IP addresses, etc. | |||
It also shows content of [[Terraform_Concepts#terraform.tfstate|terraform.tfstate]] state file. | |||
=Output= | |||
Used to extract the value of an [[Hashicorp_Configuration_Language#Output_Variable|output variable]] from the state file. | |||
All variables are extracted with: | |||
terraform output | |||
A specific variable is extracted with: | |||
terraform output <''output-var-name''> | |||
==Options== | |||
===-json=== | |||
===-no-color=== | |||
=Import= | |||
Instances can be imported using their ID: | |||
terraform import aws_instance.web i-00000000000 | |||
=Destroy= | =Destroy= | ||
Line 134: | Line 242: | ||
terraform destroy | terraform destroy | ||
=State= | |||
{{External|https://www.terraform.io/docs/commands/state/index.html}} | |||
The <code>state</code> exposes a set of sub-commands that allow [[Terraform_Concepts#State_Operations|basic state management]]. | |||
<syntaxhighlight lang='bash'> | |||
terraform state | |||
</syntaxhighlight> | |||
==List== | |||
<syntaxhighlight lang='bash'> | |||
terraform state list | |||
</syntaxhighlight> | |||
=Refresh= | |||
{{External|https://www.terraform.io/docs/commands/refresh.html}} | |||
<syntaxhighlight lang='bash'> | |||
cd <root-module-dir> | |||
terraform refresh | |||
</syntaxhighlight> | |||
The command reconcile the state Terraform knows about via its [[Terraform_Concepts#terraform.tfstate|terraform.tfstate]] file with the real-world infrastructure. The command can be used to detect any drift from the last-known state, and to update the state file. The command does not modify infrastructure, but does modify the state file. If the state is changed, this may cause changes to occur during the next plan or apply. | |||
=Force Unlock= | |||
{{External|https://www.terraform.io/docs/commands/force-unlock.html}} | |||
<syntaxhighlight lang='bash'> | |||
terraform force-unlock | |||
</syntaxhighlight> | |||
Command to force-unlock state. | |||
{{Warn|Use force-unlock with caution. If state is unlocked when someone else is holding the lock, multiple writers can write it and the state can be corrupted. Force unlock should only be used to unlock your own lock in the situation where automatic unlocking failed.}} | |||
More on state locking available here: | |||
{{Internal|Terraform Concepts#Locking|State Locking}} | |||
=Provider-Specific Operations= | =Provider-Specific Operations= | ||
==AWS Operations== | ==AWS Operations== | ||
{{Internal|Terraform AWS Operations|Terraform AWS Operations}} | {{Internal|Terraform AWS Operations|Terraform AWS Operations}} |
Latest revision as of 23:29, 28 February 2020
Internal
Version
terraform version
Help
terraform --help terraform <command> --help
Verbose Output and Debugging
Set TF_LOG
environment variable to one of:
TRACE
DEBUG
INFO
WARN
ERROR
This will send debug output to stderr.
To write to file, set TF_LOG_PATH
. Note that even when TF_LOG_PATH
is set, TF_LOG
must be set in order for any logging to be enabled.
Logs
/tmp/terraform-log402289911
Initialization
The initialization operation initializes various local settings that will be used by subsequent commands. Without additional arguments, it uses the current directory as root module and creates a .terraform directory, which contains a "plugins" sub-directory. The command also downloads provider binaries and, if any modules are used, the module source. The command needs to be re-run if new modules are set or changed, or backend configuration changes.
terraform init
Initializing the backend...
Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "aws" (hashicorp/aws) 2.49.0...
The following providers do not have any version constraints in configuration,
so the latest version was installed.
To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.
* provider.aws: version = "~> 2.49"
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
-upgrade
The -upgrade
option will additionally check for any newer versions of existing modules and providers that may be available.
-from-module
-from-module
is a useful option when we want to avoid creating transient metadata, such as the .terraform directory, inside a module directory. A common use case is when we run provisioning off modules maintained in a Git repository. While using it, be aware of the following idiosyncrasy: the --from-module=
argument must not include ~.
mkdir ~/tmp/pseudo-root-module
cd ~/tmp/pseudo-root-module
terraform init --from-module=../../playground/hashicorp/terraform/simplest-module
The command makes a physical copy of the configuration in the current directory. terraform apply can then be executed in that directory.
Configuration File Formatting
terraform fmt
Formats all .tf in the current directory. It aligns equals, etc. Formatting enables standardization.
Validation
terraform validate
Get
Pull dependencies of the module the command is run against from their repositories and store a copy locally in the .terraform directory.
terraform get
Plan
The plan is created based on the state maintained locally or remotely by Terraform. By default, before each plan operation, Terraform sync all resources in its state.
Apply
terraform apply
When the first apply operation is executed, state file terraform.tfstate is created. By default, before each apply operation, Terraform sync all resources in its state.
The output shows the execution plan, in a format similar to diff.
-/+ means the resource will be destroyed and recreated rather than update it in-place. ~ means update in-place.
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# aws_instance.terraform-test-01 will be created
+ resource "aws_instance" "terraform-test-01" {
+ ami = "ami-a6faba49dddaecfb7"
+ arn = (known after apply)
+ associate_public_ip_address = (known after apply)
+ availability_zone = (known after apply)
+ cpu_core_count = (known after apply)
+ cpu_threads_per_core = (known after apply)
+ get_password_data = false
+ host_id = (known after apply)
+ id = (known after apply)
+ instance_state = (known after apply)
+ instance_type = "m5.4xlarge"
+ ipv6_address_count = (known after apply)
+ ipv6_addresses = (known after apply)
+ key_name = (known after apply)
+ network_interface_id = (known after apply)
+ password_data = (known after apply)
+ placement_group = (known after apply)
+ primary_network_interface_id = (known after apply)
+ private_dns = (known after apply)
+ private_ip = (known after apply)
+ public_dns = (known after apply)
+ public_ip = (known after apply)
+ security_groups = (known after apply)
+ source_dest_check = true
+ subnet_id = (known after apply)
+ tenancy = (known after apply)
+ volume_tags = (known after apply)
+ vpc_security_group_ids = (known after apply)
+ ebs_block_device {
+ delete_on_termination = (known after apply)
+ device_name = (known after apply)
+ encrypted = (known after apply)
+ iops = (known after apply)
+ kms_key_id = (known after apply)
+ snapshot_id = (known after apply)
+ volume_id = (known after apply)
+ volume_size = (known after apply)
+ volume_type = (known after apply)
}
+ ephemeral_block_device {
+ device_name = (known after apply)
+ no_device = (known after apply)
+ virtual_name = (known after apply)
}
+ network_interface {
+ delete_on_termination = (known after apply)
+ device_index = (known after apply)
+ network_interface_id = (known after apply)
}
+ root_block_device {
+ delete_on_termination = (known after apply)
+ encrypted = (known after apply)
+ iops = (known after apply)
+ kms_key_id = (known after apply)
+ volume_id = (known after apply)
+ volume_size = (known after apply)
+ volume_type = (known after apply)
}
}
Plan: 1 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
aws_instance.terraform-test-01: Creating...
aws_instance.terraform-test-01: Still creating... [10s elapsed]
aws_instance.terraform-test-01: Still creating... [20s elapsed]
aws_instance.terraform-test-01: Creation complete after 24s [id=i-afbbc2c4a789ab871]
Apply Options
-auto-approve
Skip interactive approval of plan before applying.
Show
terraform show
Shows the state. It contain interesting information obtained after installation, such as IP addresses, etc.
It also shows content of terraform.tfstate state file.
Output
Used to extract the value of an output variable from the state file.
All variables are extracted with:
terraform output
A specific variable is extracted with:
terraform output <output-var-name>
Options
-json
-no-color
Import
Instances can be imported using their ID:
terraform import aws_instance.web i-00000000000
Destroy
terraform destroy
State
The state
exposes a set of sub-commands that allow basic state management.
terraform state
List
terraform state list
Refresh
cd <root-module-dir>
terraform refresh
The command reconcile the state Terraform knows about via its terraform.tfstate file with the real-world infrastructure. The command can be used to detect any drift from the last-known state, and to update the state file. The command does not modify infrastructure, but does modify the state file. If the state is changed, this may cause changes to occur during the next plan or apply.
Force Unlock
terraform force-unlock
Command to force-unlock state.
Use force-unlock with caution. If state is unlocked when someone else is holding the lock, multiple writers can write it and the state can be corrupted. Force unlock should only be used to unlock your own lock in the situation where automatic unlocking failed.
More on state locking available here: