How I Deployed Terraform Resources with CircleCI

Photo Credit: Bianca Ackermann of Unsplash

As part of my DevOps learning journey, I had an opportunity to use another impressive CI/CD tool. In this automation adventure, I followed an insightful HashiCorp tutorial that provided exposure to CircleCI. In addition to deploying an animated, puzzle — style website and storing it on an AWS simple storage service (s3), I learned about a very helpful continuous integration instrument.

What is Continuous Integration?

Continuous integration (CI) is the process of melding code commits from multiple developers into one seamless pipeline. With frequent (best practice recommends daily) commits, small batches of code are built, and tested for errors. If the test is successful, then deployment occurs. A satisfactory deployment then leads to Production. Therefore, the key steps in CI are commit, build and test. We will address continuous deployment in more detail in another project.

CircleCI Explained

CircleCI is a continuous integration tool, used to build, commit and test a codebase. On its website, CircleCI touts features such as:

· Version Control System (VCS) integration with GitHub and BitLocker

· Automated Testing

· Notifications, in the event of pipeline failure

· Automated Deployments

Notably, the website also lists Jenkins as a chief competitor and encourages users to switch from it to CircleCI. Let’s test out CircleCI by using it to deploy some Terraform infrastructure!

The logo for CircleCI

Automation Defined

Automation is the creation of a repetitive action process, which requires minimal to no human intervention. If implemented properly, the use of an automation process also reduces the risk of user error while completing tasks that require heavy amounts of reiteration. In this adventure, we will use automation to run the Terraform configuration.

Materials

· An AWS account

· A CircleCI account. If you do not already have an account with CircleCI, you can register for one with your GitHub account.

· A GitHub account

· An Integrated Development Environment (IDE) of your choice. For this project, I will use Visual Studio Code (VSC) to view edit files. Windows PowerShell will also feature prominently during this exercise.

The Terraform logo

Step One: Fork Demo Code from HashiCorp Learn

We will follow a tutorial from HashiCorp for this activity. I forked the demo code from HashiCorp’s GitHub repository and cloned it to my computer.

Instructions for cloning the repo from GitHub. Image Credit: HashiCorp

After completing those steps, I created a directory and changed into it.

The image of changing into our directory

Before we move forward, we should review the config.yml file we’ll run. To do so, open the file in an IDE.

Step Two: Review the CircleCI Configuration

Four Jobs with CircleCI

Our CircleCI configuration will complete four jobs during the process of automating the Terraform workflow.

· The “plan — apply” Job: This job will use the “hashicorp/terraform: light” image, which according to HashiCorp, contains a Terraform binary. This job conducts the checkout steps and runs the “terraform init” command. It will also create a file, called “tfapply,” by running the “terraform plan -out” command.

Visual of the “plan-apply” and the “apply” jobs in the CircleCI configuration

· The “apply” Job: In this job, HashiCorp states “the ‘attach_workspace’ step in the apply job loads the previously persisted workspace in the ‘plan’ job.” The “apply” job will run the “terraform apply” command to execute “tfapply”, which we created in the previous step. The “auto — approve” designation allows users to bypass multiple prompts to confirm approval.

· The “plan — destroy” Job: This job generates a plan to destroy the deployed infrastructure.

Screenshot of the “plan-destroy” and “destroy” jobs ran by CircleCI

· The “destroy” Job: This part of the process executes the plan to destroy the infrastructure.

HashiCorp advises that users keep a keen eye on the “plan — destroy” and “destroy” jobs while they run. Interruptions may occur and it will behoove users to monitor the progress of each job. As a newbie, I’ll keep a keen eye on all jobs in the pipeline.

Workflow

The workflow is the last portion of this CircleCI configuration. It coordinates the order, and the requirements of, each job in the pipeline. HashiCorp explains the “plan_approve_apply” workflow runs throughout each step of the process in an orderly fashion and creates an application accordingly.

The workflow of our “learn-terraform-circleci” configuration

Step Three: Set Up The Project in CircleCI

Now that we’ve reviewed the jobs and the workflow that CircleCI will run, let’s set up our project in CircleCI.

Since our CircleCI account is linked to our GitHub account, you’ll see the forked repo already listed under “Projects.” When you attempt this project, select the blue “Set Up Project” button and continue to the next screen.

Visual of CircleCI’s “Projects” screen

Photo Credit: HashiCorp

Upon arriving at the following screen, select “Hello World” and click on the choice for “Use Existing Config” for the new project. A pop — up window to confirm the creation of a “config.yml” file will appear. At this point, click the “Start Building” button.

Photo Credit: HashiCorp

Immediately, CircleCI will make an unsuccessful attempt to run the jobs within the pipelines. That result occurred because two critical pieces needed for a seamless operation are missing. We must enter our AWS Access Key ID and the AWS Secret Access Key within the “Environment Variables” screen, then save them to proceed with our project. I have included a visual of the “Environment Variables” screen, excluding my AWS credentials from your viewing.

Image of the CirlceCI’s “Environment Variables” screen

On the following screen, CircleCI displays the name of the project in focus, the statuses of each job within the pipeline, the workflow, the repo branch/commit, and settings.

Image of the “learn-terraform-circleci” project screen in CircleCI after a successful run

Step Four: Create the Backend

Now that we’ve reviewed the jobs and the workflow that CircleCI will run, let’s go back to the directory created at the beginning of this exercise and to launch the backend for it. After changing into the “s3_backend” directory, I’ll run the “terraform init” command. The “terraform init” command initializes this directory, the backend, and the provider plugins.

Image of the “terraform init” command and the result

After the initiation, the next step will require the “terraform apply” command to execute the configuration. As shown in the image below, a list of Terraform’s tentative actions immediately appears. After you review and approve the proposed actions, type “yes” to confirm them. Upon confirmation, the approved activities begin to occur.

Visual of the output from the “terraform apply” command

The “terraform apply” command results in the creation of an S3 bucket that took 12 seconds to generate.

The creation of an S3, after typing “yes” to confirm the “terraform apply” action

Step Five: Establish Terraform Variables

At this stage, it is necessary to return to the “learn-terraform-circleci” local repository. Once complete, use the file editor of your choice to open the “main.tf” file. Update this file with the generated “S3_bucket_ name,” in addition to your preferred AWS region.

Image of the revised “main.tf” file

Once you’ve updated and saved the “main.tf” file, open the “variables.tfvars” one to revise it with deployment variables.

Visual of the updated “variable.tfvars” file

Step Six: Initiate the CircleCI Workflow

The next part of the project requires initiation of the CircleCI workflow through the GitHub repository.

• git add main.tf variables.tfvars: Adds changes to the GitHub repo.
• git commit -m “Add remote backend and variable definitions”: Commits these changes with a message.
• git push: Pushes changes to the master branch in my forked repository to initiate the CircleCI run.

Screenshot of the git actions to update information within the GitHub repository

A review of the project within the CircleCI site indicates the deployment will run smoothly.

Image of the “apply” job after initiating the CircleCI workflow

When I take a deeper look into the workflow, the process details indicate the completion of the “apply” process, with seven added resources.

Visual of the “apply” process displayed within CircleCI

A close — up of the image showing a successful apply with seven added resources

Step Seven: Review AWS Resources

I revisit my AWS console to review the status of the generated “circle-ci- backend” S3 and see that it was successfully created and deployed. The review of AWS resources also revealed the creation of a second s3, “terramino.hashicorp.fun,” which contains the surprise.

Screenshot of the “circle-ci-backend” S3 from the AWS Console

Image of the “terramino.hashicorp.fun” S3 within the AWS Console

Step Eight: Check Our Work

Following a review of all the variables and confirming deployed resources, it’s finally time to check our work. What happens after navigating to the endpoint (address) provided within the “apply” output?

The puzzle— style animation saved on an S3 that appears after a successful CI/CD run with CirlceCI

We get a great surprise: A puzzle — style game titled, “Terranimo,” created by HashiCorp! At the end of the animation when all of the puzzle pieces fill up to the top of the screen, a “Game Over!” message appears.

Step Nine: Destroy the Resources

Now that we’ve revealed the cool animation, we have to destroy the setup. We don’t want to incur any unnecessary AWS charges by continuing to run resources that only have a temporary need. As shown in the image below, click on the “hold — destroy” button to indicate approval. This step will initiate the “destroy” process.

Visual of the CircleCI “plan_approve_apply” screen with the approved “hold-destroy” option and a pending status for the “destroy” job

Shortly afterward, the “destroy” process will finalize.

Image of a completed “destroy” process

Go back to the project dashboard to ensure the status of the pipeline.

Screenshot of the “learn-terraform-circleci” project, displaying a successful run of all required jobs

To finalize the destruction of all resources within this project, go back to the local repository and enter the “terraform destroy” command to eliminate the final resource.

Screenshot of a “terraform destroy” run for the deployed architecture

This project was challenging, yet fun! While this exercise reminded me of a certain, beloved video game from childhood, it also showed how CircleCI is a valuable CI tool. During this project, I learned how CircleCI’s automated workflow effectively ran Terraform configurations throughout all jobs in the pipeline. HashiCorp Learn’s “Deploy Terraform Infrastructure with CircleCI” exercise served as the basis of this project. I look forward to experimenting with additional automation tools during my career transition journey!