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 below.

Automate your project with Google Cloud Build
Google Cloud Build is one of the CI/CD tool, other you may hear the name are Jenkins and Github Action, for instance.

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 $(ls ../variables/*.tfvars); 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.

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.

buil

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.


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.