Terraform Workflow
Last updated
Last updated
The Terraform workflow generally follows four steps: Write, Initialise, Plan and Apply. To better understand this workflow and how it can benefit DevSecOps engineers while provisioning of infrastructure, let's consider an infrastructure at different points in development. When dealing with infrastructure provisioning, you tend to have different problems at different stages. To illustrate this, let's consider the Terraform workflow at three points in time:
Day 1 (the infrastructure does not exist yet and needs to be provisioned from scratch)
Day 2+ (The infrastructure exists, but some changes need to be made)
Day N (an undefined point in time when you no longer need this infrastructure)
Let's have a look at what the Terraform workflow would look like on Day 1 of infrastructure provisioning. You have an empty environment with no infrastructure set up and need to define and provision this infrastructure. Using Terraform, you would follow this workflow:
Write: In this part of the workflow, you would define the desired state of your infrastructure in a Terraform configuration file. As discussed in the previous task, these configuration files are used to define the desired components, and these components can reference each other if they have a relation.
Initialise: The next part of the workflow is to initialise. The init command prepares your workspace (the working directory where your Terraform configuration files are) so Terraform can apply your changes. This preparation includes things like downloading dependencies, for example, if your configuration file defines 'aws' as the provider, during the initialisation, Terraform will download the aws provider plug-in. This is done using the following command: terraform init
Plan: After initialising your workspace, you should now plan your changes. The planning stage considers what infrastructure is present currently (with it being Day 1, there will be no infrastructure present) vs the desired state and prepares a plan of actions which, if applied, will make it so the infrastructure matches the desired state. It produces this execution plan and will tell the user what components will be added/destroyed in the process. This is done using the following command: terraform plan
Apply: Apply actions the steps (detailed in the plan) required to take the infrastructure from the current state to the desired state. Terraform works out which order these infrastructure resources should be created. In our example from the previous task, we defined two resources: a VPC and a security group. Since the security group references the VPC and is therefore dependent on it, Terraform would create the VPC first. This is done using the following command: terraform apply
Day 2+ means any day after the infrastructure has been provisioned; what will the workflow look like when making changes to an existing infrastructure? Say, for instance, you wanted to add a component to your infrastructure.
Initialise: terraform init should be the first command run after making any changes to an infrastructure configuration. It will initialise the workspace just like when creating the infra from scratch.
Plan: Terraform plan is not required but is best practice, especially in an already existing infrastructure. The execution plan generated by the plan command will show you exactly what is being removed or added to the infrastructure. This can catch any misconfigurations before they are applied and break anything. The plan will assess the existing infrastructure in this case and note that the existing components match the desired state, so no changes need to be made, but the additional component has not been created yet and will need to be created to match the desired state, so will be listed as a resource that needs to be added.
Apply: Again, Terraform will provision the infrastructure changes defined using the execution plan made during the Plan phase (note that if you skip the planning phase, Terraform will automatically create an execution plan as if you had and will ask you to approve the plan before execution). The state file will then be updated to reflect that the current state now matches the desired state as the additional component has been added/provisioned.
Day N denotes a day in the future when the infrastructure is no longer needed. Maybe it was just a test environment, or the application it supports has been shelved. Now that this infrastructure is no longer needed, all that is required is to destroy it.
Destroy: Running the terraform destroy command will take care of this. Functionally, the destroy command is quite similar to the apply command in that it takes a plan (a destroy plan which Terraform makes on running this command) and compares it to what infrastructure currently exists and actions that plan instead of provisioning/de-provisioning resources changes, it tears down all resources.
