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.
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.
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.
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.
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.
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!
I've written many blog posts about connecting to an Autonomous DB instance in the past. Best practices evolve as tools, services, and frameworks become...
In my last post, we looked at the technical aspects of my Brain to the Cloud project including much of the code that was used to collect and analyze the...
In my last post, we went over the inspiration, objectives, and architecture for my Brain to the Cloud project. In this post, we'll look in-depth at the...