CircleCI is a continuous integration and delivery (CI/CD) platform for automating software builds, tests, and deployments. The CI/CD paradigm establishes version control repositories as the source of truth for your deployments. It also helps teams quickly ship new features and fixes by defining pipelines that help ensure the stability and resilience of your services through testing and automation. You can build deployment pipelines of varying complexity to satisfy your organization’s requirements for production deployments.
Using Terraform to manage your infrastructure as code enables the benefits of the CI/CD workflow for infrastructure deployments. Since your infrastructure is codified, your team can collaborate and review it and deploy it using automated pipelines instead of manual orchestration. To automate Terraform operations in a remote environment, you need to configure remote state storage so Terraform can access and manage your project's state across runs.
In this tutorial, you will use CircleCI and Terraform to deploy an S3-backed web application. You will configure and review an automated Terraform workflow and use HCP Terraform for remote state storage.
This tutorial assumes that you are familiar with the Terraform and HCP Terraform workflows. If you are new to Terraform, complete Get Started tutorials first. If you are new to HCP Terraform, complete the HCP Terraform Get Started tutorials first.
In order to complete this tutorial, you will need the following:
In order to authenticate with HCP Terraform to store your project's Terraform state, you need to configure your HCP Terraform integration with an HCP Terraform API token.
Navigate to your organization settings, then select the API tokens page.
Tip
If you are using a free HCP Terraform account, create a token for your default Owners team. Otherwise, choose or create a new team with permissions to manage workspaces.
Click Create a team token. Under Team, choose your team name and choose an Expiration of 30 days. Click Create.
Click Copy token to copy the token string. Store this token in a secure place as HCP Terraform will not display it again. Later in this tutorial, you will set an environment variable in your CircleCI project to this token value for your build to use.
Fork this tutorial’s example repository in GitHub. This repository contains example configuration to deploy Terramino, a Terraform-skinned Tetris game, to an AWS S3 bucket using Terraform and CircleCI.
Once you have forked the repository, clone it to your machine. Edit the command below to include your own GitHub username.
$ git clone https://github.com/YOUR_USER_NAME/learn-terraform-circleci
Then, navigate to the repository.
$ cd learn-terraform-circleci
Open the main.tf file.
The Terraform configuration in this repository deploys Terramino, a Terraform-skinned Tetris application, to an AWS S3 bucket.
main.tf
provider "aws" {
region = var.region
default_tags {
tags = {
hashicorp-learn = "circleci"
}
}
}
resource "random_uuid" "randomid" {}
resource "aws_s3_bucket" "app" {
tags = {
Name = "App Bucket"
}
bucket = "${var.app}.${var.label}.${random_uuid.randomid.result}"
force_destroy = true
}
resource "aws_s3_bucket_object" "app" {
acl = "public-read"
key = "index.html"
bucket = aws_s3_bucket.app.id
content = file("./assets/index.html")
content_type = "text/html"
}
resource "aws_s3_bucket_acl" "bucket" {
bucket = aws_s3_bucket.app.id
acl = "public-read"
}
resource "aws_s3_bucket_website_configuration" "terramino" {
bucket = aws_s3_bucket.app.bucket
index_document {
suffix = "index.html"
}
error_document {
key = "error.html"
}
}
This configuration uses a terraform.tfvars file to set values for the input variables of your configuration. Open the terraform.tfvars file to review its contents.
terraform.tfvars
region = "us-east-1"
label = "hashicorp"
app = "terramino"
Next, open the terraform.tf file. The configuration in this file defines the required provider and Terraform versions for this configuration. It also includes an empty cloud block.
main.tf
terraform {
cloud {}
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 4.4.0"
}
}
required_version = ">= 1.2.0"
}
The cloud block configures an HCP Terraform integration for CLI-driven HCP Terraform runs. As of Terraform 1.2.0, you can configure the cloud block using environment variables that let you dynamically determine which HCP Terraform organization or workspace to deploy to. Terraform also lets you use an environment variable to pass an HCP Terraform token to your CI/CD system. Later in this tutorial, you will configure environment variables in your CircleCI project to configure your HCP Terraform integration.
Navigate to the .circleci subdirectory
CircleCI pipelines consist of jobs and workflows. A job is a collection of steps executed together. A workflow is a sequence of jobs that progresses based on the result of the individual steps. For example, your CircleCI configuration may define a testing job that runs tests on your infrastructure and a deployment job that ships your changes. You can then compose these jobs into a workflow, specifying that if the test job succeeds, CircleCI should trigger the deployment job.
Each job declares an executor, which defines the environment CircleCI will perform the job's steps in. All of the jobs in this configuration use the Docker executor and reference a Docker image that contains the latest version of the Terraform binary.
Open the config.yml file in your file editor to review the jobs and workflows for this configuration.
This configuration defines four jobs: plan-apply, apply, plan-destroy, and destroy. It composes these jobs into an automated Terraform workflow.
plan-apply job
The plan-apply job copies your repository using the checkout step, runs terraform init to initialize your configuration, and generates a plan file named tfapply by running terraform plan -out.
The job uses the hashicorp/terraform:light Docker image, which contains the latest version of the Terraform binary. The persist_to_workspace step saves the initialized configuration and your environment variables for use in the following jobs. persist_to_workspace allows you to run this initialized Terraform configuration throughout the rest of the jobs in the workflow as if they are running on the same machine.
.circleci/config.yml
jobs:
plan-apply:
working_directory: /tmp/project
docker:
- image: docker.mirror.hashicorp.services/hashicorp/terraform:light
steps:
- checkout
- run:
name: terraform init & plan
command: |
terraform init -input=false
terraform plan -out tfapply -var-file terraform.tfvars
- persist_to_workspace:
root: .
paths:
- .
apply job
The apply job invokes the attach_workspace step to load the persisted workspace from the plan job, giving this job access to its artifacts, including the execution plan captured in the tfapply file. It then runs terraform apply using the -auto-approve flag to avoid prompting for user input.
apply:
docker:
- image: docker.mirror.hashicorp.services/hashicorp/terraform:light
steps:
- attach_workspace:
at: .
- run:
name: terraform
command: |
terraform apply -auto-approve tfapply
- persist_to_workspace:
root: .
paths:
- .
plan-destroy and destroy jobs
Similarly to the plan-apply and apply jobs, the plan-destroy job creates an execution plan and the destroy job executes that saved plan to remove all of the infrastructure tracked in the project's state file. It uses the persisted workspace to access the execution plan across jobs.
plan-destroy:
docker:
- image: docker.mirror.hashicorp.services/hashicorp/terraform:light
steps:
- attach_workspace:
at: .
- run:
name: terraform create destroy plan
command: |
terraform plan -destroy -out tfdestroy -var-file terraform.tfvars
- persist_to_workspace:
root: .
paths:
- .
destroy:
docker:
- image: docker.mirror.hashicorp.services/hashicorp/terraform:light
steps:
- attach_workspace:
at: .
- run:
name: terraform destroy
command: |
terraform apply -auto-approve tfdestroy
You should not run these jobs unattended because it may lead to disruption to your services.
Review the workflowThe last block in the configuration composes the jobs into a workflow. Workflows define order, precedence, and dependencies to perform the jobs within the pipeline.
workflows:
version: 2
plan_approve_apply:
jobs:
- plan-apply
- hold-apply:
type: approval
requires:
- plan-apply
- apply:
requires:
- hold-apply
- plan-destroy:
requires:
- apply
- hold-destroy:
type: approval
requires:
- plan-destroy
- destroy:
requires:
- hold-destroy
Notice that hold-apply and hold-destroy have type: approval in this workflow. This means that for every run, CircleCI will generate a plan and wait for approval before running the apply job. CircleCI will also generate a plan to destroy the infrastructure and wait for approval before running the destroy job.
This configuration uses HCP Terraform for your project's state storage. You will create a new workspace to use for this project and configure it for local execution. When using local execution with HCP Terraform, the Terraform operations occur in the environment that runs the Terraform CLI (in this case, the Docker executor configured for your build), and HCP Terraform stores the state file for shared access across builds and runs.
In the HCP Terraform UI, create a new CLI-driven workspace named learn-terraform-circleci.
On the workspace overview page, click on the curent Execution Mode to navigate to the general settings.
Under Execution Mode, select Local. Then, click Save Settings at the bottom of the page.
Navigate to your CircleCI dashboard. Make sure that you are in the correct organization with access to your GitHub account by confirming the organization in the top left corner.
Then, select Projects in the left sidebar.
Search for your forked learn-terraform-circleci repository. Then, click the Set Up Project button
Select the Fastest configuration option to use the CircleCI configuration file in the repository. Enter the main branch as the brain to track. Then, click Set Up Project.
CircleCI will automatically attempt to run the job and fail because the project needs your AWS credentials and HCP Terraform integration details.
Navigate to the project's Project Settings, then select Environment Variables from the sidebar.
Set the following environment variables, which Terraform will access in your build environment to configure both the AWS provider and the HCP Terraform integration for your project:
AWS_ACCESS_KEY_ID to the generated key for the AWS user running this job. To generate an access key and secret access key file, log in to your AWS account and create them in IAM.AWS_SECRET_ACCESS_KEY to the secret access key you generated above.TF_CLOUD_ORGANIZATION to your HCP Terraform organization nameTF_WORKSPACE to learn-terraform-circleci, the HCP Terraform workspace you created and configured earlier in this tutorial.TF_TOKEN_app_terraform_io to the API token you created at the beginning of the tutorial.When complete, your environment variables page will list the configured variables.
In your file editor, open terraform.tfvars and update the label variable value to hashicorp.fun. Then, save the file.
terraform.tfvars
region = "us-east-1"
label = "hashicorp.fun"
app = "terramino"
Stage your changes to your GitHub repository.
$ git add terraform.tfvars
Commit these changes with a message.
$ git commit -m "Update variable definitions"
Finally, push these changes to your forked repository's main branch to kick off a CircleCI run.
The CircleCI web UI should indicate that your build started. The steps for this deployment will initialize your Terraform directory, plan the Terraform deployment, and wait for your approval to apply the planned changes.
Review the output for the plan-apply job, which shows the proposed execution plan to create your resources. First, click on the plan-apply step in the workflow, then expand the terraform init && plan step to review the execution plan.
Then, return to the workflow overview by clicking the plan_approve_apply workflow at the top and approve it.
Once the deployment job is complete, your workflow will hold so that you can review the destroy plan before it starts the destroy job. Before you approve the destroy operation, review the output for the apply job and navigate to the endpoint in the output to test out your application.
Any changes to your GitHub repository will trigger another run of this workflow. As with any Terraform deployment, Terraform will determine which resources to recreate or update in place depending on configuration and the provider.
Navigate to the HCP Terraform workspace to verify that it stores the state for your project, and lists the resources it manages on the workspace overview page.
Destroy the infrastructure
The plan-destroy step in the workflow generated and saved a plan to destroy your application. The hold-destroy job is a manual gate step that gives you to review the plan before the workflow destroys your resources. Click on the hold step and then choose "approve" to move on to the destroy job in this workflow.
While Terraform is destroying your infrastructure, navigate to the plan-destroy job in the CircleCI web UI to observe the output in the terraform create destroy plan dropdown.
In this tutorial, you deployed an S3-backed website using Terraform and CircleCI and stored the project state in HCP Terraform. If you would like to learn more about CircleCI or automated Terraform workflow best practices, consider these resources:
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4