Registry #

Terraform Registry di registry.terraform.io adalah repositori publik yang berisi ribuan module siap pakai — dari VPC dan EKS di AWS hingga cluster Kubernetes di GCP dan Azure. Menggunakan module dari Registry bisa menghemat waktu yang signifikan, tapi hanya jika module yang dipilih memang tepat untuk kebutuhanmu. Artikel ini membahas cara menavigasi Registry secara efektif, kapan menggunakannya, dan kapan lebih baik menulis module sendiri.

Apa itu Terraform Registry #

Terraform Registry adalah direktori terpusat untuk:

registry.terraform.io berisi:

PROVIDERS
  Semua provider yang bisa digunakan di Terraform
  (hashicorp/aws, hashicorp/google, cloudflare/cloudflare, dll.)

MODULES
  Module yang bisa langsung dipanggil sebagai child module
  Dikategorikan berdasarkan provider dan fungsi

Dua kategori module di Registry:

  VERIFIED ✓
    Ditulis dan dikelola oleh HashiCorp atau partner resmi
    Review kualitas lebih ketat
    Contoh: hashicorp/consul/aws

  COMMUNITY
    Ditulis oleh komunitas
    Kualitas bervariasi — perlu evaluasi lebih cermat
    Contoh: terraform-aws-modules/vpc/aws

terraform-aws-modules: Koleksi Module AWS Terpopuler #

terraform-aws-modules adalah koleksi module open-source yang paling banyak digunakan untuk AWS — ditulis dan dikelola oleh komunitas aktif dengan ratusan kontributor.

# Module VPC yang paling banyak digunakan
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  name = "production-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["ap-southeast-1a", "ap-southeast-1b", "ap-southeast-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = false  # NAT Gateway per-AZ untuk HA

  tags = {
    Environment = "production"
    ManagedBy   = "terraform"
  }
}

# Module EKS
module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.0"

  cluster_name    = "production-eks"
  cluster_version = "1.29"

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  eks_managed_node_groups = {
    general = {
      min_size     = 2
      max_size     = 5
      desired_size = 2
      instance_types = ["t3.medium"]
    }
  }
}

# Module RDS
module "rds" {
  source  = "terraform-aws-modules/rds/aws"
  version = "~> 6.0"

  identifier        = "production-db"
  engine            = "postgres"
  engine_version    = "15"
  instance_class    = "db.t3.medium"
  allocated_storage = 100

  db_name  = "appdb"
  username = "dbadmin"

  vpc_security_group_ids = [module.security_group.security_group_id]
  subnet_ids             = module.vpc.database_subnets
}

Cara Mengevaluasi Module di Registry #

Tidak semua module yang ada di Registry layak dipakai di production. Gunakan kriteria ini sebelum memutuskan.

KRITERIA EVALUASI MODULE:

KEPERCAYAAN:
  □ Apakah dari namespace yang dikenal? (terraform-aws-modules, hashicorp)
  □ Jumlah download — module populer lebih banyak diuji
  □ Jumlah kontributor dan aktivitas commit terakhir
  □ Berapa issue open yang belum diselesaikan?

KUALITAS KODE:
  □ Apakah ada README yang lengkap dengan contoh?
  □ Apakah ada file examples/ yang bisa langsung dijalankan?
  □ Apakah variable punya deskripsi dan validasi?
  □ Apakah output mencakup semua atribut yang umum dibutuhkan?

KESESUAIAN:
  □ Apakah module melakukan persis yang kamu butuhkan?
  □ Apakah terlalu opinionated untuk kebutuhanmu?
  □ Apakah kamu akan bergantung pada fitur yang mungkin berubah?
  □ Apakah lisensinya kompatibel dengan kebutuhan organisasi?

Private Registry #

Untuk modul internal yang tidak ingin dipublikasikan, organisasi bisa menggunakan private registry. Ada beberapa opsi.

# OPSI 1: Terraform Cloud / HCP Terraform Private Registry
# Module di-upload dan dikelola via UI atau API
module "vpc" {
  source  = "app.terraform.io/my-org/vpc/aws"
  version = "~> 2.0"
  # Terraform Cloud menangani authentication dan versioning
}

# OPSI 2: Git repository dengan tag — paling sederhana
# Tidak butuh infrastruktur tambahan
module "vpc" {
  source = "git::https://github.com/my-org/terraform-module-vpc.git?ref=v2.1.0"
}

# Atau dengan SSH untuk private repo
module "vpc" {
  source = "git::ssh://[email protected]/my-org/terraform-module-vpc.git?ref=v2.1.0"
}

# OPSI 3: Gitea, GitLab, atau Bitbucket sebagai module registry
# GitLab punya built-in Terraform Module Registry
module "vpc" {
  source  = "gitlab.example.com/infrastructure/vpc/aws"
  version = "~> 1.0"
}

Kapan Menggunakan Registry vs Menulis Sendiri #

GUNAKAN MODULE DARI REGISTRY JIKA:
  ✓ Module sudah proven dan well-maintained (banyak download, aktif)
  ✓ Kebutuhanmu sesuai dengan apa yang module lakukan
  ✓ Kamu tidak punya persyaratan keamanan atau compliance yang melarang
    penggunaan kode eksternal
  ✓ Module punya fleksibilitas yang cukup via variable

TULIS MODULE SENDIRI JIKA:
  ✗ Kebutuhanmu sangat spesifik dan berbeda dari yang ada di Registry
  ✗ Module yang tersedia terlalu kompleks dan banyak fitur yang tidak dibutuhkan
  ✗ Ada persyaratan compliance yang mengharuskan audit semua kode
  ✗ Module Registry terlalu sering berubah interface-nya dan upgrade mengganggu
  ✗ Kebutuhan kustomisasi sangat dalam sehingga lebih mudah tulis dari awal

PERTIMBANGKAN HYBRID:
  ✓ Fork module publik dan modifikasi untuk kebutuhan internal
    — kamu mendapat pondasi yang teruji, tapi kontrol penuh
  ✓ Bungkus module publik dalam module internal
    — sembunyikan kompleksitas module publik di balik interface yang lebih sederhana

# Pola wrapper: bungkus module publik dengan interface yang lebih sederhana
# modules/internal-vpc/main.tf

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  # Konfigurasi yang sudah opinionated untuk standar internal
  name = var.name
  cidr = var.cidr

  # AZ dan subnet dihitung otomatis — pemanggil tidak perlu tahu detail ini
  azs             = data.aws_availability_zones.available.names
  private_subnets = [for k, v in data.aws_availability_zones.available.names : cidrsubnet(var.cidr, 4, k)]
  public_subnets  = [for k, v in data.aws_availability_zones.available.names : cidrsubnet(var.cidr, 4, k + 8)]

  # Standar internal yang tidak bisa di-override
  enable_nat_gateway   = true
  single_nat_gateway   = false
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = merge(var.tags, local.mandatory_tags)
}

# Interface yang jauh lebih sederhana untuk pengguna internal
# Hanya butuh 2 variable wajib:
variable "name" { type = string }
variable "cidr" { type = string }
variable "tags" { type = map(string); default = {} }

Ringkasan #

  • Terraform Registry berisi ribuan module provider dan module siap pakai — titik pertama yang harus diperiksa sebelum menulis module dari nol.
  • terraform-aws-modules adalah koleksi module AWS paling terpercaya di komunitas — VPC, EKS, RDS, dan puluhan module lainnya.
  • Evaluasi module dengan cermat sebelum digunakan di production — jumlah download, aktivitas maintenance, kualitas dokumentasi, dan kesesuaian dengan kebutuhan.
  • Private registry bisa menggunakan Terraform Cloud, atau cukup Git repository dengan tag untuk kebutuhan sederhana.
  • Wrapper module adalah pola yang kuat — bungkus module publik dengan interface yang lebih sederhana dan opinionated sesuai standar internal organisasi.
  • Tulis sendiri jika kebutuhanmu terlalu spesifik, ada persyaratan compliance, atau module publik yang tersedia terlalu kompleks untuk kebutuhanmu.

← Sebelumnya: Interface Design   Berikutnya: Apa itu Environment? →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact