IaC in the Cloud: Integrating Terraform and Resource Manager into your CI/CD Pipeline - Building With the OCI CLI

Welcome back to this series where we’re learning all about using Terraform and Resource Manager to manage your infrastructure in the Oracle Cloud. In our last post, we saw how to use GitHub Actions to create a distributable release that can be shared with other developers and learned how to add a ‘Deploy to Oracle Cloud’ button to our repo. In this post, we’re going to look at executing our Terraform scripts with GitHub Actions using the OCI CLI in our workflow.

Building Infrastructure From Your Pipeline

So far in this series we have focused on manually invoking our infrastructure builds, but in this post we’re finally going to look at some automation options to include our cloud provisioning in our CI/CD pipeline. 

Create Secrets

In order to execute our Terraform scripts from our CI/CD pipeline, we’re going to need to set some secrets in our GitHub repo. Set some secrets for the following values from your tenancy.

Running With Resource Manager via the OCI CLI

Now that our secrets are set, we can create a workflow with GitHub Actions that uses the OCI CLI to build our stack. We will declare a few environment variables that will be available to our job steps.

Note: We’ll be working with the same code that we started using earlier in this series. If you get stuck or would like to view the entire project, check out this branch on GitHub that focuses on building with the OCI CLI: https://github.com/recursivecodes/oci-resource-manager-demo/tree/github-actions-resource-manager

Note: We’ll need a GitHub token to use in our workflow so that we can use GitHub itself as a source provider, so see part 3 of this series if you haven’t created that token yet.

Add your GitHub Access Token as a secret in your GitHub repo:

Now let’s add a few steps to our build. The first step will simply check out the project codebase into the CI/CD pipeline working directory. Then we will write out our secret values that we set above to the config file that the OCI CLI expects, install the CLI itself and repair the permissions on the config file.

And now we can start using the OCI CLI to perform the work that we manually performed in the previous posts in this series. Let’s look at a quick overview of the process as a refresher:

• Create GitHub Source Provider (if necessary)

• Create Stack (if necessary)

• Create/Execute Plan Job

• Create/Execute Apply Job

We can perform all of these tasks with the CLI in our workflow. First, let’s check for the source provider and stack - storing the OCID in environment variables if they are retrieved.

Next, we’ll create the source provider and stack if they don’t exist (note the if conditional that prevents the step from running if the object’s ID exists in the correct environment variable).

Finally, we can create the plan and apply jobs.

Once the build.yaml file is complete, we commit and push it to the remote GitHub repo to trigger the build. Once the job has succeeded, we can check the logs.

Summary

We’ve fully automated the process of creating our source provider, stack and running jobs via our GitHub Actions CI/CD pipeline! Notice that the job in this case took 3 minutes and 17 seconds to run. The longest running steps were the installation of the CLI and the steps to create the plan and apply jobs. Can we somehow improve those times? Read the next (and final) post in this series to find out!

Photo by NOAA on Unsplash