Let's try: Terraform part 6 – CI/CD
in this series
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.
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 asgcs-dev.tfvars
and project name asproject-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.

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.