Next advance topic GitLab and Terraform

I’ll go over this topic this weekend, as it will also help me refresh my own memory of it.

In earlier topics, we have to manually create the Amazon AWS EC2 cloud instance manually but with Terraform – A tool from HashiCorp that lets us define infrastructure as code and it allows us to automate the provision of this instance automatically through hcl code (HashiCorp Configuration Language) and it is file with .tf extension — for example1: main.tf

resource "aws_instance" "example" {
ami = "ami-123456"
instance_type = "t2.micro"
}

When we run terraform apply, it creates that infrastructure automatically (terraform loads *.tf, read them and execute)

example2: .gitlab-ci.yml

stages:
- validate
- plan
- apply

variables:
TF_ROOT: "./" # location of terraform files
TF_STATE_NAME: "default"
TF_IN_AUTOMATION: "true"

before_script:
- cd $TF_ROOT
- terraform init -input=false

validate:
stage: validate
script:
- terraform validate

plan:
stage: plan
script:
- terraform plan -out=tfplan
artifacts:
paths:
- $TF_ROOT/tfplan

apply:
stage: apply
script:
- terraform apply -auto-approve tfplan
when: manual # requires manual approval

In short, with Terraform, we can use it to define infrastructure as code as seen above so it allows us to automate the infrastructure (AWS, GCP, Azure, etc.) through GitLab Pipelines instead of manual provisioning. It’s very useful since manual processes are typically more prone to errors than automated ones.

e.g we would have a GitLab project that is responsible to automate the infrastructure of the cloud providers like AWS, Google Cloud Platform (GCP), Azure etc. and another GitLab project that is responsible to do the actual software development on that said infrastructure.

And with this automation of the infrastructure of the cloud providers we can quickly provision them through code – hcl code. It is an advance topic.