github.com/jmbataller/terraform@v0.6.8-0.20151125192640-b7a12e3a580c/website/source/intro/getting-started/change.html.md (about) 1 --- 2 layout: "intro" 3 page_title: "Change Infrastructure" 4 sidebar_current: "gettingstarted-change" 5 description: |- 6 In the previous page, you created your first infrastructure with Terraform: a single EC2 instance. In this page, we're going to modify that resource, and see how Terraform handles change. 7 --- 8 9 # Change Infrastructure 10 11 In the previous page, you created your first infrastructure with 12 Terraform: a single EC2 instance. In this page, we're going to 13 modify that resource, and see how Terraform handles change. 14 15 Infrastructure is continuously evolving, and Terraform was built 16 to help manage and enact that change. As you change Terraform 17 configurations, Terraform builds an execution plan that only 18 modifies what is necessary to reach your desired state. 19 20 By using Terraform to change infrastructure, you can version 21 control not only your configurations but also your state so you 22 can see how the infrastructure evolved over time. 23 24 ## Configuration 25 26 Let's modify the `ami` of our instance. Edit the "aws\_instance.example" 27 resource in your configuration and change it to the following: 28 29 ``` 30 resource "aws_instance" "example" { 31 ami = "ami-aa7ab6c2" 32 instance_type = "t1.micro" 33 } 34 ``` 35 36 We've changed the AMI from being an Ubuntu 14.04 AMI to being 37 an Ubuntu 12.04 AMI. Terraform configurations are meant to be 38 changed like this. You can also completely remove resources 39 and Terraform will know to destroy the old one. 40 41 ## Execution Plan 42 43 Let's see what Terraform will do with the change we made. 44 45 ``` 46 $ terraform plan 47 ... 48 49 -/+ aws_instance.example 50 ami: "ami-408c7f28" => "ami-aa7ab6c2" (forces new resource) 51 availability_zone: "us-east-1c" => "<computed>" 52 key_name: "" => "<computed>" 53 private_dns: "domU-12-31-39-12-38-AB.compute-1.internal" => "<computed>" 54 private_ip: "10.200.59.89" => "<computed>" 55 public_dns: "ec2-54-81-21-192.compute-1.amazonaws.com" => "<computed>" 56 public_ip: "54.81.21.192" => "<computed>" 57 security_groups: "" => "<computed>" 58 subnet_id: "" => "<computed>" 59 ``` 60 61 The prefix "-/+" means that Terraform will destroy and recreate 62 the resource, versus purely updating it in-place. While some attributes 63 can do in-place updates (which are shown with a "~" prefix), AMI 64 changing on EC2 instance requires a new resource. Terraform handles 65 these details for you, and the execution plan makes it clear what 66 Terraform will do. 67 68 Additionally, the plan output shows that the AMI change is what 69 necessitated the creation of a new resource. Using this information, 70 you can tweak your changes to possibly avoid destroy/create updates 71 if you didn't want to do them at this time. 72 73 ## Apply 74 75 From the plan, we know what will happen. Let's apply and enact 76 the change. 77 78 ``` 79 $ terraform apply 80 aws_instance.example: Destroying... 81 aws_instance.example: Modifying... 82 ami: "ami-408c7f28" => "ami-aa7ab6c2" 83 84 Apply complete! Resources: 0 added, 1 changed, 1 destroyed. 85 86 ... 87 ``` 88 89 As the plan predicted, Terraform started by destroying our old 90 instance, then creating the new one. You can use `terraform show` 91 again to see the new properties associated with this instance. 92 93 ## Next 94 95 You've now seen how easy it is to modify infrastructure with 96 Terraform. Feel free to play around with this more before continuing. 97 In the next section we're going to [destroy our infrastructure](/intro/getting-started/destroy.html).