github.com/hs0210/hashicorp-terraform@v0.11.12-beta1/website/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  ## Apply Changes
    44  
    45  After changing the configuration, run `terraform apply` again to see how
    46  Terraform will apply this change to the existing resources.
    47  
    48  ```
    49  $ terraform apply
    50  # ...
    51  
    52  -/+ aws_instance.example
    53      ami:                      "ami-2757f631" => "ami-b374d5a5" (forces new resource)
    54      availability_zone:        "us-east-1a" => "<computed>"
    55      ebs_block_device.#:       "0" => "<computed>"
    56      ephemeral_block_device.#: "0" => "<computed>"
    57      instance_state:           "running" => "<computed>"
    58      instance_type:            "t2.micro" => "t2.micro"
    59      private_dns:              "ip-172-31-17-94.ec2.internal" => "<computed>"
    60      private_ip:               "172.31.17.94" => "<computed>"
    61      public_dns:               "ec2-54-82-183-4.compute-1.amazonaws.com" => "<computed>"
    62      public_ip:                "54.82.183.4" => "<computed>"
    63      subnet_id:                "subnet-1497024d" => "<computed>"
    64      vpc_security_group_ids.#: "1" => "<computed>"
    65  ```
    66  
    67  The prefix `-/+` means that Terraform will destroy and recreate
    68  the resource, rather than updating it in-place. While some attributes
    69  can be updated in-place (which are shown with the `~` prefix), changing the
    70  AMI for an EC2 instance requires recreating it. Terraform handles these details
    71  for you, and the execution plan makes it clear what Terraform will do.
    72  
    73  Additionally, the execution plan shows that the AMI change is what
    74  required resource to be replaced. Using this information,
    75  you can adjust your changes to possibly avoid destroy/create updates
    76  if they are not acceptable in some situations.
    77  
    78  Once again, Terraform prompts for approval of the execution plan before
    79  proceeding. Answer `yes` to execute the planned steps:
    80  
    81  
    82  ```
    83  # ...
    84  aws_instance.example: Refreshing state... (ID: i-64c268fe)
    85  aws_instance.example: Destroying...
    86  aws_instance.example: Destruction complete
    87  aws_instance.example: Creating...
    88    ami:                      "" => "ami-b374d5a5"
    89    availability_zone:        "" => "<computed>"
    90    ebs_block_device.#:       "" => "<computed>"
    91    ephemeral_block_device.#: "" => "<computed>"
    92    instance_state:           "" => "<computed>"
    93    instance_type:            "" => "t2.micro"
    94    key_name:                 "" => "<computed>"
    95    placement_group:          "" => "<computed>"
    96    private_dns:              "" => "<computed>"
    97    private_ip:               "" => "<computed>"
    98    public_dns:               "" => "<computed>"
    99    public_ip:                "" => "<computed>"
   100    root_block_device.#:      "" => "<computed>"
   101    security_groups.#:        "" => "<computed>"
   102    source_dest_check:        "" => "true"
   103    subnet_id:                "" => "<computed>"
   104    tenancy:                  "" => "<computed>"
   105    vpc_security_group_ids.#: "" => "<computed>"
   106  aws_instance.example: Still creating... (10s elapsed)
   107  aws_instance.example: Still creating... (20s elapsed)
   108  aws_instance.example: Creation complete
   109  
   110  Apply complete! Resources: 1 added, 0 changed, 1 destroyed.
   111  
   112  # ...
   113  ```
   114  
   115  As indicated by the execution plan, Terraform first destroyed the existing
   116  instance and then created a new one in its place. You can use `terraform show`
   117  again to see the new values associated with this instance.
   118  
   119  ## Next
   120  
   121  You've now seen how easy it is to modify infrastructure with
   122  Terraform. Feel free to play around with this more before continuing.
   123  In the next section we're going to [destroy our infrastructure](/intro/getting-started/destroy.html).