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.

flowchart TD
    A["Terraform\nRegistry"] --> B["Official\nProviders"]
    A --> C["Verified\nProviders"]
    A --> D["Community\nModules"]

    B --> E["hashicorp/aws\nhashicorp/azurerm"]
    C --> F["terraform-aws-modules\nGoogle Cloud modules"]
    D --> G["Custom modules\nfrom community"]

    style A fill:#3b82f6,stroke:#1e40af,color:#fff
    style B fill:#10b981,stroke:#059669,color:#fff
    style C fill:#f59e0b,stroke:#d97706,color:#fff
    style D fill:#8b5cf6,stroke:#6d28d9,color:#fff

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?
flowchart LR
    A["terraform init"] -->|"Download"| B["📦 Module dari\nRegistry"]
    B -->|"Cached in\n.terraform/"| C["Used in\nConfiguration"]

    style A fill:#3b82f6,stroke:#1e40af,color:#fff
    style B fill:#10b981,stroke:#059669,color:#fff
    style C fill:#f59e0b,stroke:#d97706,color:#fff

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 = {} }


Publishing Module ke Registry #

# Public Registry (registry.terraform.io):
# 1. Push ke GitHub dengan tag semver
git tag v1.0.0
git push origin v1.0.0
# 2. Login ke registry.terraform.io
# 3. Add module → Select GitHub repo
# 4. Terraform otomatis detect tag sebagai versi

# Private Registry (Terraform Cloud):
# 1. Push ke VCS connected ke TFC
# 2. TFC → Registry → Publish Module
# 3. Module hanya bisa diakses oleh org kamu
# Menggunakan module dari registry
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"
  
  name = "my-vpc"
  cidr = "10.0.0.0/16"
  
  azs             = ["ap-southeast-1a", "ap-southeast-1b"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24"]
  
  enable_nat_gateway = true
}

Private Module Registry Setup #

# Setup private registry di Terraform Cloud:
# 1. Connect VCS provider (GitHub/GitLab/Bitbucket)
# 2. Publish module → Select repository
# 3. Terraform auto-detect tags sebagai versi
# 4. Module tersedia di: app.terraform.io/{org}/{module}/{provider}

# Menggunakan module dari private registry
module "app" {
  source  = "app.terraform.io/my-org/app/aws"
  version = "~> 2.0"
}

Module Documentation #

# Auto-generate module documentation
brew install terraform-docs
terraform-docs markdown table . > README.md

# Contoh output:
# | Name | Description | Type | Default | Required |
# |------|-------------|------|---------|----------|
# | vpc_cidr | CIDR block untuk VPC | string | n/a | yes |
# | environment | Nama environment | string | n/a | yes |
# | enable_nat | Enable NAT gateway | bool | true | no |
# Publish module dengan dokumentasi yang baik
# 1. Write README.md dengan usage examples
# 2. Semua variable punya description
# 3. Semua output punya description
# 4. Include CHANGELOG.md
# 5. Git tag dengan semver (v1.2.3)

Module Publishing Checklist #

BEFORE PUBLISHING:

□ Semua variable punya description
□ Semua output punya description
□ README.md lengkap dengan usage examples
□ CHANGELOG.md mencatat semua perubahan
□ Tests passing (terraform validate, tflint)
□ Version tag dengan semver
□ License file ada
□ .gitignore tidak exclude file yang dibutuhkan
□ Examples directory dengan contoh penggunaan
□ Terraform-docs generate documentation
# Pre-publish validation
terraform fmt -check
terraform validate
tflint .
terraform-docs markdown . > README.md

# Tag and publish
git tag -a v1.0.0 -m "Release v1.0.0: Initial release"
git push origin v1.0.0

Module Dependency Graph #

DEPENDENCY ORDER:

1. Foundation modules (no dependencies)
   - networking (VPC, subnets)
   - security (KMS, IAM)
   
2. Platform modules (depends on foundation)
   - compute (needs networking)
   - database (needs networking)
   
3. Application modules (depends on platform)
   - monitoring (needs compute, database)
   - ci-cd (needs compute)
# Module version pinning strategy
# Root module pins exact version
module "networking" {
  source  = "app.terraform.io/my-org/networking/aws"
  version = "2.3.1"  # Exact pin for production
}

# Dev can use latest
module "networking" {
  source  = "app.terraform.io/my-org/networking/aws"
  version = "~> 2.0"  # Allow minor updates
}

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