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:#fffApa 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:#fffPrivate 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-modulesadalah 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? →