3.3 KiB
layout | page_title | sidebar_current | description |
---|---|---|---|
intro | Change Infrastructure | gettingstarted-change | In the previous page, you created your first infrastructure with Vault: a single EC2 instance. In this page, we're going to modify that resource, and see how Vault handles change. |
Change Infrastructure
In the previous page, you created your first infrastructure with Vault: a single EC2 instance. In this page, we're going to modify that resource, and see how Vault handles change.
Infrastructure is continuously evolving, and Vault was built to help manage and enact that change. As you change Vault configurations, Vault builds an execution plan that only modifies what is necessary to reach your desired state.
By using Vault to change infrastructure, you can version control not only your configurations but also your state so you can see how the infrastructure evolved over time.
Configuration
Let's modify the ami
of our instance. Edit the "aws_instance.example"
resource in your configuration and change it to the following:
resource "aws_instance" "example" {
ami = "ami-aa7ab6c2"
instance_type = "t1.micro"
}
We've changed the AMI from being an Ubuntu 14.04 AMI to being an Ubuntu 12.04 AMI. Vault configurations are meant to be changed like this. You can also completely remove resources and Vault will know to destroy the old one.
Execution Plan
Let's see what Vault will do with the change we made.
$ vault plan
...
-/+ aws_instance.example
ami: "ami-408c7f28" => "ami-aa7ab6c2" (forces new resource)
availability_zone: "us-east-1c" => "<computed>"
key_name: "" => "<computed>"
private_dns: "domU-12-31-39-12-38-AB.compute-1.internal" => "<computed>"
private_ip: "10.200.59.89" => "<computed>"
public_dns: "ec2-54-81-21-192.compute-1.amazonaws.com" => "<computed>"
public_ip: "54.81.21.192" => "<computed>"
security_groups: "" => "<computed>"
subnet_id: "" => "<computed>"
The prefix "-/+" means that Vault will destroy and recreate the resource, versus purely updating it in-place. While some attributes can do in-place updates (which are shown with a "~" prefix), AMI changing on EC2 instance requires a new resource. Vault handles these details for you, and the execution plan makes it clear what Vault will do.
Additionally, the plan output shows that the AMI change is what necessitated the creation of a new resource. Using this information, you can tweak your changes to possibly avoid destroy/create updates if you didn't want to do them at this time.
Apply
From the plan, we know what will happen. Let's apply and enact the change.
$ vault apply
aws_instance.example: Destroying...
aws_instance.example: Modifying...
ami: "ami-408c7f28" => "ami-aa7ab6c2"
Apply complete! Resources: 0 added, 1 changed, 1 destroyed.
...
As the plan predicted, Vault started by destroying our old
instance, then creating the new one. You can use vault show
again to see the new properties associated with this instance.
Next
You've now seen how easy it is to modify infrastructure with Vault. Feel free to play around with this more before continuing. In the next section we're going to destroy our infrastructure.