@ -165,16 +165,19 @@ specifying that version in configuration to ensure that running
is not necessary for following the getting started guide, since this
configuration will be discarded at the end.
## Execution Plan
## Apply Changes
Next, let's see what Terraform would do if we asked it to
apply this configuration. In the same directory as the
`example.tf` file you created, run `terraform plan` . You
should see output similar to what is copied below. We've
truncated some of the output to save space.
~> **Note:** The commands shown in this guide apply to Terraform 0.11 and
above. Earlier versions require using the `terraform plan` command to
see the execution plan before applying it. Use `terraform version`
to confirm your running version.
In the same directory as the `example.tf` file you created, run
`terraform apply` . You should see output similar to below, though we've
truncated some of the output to save space:
```
$ terraform plan
$ terraform apply
# ...
+ aws_instance.example
@ -198,30 +201,31 @@ $ terraform plan
vpc_security_group_ids.#: "< computed > "
```
`terraform plan` shows what changes Terraform will apply to
your infrastructure given the current state of your infrastructure
as well as the current contents of your configuration.
If `terraform plan` failed with an error, read the error message
and fix the error that occurred. At this stage, it is probably a
syntax error in the configuration.
This output shows the _execution plan_ , describing which actions Terraform
will take in order to change real infrastructure to match the configuration.
The output format is similar to the diff format generated by tools
such as Git. The output has a "+" next to "aws\_instance.example" ,
such as Git. The output has a `+` next to `aws_instance.example` ,
meaning that Terraform will create this resource. Beneath that,
it shows the attributes that will be set. When the value displayed
is `<computed>` , it means that the value won't be known
until the resource is created.
## Apply
The plan looks good, our configuration appears valid, so it's time to
create real resources. Run `terraform apply` in the same directory
as your `example.tf` , and watch it go! It will take a few minutes
since Terraform waits for the EC2 instance to become available.
If `terraform apply` failed with an error, read the error message
and fix the error that occurred. At this stage, it is likely to be a
syntax error in the configuration.
If the plan was created successfully, Terraform will now pause and wait for
approval before proceeding. If anything in the plan seems incorrect or
dangerous, it is safe to abort here with no changes made to your infrastructure.
In this case the plan looks acceptable, so type `yes` at the confirmation
prompt to proceed.
Executing the plan will take a few minutes since Terraform waits for the EC2
instance to become available:
```
$ terraform apply
# ...
aws_instance.example: Creating...
ami: "" => "ami-2757f631"
instance_type: "" => "t2.micro"
@ -235,20 +239,19 @@ Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
# ...
```
Done! You can go to the AWS console to prove to yourself that the
EC2 instance has been created.
After this, Terraform is all done! You can go to the EC2 console to see the
created EC2 instance. (Make sure you're looking at the same region that was
configured in the provider configuration!)
Terraform also puts some state into the `terraform.tfstate` file
by default. This state file is extremely important; it maps various
resource metadata to actual resource IDs so that Terraform knows
what it is managing. This file must be saved and distributed
to anyone who might run Terraform. It is generally recommended to
Terraform also wrote some data into the `terraform.tfstate` file. This state
file is extremely important; it keeps track of the IDs of created resources
so that Terraform knows what it is managing. This file must be saved and
distributed to anyone who might run Terraform. It is generally recommended to
[setup remote state ](https://www.terraform.io/docs/state/remote.html )
when working with Terraform. This will mean that any potential secrets
stored in the state file, will not be checked into version control
when working with Terraform, to share the state automatically, but this is
not necessary for simple situations like this Getting Started guide.
You can inspect the state using `terraform show` :
You can inspect the current state using `terraform show` :
```
$ terraform show
@ -267,8 +270,8 @@ aws_instance.example:
```
You can see that by creating our resource, we've also gathered
a lot more metadata about it. This metadata can actually be referenced
for other resources or outputs, which will be covered later in
a lot of information about it. These values can actually be referenced
to configure other resources or outputs, which will be covered later in
the getting started guide.
## Provisioning
@ -279,8 +282,7 @@ an image-based infrastructure (perhaps creating images with
[Packer ](https://www.packer.io )), then this is all you need.
However, many infrastructures still require some sort of initialization
or software provisioning step. Terraform supports
provisioners,
or software provisioning step. Terraform supports provisioners,
which we'll cover a little bit later in the getting started guide,
in order to do this.
Martin Atkins
9 years ago