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.
Ok, we would reuse the files from the latest blog and have them in this structure.
moduleshas only GCS module and its variables
src, we split into backend, main, provider, and variables file
variables, we split variables into 2 files; GCS as
gcs-dev.tfvarsand project name as
Also there are other 2 files we didn't make it before in this series. They are:
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"
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.
Get into folder
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"
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.
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
Try once manually
Let's run it by hand just once.
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.
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.