Belajar OpenTofu - Reusable Modules & OpenTofu Registry

#Pendahuluan

Di episode 9 sebelumnya kita membahas state manipulation & import workflows — mengimpor infrastruktur eksisting lewat import block dan tofu import, lalu melakukan refactoring tanpa destroy memakai moved block dan tofu state. Infrastruktur kalian sudah tercatat rapi di state dan bisa dikelola dengan aman. Sekarang muncul pertanyaan berikutnya: bagaimana mencegah setiap tim menulis kode yang sama dari nol?

Tanpa modul, lima tim di perusahaan kalian akan mendeklarasikan VPC, security group, dan database masing-masing dengan cara yang sedikit berbeda. Satu tim membuka port SSH ke publik, tim lain lupa memasang encryption, dan yang paling parah — semuanya tampak "berfungsi" sehingga tidak ada yang menyadari inkonsistensinya sampai terjadi insiden.

Di episode ini kita akan membahas reusable modules & OpenTofu Registry: cara membungkus infrastruktur menjadi modul yang bisa dipakai ulang, struktur file standar main.tf, variables.tf, dan outputs.tf, serta cara mengkonsumsi modul dari OpenTofu Registry, repositori Git, atau local path.

#Pembahasan Utama

#Prinsip Modul: Mainan Lego

Modul adalah kumpulan resource OpenTofu yang dikemas sebagai satu kesatuan dengan input (variabel) dan output (nilai yang diekspos). Analogi terbaiknya adalah mainan Lego: kalian tidak merakit setiap roda gigi sendiri, melainkan memakai blok yang sudah jadi. Semua "configurasi default yang benar" di-encapsulate di dalam modul, dan konsumen cukup memberi input kecil.

Seluruh konfigurasi yang pernah kita tulis sejauh ini — termasuk modul itu sendiri — sebenarnya adalah root module. Bedanya: modul reusable dipanggil berkali-kali lewat block module, sedangkan root module hanya satu dan menjadi titik masuk eksekusi.

#Struktur Modul Reusable

Konvensi standar sebuah modul terdiri dari tiga file: main.tf untuk resource, variables.tf untuk input, dan outputs.tf untuk hasil:

resource "aws_vpc" "main" {
  cidr_block = var.cidr_block
  tags       = var.tags
}
 
resource "aws_subnet" "public" {
  count      = length(var.public_subnets)
  vpc_id     = aws_vpc.main.id
  cidr_block = var.public_subnets[count.index]
  tags = {
    Name = "public-${count.index}"
  }
}

variable "cidr_block" {
  type        = string
  description = "CIDR block untuk VPC"
}
 
variable "public_subnets" {
  type    = list(string)
  default = []
}
 
variable "tags" {
  type    = map(string)
  default = {}
}

output "vpc_id" {
  value = aws_vpc.main.id
}
 
output "public_subnet_ids" {
  value = aws_subnet.public[*].id
}

Perhatikan polanya: variables.tf mendefinisikan kontrak input dengan type, description, dan default; main.tf mengkonsumsinya lewat referensi var.nama; outputs.tf mengekspos nilai yang dibutuhkan pemanggil. Modul yang baik hanya mengekspos output yang benar-benar dibutuhkan, bukan seluruh atribut internal.

#Mengkonsumsi Modul dari OpenTofu Registry

OpenTofu Registry (registry.opentofu.org) adalah rumah publik untuk modul dan provider. Modul komunitas yang populer, seperti terraform-aws-modules/vpc/aws, bisa dipanggil langsung dengan penulisan singkat namespace/nama/provider:

module "vpc" {
  source = "registry.opentofu.org/terraform-aws-modules/vpc/aws"
  version = "5.0.0"
 
  name = "production"
  cidr = "10.0.0.0/16"
  azs  = ["ap-southeast-1a", "ap-southeast-1b"]
}
 
module "vpc_staging" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.0.0"
 
  name = "staging"
  cidr = "10.1.0.0/16"
  azs  = ["ap-southeast-1a"]
}

Dua hal yang perlu diperhatikan. Pertama, source bisa ditulis lengkap dengan host registry, atau singkat — host registry.opentofu.org dipakai secara default. Kedua, dua pemanggilan modul yang sama tidak masalah: setiap blok module menghasilkan instansiasi terpisah, masing-masing dengan inputnya sendiri. Inilah kekuatan "satu definisi, banyak instans".

#Sumber Modul: Registry, Git, dan Local Path

Tidak semua modul pantas dipublikasikan ke registry. OpenTofu mendukung tiga sumber utama:

Sumber Git memakai skema git::URL//subdir?ref=ref — garis miring ganda menunjuk ke direktori di dalam repo, dan ref mengunci ke branch, tag, atau commit tertentu:

module "vpc" {
  source  = "git::https://github.com/org/modules.git//vpc?ref=v1.0.0"
  cidr    = "10.0.0.0/16"
  subnets = ["10.0.1.0/24"]
}

Sementara local path paling cocok saat modul masih berkembang di repository yang sama dengan pemanggilnya — tidak perlu push ke registry untuk setiap perubahan:

module "vpc" {
  source  = "./modules/vpc"
  cidr    = "10.2.0.0/16"
  subnets = ["10.2.1.0/24"]
}

#Praktik Terbaik Modul

• Satu modul, satu tanggung jawab — modul yang terlalu besar sulit diuji dan dipakai ulang.
• Pin versi dan manfaatkan lock file untuk semua sumber modul.
• Dokumentasikan variabel dan output lewat description; sediakan README bila perlu.
• Uji modul sebelum dibagikan — OpenTofu punya framework tofu test native yang akan kita bahas di episode berikutnya.
• Komposisi via output — rantai modul dengan menyambungkan output satu modul ke input modul lain, bukan menyalin nilai.

#Penutup

Pada episode 10 ini kita membangun fondasi modularitas:

• Modul meng-encapsulate resource dengan input dan output, seperti blok Lego yang bisa dipakai berulang.
• Struktur standar main.tf, variables.tf, dan outputs.tf membentuk kontrak modul yang jelas.
• OpenTofu Registry menyediakan modul publik dengan penulisan source singkat dan version yang di-pin.
• Sumber lain: Git repository untuk modul privat, dan local path untuk pengembangan internal.
• Praktik terbaik: satu tanggung jawab, versi terkunci, dokumentasi, dan pengujian.

Dengan modul, kalian bisa membangun platform yang konsisten di banyak tim dan environment. Di episode 11 selanjutnya kita akan membahas Formatting, Linting & Native Testing Framework — merapikan kode dengan tofu fmt, memvalidasi dengan tofu validate, memindai dengan Checkov dan Trivy, lalu menulis pengujian .tftest.hcl memakai tofu test tanpa perlu Terratest. Sampai jumpa!