Infrastructure as Code dengan Terraform: Provisioning AWS Resources secara Declaratif

Mengapa Infrastructure as Code Penting

Menyediakan infrastruktur cloud melalui konsol web secara manual memakan waktu dan rentan terhadap kesalahan manusia. Satu klik yang salah atau pengaturan yang terlupakan dapat menyebabkan downtime atau celah keamanan. Ketika tim bertambah besar, inkonsistensi antara environment development dan production menjadi semakin sulit dikendalikan.

Infrastructure as Code (IaC) mengatasi masalah ini dengan mendefinisikan seluruh resource cloud dalam file teks yang dapat diverifikasi dan diulang. Konfigurasi tersebut disimpan di version control, sehingga setiap perubahan memiliki audit trail yang jelas. Kita bisa melakukan review pada perubahan infrastruktur sebelum diterapkan, sama seperti review kode aplikasi.

Terraform muncul sebagai salah satu tool IaC yang paling populer karena mendukung pendekatan deklaratif. Alih-alih menulis serangkaian perintah imperatif untuk membuat resource satu per satu, kita cukup mendeskripsikan state akhir yang diinginkan. Terraform akan menghitung delta antara state saat ini dan state yang diinginkan, kemudian mengeksekusi perubahan secara otomatis. Selain itu, Terraform mendukung ratusan provider, mulai dari AWS, Azure, Google Cloud, hingga platform on-premise seperti VMware.

Konfigurasi Dasar Terraform

Project Terraform terdiri dari satu atau lebih file dengan ekstensi .tf. Bahasa yang digunakan adalah HashiCorp Configuration Language (HCL), yang dirancang agar mudah dibaca oleh manusia sekaligus diproses oleh mesin.

Konsep pertama yang harus dipahami adalah provider. Provider merupakan plugin yang menjadi jembatan antara Terraform dan API platform cloud. Tanpa provider, Terraform tidak tahu cara berkomunikasi dengan AWS. Konsep kedua adalah resource, yang merepresentasikan komponen infrastruktur nyata, seperti VPC, subnet, atau EC2 instance. Konsep ketiga adalah variable, yang memungkinkan kita membuat konfigurasi menjadi dinamis tanpa harus mengubah nilai hardcoded di banyak tempat. Terakhir, output digunakan untuk mengekspos nilai penting setelah provisioning berhasil, misalnya public IP address atau endpoint database.

Berikut adalah konfigurasi minimal untuk menghubungkan Terraform dengan akun AWS:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "ap-southeast-1"
}

Blok terraform di atas mengunci versi provider agar tidak berubah secara tidak sengaja saat dijalankan di mesin lain. Region ap-southeast-1 menentukan wilayah Singapura sebagai lokasi deployment. Pendekatan ini memastikan environment lokal, CI/CD, dan rekan tim lain menghasilkan behavior yang identik.

Membuat VPC dan EC2 Instance di AWS

Setelah provider dikonfigurasi, kita bisa mulai mendefinisikan resource. Mari kita bangun satu set infrastruktur sederhana yang terdiri dari VPC, subnet publik, security group, dan satu EC2 instance. VPC memberikan isolasi jaringan. Subnet publik memungkinkan instance mendapatkan IP publik. Security group bertindak sebagai firewall virtual yang mengontrol traffic masuk dan keluar.

Contoh konfigurasi lengkap:

variable "vpc_cidr" {
  description = "CIDR block untuk VPC"
  default     = "10.0.0.0/16"
}

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true

  tags = {
    Name = "terraform-vpc"
  }
}

resource "aws_subnet" "public" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "ap-southeast-1a"
  map_public_ip_on_launch = true

  tags = {
    Name = "terraform-public-subnet"
  }
}

resource "aws_security_group" "ssh" {
  name        = "allow-ssh"
  description = "Security group untuk mengizinkan SSH"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "terraform-ssh-sg"
  }
}

resource "aws_instance" "web" {
  ami                    = "ami-0c02fb55956c7d316"
  instance_type          = "t3.micro"
  subnet_id              = aws_subnet.public.id
  vpc_security_group_ids = [aws_security_group.ssh.id]

  tags = {
    Name = "terraform-web-server"
  }
}

output "instance_public_ip" {
  description = "Public IP dari EC2 instance"
  value       = aws_instance.web.public_ip
}

Terraform membangun dependency graph secara otomatis berdasarkan referensi antar resource. aws_subnet bergantung pada aws_vpc melalui atribut vpc_id. aws_instance bergantung pada aws_subnet dan aws_security_group. Kita tidak perlu menulis urutan eksekusi secara manual. Terraform juga akan menunggu resource induk selesai dibuat sebelum melanjutkan ke resource anak. Pendekatan ini mengurangi kompleksitas orchestration secara signifikan.

Mengelola State dan Workflow Deployment

Terraform menyimpan snapshot dari infrastruktur yang sudah dibuat dalam file state. File ini berisi mapping antara nama resource di konfigurasi dengan ID resource nyata di cloud provider. State memungkinkan Terraform menentukan apakah sebuah resource perlu dibuat, dimodifikasi, atau dihapus pada run berikutnya.

Secara default, Terraform menyimpan state secara lokal dalam file terraform.tfstate. Pendekatan ini berfungsi untuk eksperimen pribadi, tetapi berisiko besar saat bekerja dalam tim. Jika dua orang menjalankan terraform apply secara bersamaan, state bisa rusak atau tertimpa. Solusinya adalah remote backend.

Amazon S3 adalah pilihan yang umum untuk menyimpan state file. Untuk mencegah race condition, kita mengaktifkan state locking dengan DynamoDB. Setiap kali Terraform berjalan, Terraform akan mengunci state terlebih dahulu. Jika proses lain mencoba berjalan secara bersamaan, proses tersebut akan menunggu sampai lock dilepaskan.

terraform {
  backend "s3" {
    bucket         = "my-terraform-state-bucket"
    key            = "vpc-ec2/terraform.tfstate"
    region         = "ap-southeast-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

Workflow standar Terraform dimulai dari terraform init. Perintah ini mengunduh provider plugin dan menginisialisasi remote backend. Selanjutnya, terraform validate memeriksa sintaks dan referensi resource agar tidak ada kesalahan konfigurasi sebelum dieksekusi. terraform plan menghasilkan execution plan yang merinci setiap perubahan yang akan terjadi. Kita harus selalu meninjau plan ini sebelum melanjutkan. terraform apply mengeksekusi plan setelah konfirmasi dari pengguna. Ketika resource sudah tidak dibutuhkan, terraform destroy akan menghapus seluruh resource yang dikelola oleh konfigurasi tersebut secara terurut.

Best Practices untuk Kolaborasi Tim

File konfigurasi Terraform harus selalu berada di version control, seperti Git. Setiap perubahan infrastruktur dapat direview melalui pull request, sehingga kesalahan dapat tertangkap sebelum masuk ke production. Penggunaan module sangat direkomendasikan untuk mengenkapsulasi pola infrastruktur yang sering digunakan. Sebagai contoh, modul VPC standar perusahaan dapat dipakai berulang kali oleh berbagai project tanpa menduplikasi kode.

Pemisahan environment — development, staging, dan production — dapat dilakukan dengan workspace atau direktori terpisah. Workspace memungkinkan kita menggunakan konfigurasi yang sama dengan state yang berbeda. Direktori terpisah memberikan isolasi yang lebih kuat jika konfigurasi antar environment memiliki perbedaan signifikan. Integrasi dengan CI/CD pipeline memungkinkan terraform plan dijalankan secara otomatis pada setiap commit atau pull request. Tim mendapatkan visibilitas penuh terhadap dampak perubahan infrastruktur sebelum approval diberikan.

Siap menguasai cloud computing dan automation secara praktis? Kunjungi kursus dan bootcamp di Rumah Coding untuk belajar langsung dari praktisi dan membangun portfolio project yang relevan dengan kebutuhan industri.