Let's try: Terraform part 6 - CI/CD

In this series

1. Let's try: Terraform part 1 - basic
2. Let's try: Terraform part 2 - variables
3. Let's try: Terraform part 3 - backend
4. Let's try: Terraform part 4 - modules
5. Let's try: Terraform part 5 - import
6. Let's try: Terraform part 6 - CI/CD
7. Let's try: Terraform part 7 - Locals, Data, and Output

In this blog we’re gonna wrap up all basic part 1 to 5 and make it automated by using our CI/CD tool, Google Cloud Build

If you want to understand what is Google Cloud Build and CI/CD, feel free to follow this link.

Automate your project with Google Cloud Build

Automate deployment is a useful scheme associated with Git concepts.

bluebirz

---

File structures

Ok, we would reuse the files from the latest blog and have them in this structure.

• folder “modules” has only GCS module and its variables
• folder “src”, we split into backend, main, provider, and variables file
• folder “variables”, we split variables into 2 files; GCS as “gcs-dev.tfvars” and project name as “project-dev.tfvars”.

Also there are other 2 files we didn’t make it before in this series. They are:

“backend-dev.hcl”

HCL file is HashiCorp Configuration Language that we utilise it to store our backend configurations. It would be nice when we’re building in multiple environments. Therefore we can leave the backend script blank like this.

and prepare backend configuration in a separated file, say naming it “backend-dev.hcl”

“cloudbuild.yaml”

Our main character is here. Remember Terraform commands we used in the terminal? We will arrage them all into the file.

It is so easy as we can just use a ready-to-use Terraform image, “hashicorp/terraform:1.0.0”. This is a link to Docker Hub.

We create 3 simple steps here.

init

Get into folder “src” and init adding parameters of “backend-dev.hcl”. Now we are using the proper state file.

cd src
terraform init -backend-config="../variables/backend-dev.hcl"

plan

Run the command.

cd src
terraform plan $(for v in $(ls ../variables/*.tfvars); do echo -var-file='$v'; done)

For the statement $(for v in ...; do echo -var-file='$v'; done), we are listing all “tfvars” files in the folder “variables” then print them out in the format -var-files='...'. As a result, it’s concatinating to a full command like this.

cd src
terraform plan -var-file="gcs-dev.tfvars" -var-file="project-dev.tfvars"

We don’t have to update the command every time we created a new “tfvars” file, just put it in the correct folder and the command will reflect them automatically.

apply

cd src
terraform apply $(for v in $(ls ../variables/*.tfvars); do echo -var-file="$v"; done) -auto-approve

When everything seems fine we can add -auto-approve there.

---

Try once manually

Let’s run it by hand just once.

We init it.

We plan it.

And we apply it.

So now we can see the bucket “bluebirz_sample_tf_cicd_01” there.

---

Run it on Cloud Build

This time we run on Cloud Build.

First of all, make sure we already have a trigger for the repo and granted necessary permissions to the service account of the trigger.

In this case, I have granted permission “Storage Admin” for the Cloud Build service account. See how to configure access for Cloud Build and understanding GCP roles.

I changed the name of target bucket from “bluebirz_sample_tf_cicd_01” to “bluebirz_sample_tf_cicd_02” so the bucket is expected to be re-created in the new name.

Commit the change and push it. Cloud Build runs successfully.

Go check buckets and yes, it’s re-created actually.

---

Repo

For all source code of this part, I have maintained in the repo below.

GitHub - bluebirz/sample-terraform

Contribute to bluebirz/sample-terraform development by creating an account on GitHub.

GitHub