Learn Terraform with GCP — Part 2
In the previous article, we went through how to create a GCP Compute Instance using Terraform.
Here, we will look at how you can modify resources created by Terraform and some considerations on how it may affect your infrastructure. We will also look at how to destroy the resources that you created when no longer needed.
Update a Resource
Following on the Compute Instance creation from Part 1, let us update the machine from e2-micro to e2-small. The corresponding code is shown below with the changed line highlighted.
terraform {
required_providers {
google = {
source = "hashicorp/google"
version = "~> 3.90.1"
}
}
required_version = ">= 1.2.0"
}provider "google" {
project = "your-project-id-here"
region = "us-central1"
} resource "google_compute_instance" "web_server" {
name = "web-vm"
machine_type = "e2-small"
zone = "us-central1-a" boot_disk {
initialize_params {
image = "debian-cloud/debian-9"
}
}
network_interface {
network = "default"
access_config {
# Optional
# Include this section to give the VM an external IP address
}
}
}
After saving the above change, run a terraform plan command in the same directory to view the changes that Terraform will make.
~ update in-placeTerraform will perform the following actions:# google_compute_instance.web_server will be updated in-place
~ resource "google_compute_instance" "web_server" {
id = "projects/********/zones/us-central1-a/instances/web-vm"
~ machine_type = "e2-micro" -> "e2-small"
name = "web-vm"
tags = []
# (16 unchanged attributes hidden)# (4 unchanged blocks hidden)
}Plan: 0 to add, 1 to change, 0 to destroy.
As shown in the terraform plan output above, the instance will be updated to an e2-small. This will not affect any other configuration on the machine including the attached disk (which might have data in a real environment).
Continue to run terraform apply to commit the changes and update the machine. See output below:
google_compute_instance.web_server: Modifying... [id=projects/********/zones/us-central1-a/instances/web-vm]
╷
│ Error: Changing the machine_type, min_cpu_platform, service_account, enable_display, shielded_instance_config, scheduling.node_affinities or network_interface.[#d].(network/subnetwork/subnetwork_project) or advanced_machine_features on a started instance requires stopping it. To acknowledge this, please set allow_stopping_for_update = true in your config. You can also stop it by setting desired_status = "TERMINATED", but the instance will not be restarted after the update.According to this, the update cannot be done unless the machine is turned off. And the provider plugin also gives the recommendation on what needs to be done to get this applied.
Add the line allow_stopping_for_update=true as the last item in the configuration as shown:
# Partial code section #network_interface {
network = "default"
access_config {
# Optional
# Include this section to give the VM an external IP address
}
}
allow_stopping_for_update = true
}
Run terraform apply again to continue and update the resource.
Plan: 0 to add, 1 to change, 0 to destroy.
google_compute_instance.web_server: Modifying... [id=projects/********/zones/us-central1-a/instances/web-vm]<content removed for brevity>google_compute_instance.web_server: Modifications complete after 2m16s [id=projects/********/zones/us-central1-a/instances/web-vm]Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
The compute instance have been successfully updated. You can verify that the instance is running with the updated machine type when the terraform apply is completed.
Important Note
There are some considerations to be aware of when modifying Terraform resources: A modify or update of resources does not necessarily mean that an existing resource is updated with the changes that you made to the code. Depending on the provider and resource type, an update might require the existing resource to be deleted and a new one created in it’s place. Or it might mean that a resource is shut down (like the Compute Instance example) and restarted with new settings. This can also vary based on which parameter of the resource changed.
In the above example, adding a new disk to the instance would be treated as an update, where the new disk is added to the existing instance.
On the other hand, if you change the region where the instance is provisioned, it will remove the existing instance, and create a new one in the new region specified. The terraform plan will indicate whether a resource is updated in-place or one resource is destroyed and a new one is created based on the scenario. Be careful to read the plan output before you commit a change.
Destroy a Resource
Destroying a resource can be done in multiple ways. The most obvious way is the terraform destroy command. This targets the entire set of resources in the current directory, in the reverse sequence of how they were created, when appropriate dependencies exist in the code.
Running terraform destroy will display the planned list of resources to be deleted and prompt you to confirm before the deletion is done. When you confirm with a yes, the resources will be removed and state file will be updated to reflect this.
However, if your Terraform module (resources in the current directory) includes multiple resources, and you wish to remove only one of them, you can do that by commenting out the code section that defines the specific resource and running terraform apply. This causes Terraform to re-evaluate code and the state files and match up the existing resources in the GCP environment. When you comment out the code for one of the resources, this essentially means that the resource is no longer needed, since it exists in the state file but you removed it from the corresponding Terraform code.
In short, Terraform does not care about what is in the real environment as long as it does not conflict with the state file. Terraform will not manage or update anything in the environment outside of what is defined in your code, and makes sure that your code, the state file and the associated resources are in sync.
We’ll continue with understanding Remote State backends in the next article.
