github.com/nathanielks/terraform@v0.6.1-0.20170509030759-13e1a62319dc/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  ```hcl
    30  resource "aws_instance" "example" {
    31    ami           = "ami-b374d5a5"
    32    instance_type = "t2.micro"
    33  }
    34  ```
    35  
    36  ~> **Note:** EC2 Classic users please use AMI `ami-656be372` and type `t1.micro`
    37  
    38  We've changed the AMI from being an Ubuntu 16.04 LTS AMI to being
    39  an Ubuntu 16.10 AMI. Terraform configurations are meant to be
    40  changed like this. You can also completely remove resources
    41  and Terraform will know to destroy the old one.
    42  
    43  ## Execution Plan
    44  
    45  Let's see what Terraform will do with the change we made.
    46  
    47  ```
    48  $ terraform plan
    49  # ...
    50  
    51  -/+ aws_instance.example
    52      ami:                      "ami-2757f631" => "ami-b374d5a5" (forces new resource)
    53      availability_zone:        "us-east-1a" => "<computed>"
    54      ebs_block_device.#:       "0" => "<computed>"
    55      ephemeral_block_device.#: "0" => "<computed>"
    56      instance_state:           "running" => "<computed>"
    57      instance_type:            "t2.micro" => "t2.micro"
    58      private_dns:              "ip-172-31-17-94.ec2.internal" => "<computed>"
    59      private_ip:               "172.31.17.94" => "<computed>"
    60      public_dns:               "ec2-54-82-183-4.compute-1.amazonaws.com" => "<computed>"
    61      public_ip:                "54.82.183.4" => "<computed>"
    62      subnet_id:                "subnet-1497024d" => "<computed>"
    63      vpc_security_group_ids.#: "1" => "<computed>"
    64  ```
    65  
    66  The prefix "-/+" means that Terraform will destroy and recreate
    67  the resource, versus purely updating it in-place. While some attributes
    68  can do in-place updates (which are shown with a "~" prefix), AMI
    69  changing on EC2 instance requires a new resource. Terraform handles
    70  these details for you, and the execution plan makes it clear what
    71  Terraform will do.
    72  
    73  Additionally, the plan output shows that the AMI change is what
    74  necessitated the creation of a new resource. Using this information,
    75  you can tweak your changes to possibly avoid destroy/create updates
    76  if you didn't want to do them at this time.
    77  
    78  ## Apply
    79  
    80  From the plan, we know what will happen. Let's apply and enact
    81  the change.
    82  
    83  ```
    84  $ terraform apply
    85  aws_instance.example: Refreshing state... (ID: i-64c268fe)
    86  aws_instance.example: Destroying...
    87  aws_instance.example: Destruction complete
    88  aws_instance.example: Creating...
    89    ami:                      "" => "ami-b374d5a5"
    90    availability_zone:        "" => "<computed>"
    91    ebs_block_device.#:       "" => "<computed>"
    92    ephemeral_block_device.#: "" => "<computed>"
    93    instance_state:           "" => "<computed>"
    94    instance_type:            "" => "t2.micro"
    95    key_name:                 "" => "<computed>"
    96    placement_group:          "" => "<computed>"
    97    private_dns:              "" => "<computed>"
    98    private_ip:               "" => "<computed>"
    99    public_dns:               "" => "<computed>"
   100    public_ip:                "" => "<computed>"
   101    root_block_device.#:      "" => "<computed>"
   102    security_groups.#:        "" => "<computed>"
   103    source_dest_check:        "" => "true"
   104    subnet_id:                "" => "<computed>"
   105    tenancy:                  "" => "<computed>"
   106    vpc_security_group_ids.#: "" => "<computed>"
   107  aws_instance.example: Still creating... (10s elapsed)
   108  aws_instance.example: Still creating... (20s elapsed)
   109  aws_instance.example: Creation complete
   110  
   111  Apply complete! Resources: 1 added, 0 changed, 1 destroyed.
   112  
   113  # ...
   114  ```
   115  
   116  As the plan predicted, Terraform started by destroying our old
   117  instance, then creating the new one. You can use `terraform show`
   118  again to see the new properties associated with this instance.
   119  
   120  ## Next
   121  
   122  You've now seen how easy it is to modify infrastructure with
   123  Terraform. Feel free to play around with this more before continuing.
   124  In the next section we're going to [destroy our infrastructure](/intro/getting-started/destroy.html).