Belajar OpenTofu - Complete Production-Grade Enterprise OpenTofu Architecture

#Pendahuluan

Di episode 19 sebelumnya kita membahas Disaster Recovery & Encrypted State Recovery, memastikan bahwa bahkan ketika KMS key bermasalah, infrastruktur tetap bisa dipulihkan. Kini saatnya merangkai semuanya. Selama 20 episode kita telah membangun kemampuan satu per satu — dari pre-requisites di episode 0 hingga DR di episode 19 — dan di episode pamungkas ini semuanya bersatu.

Di episode 20 kali ini, kita akan merancang Complete Production-Grade Enterprise OpenTofu Architecture. Kita akan menggabungkan OpenTofu Engine, native client-side state encryption dengan AWS KMS, dynamic provider iteration, reusable modules, framework tofu test, Terragrunt dan Digger dengan GitHub Actions OIDC, gerbang policy OPA, serta drift detection otomatis. Kita tutup dengan checklist kesiapan produksi dan panduan code review.

#Gambaran Besar Arsitektur

Arsitektur enterprise bukan tentang satu tool, melainkan tentang bagaimana tool-tool bekerja sebagai satu sistem. Alur produksinya menjadi:

1. Developer menulis kode HCL di dalam reusable modules.
2. PR dibuka, pipeline GitHub Actions berjalan: format, validate, dan tofu test.
3. Setelah lolos, plan dibuat dan diuji dengan gerbang policy OPA.
4. Reviewer menyetujui, merge ke branch utama, dan apply dijalankan melalui OIDC.
5. State terenkripsi disimpan di backend remote dengan locking dan versioning.
6. Scheduled pipeline memeriksa drift setiap hari dan memperbaiki penyimpangan.

Setiap lapisan ini sudah kita bangun di episode sebelumnya — sekarang kita hanya menyatukannya.

#Fondasi: OpenTofu Engine dengan State Encryption

Fondasi arsitektur adalah OpenTofu Engine itu sendiri, dikombinasikan dengan native client-side state encryption menggunakan AWS KMS:

terraform {
  backend "s3" {
    bucket         = "org-opentofu-state"
    key            = "prod/opentofu.tfstate"
    region         = "ap-southeast-1"
    encrypt        = true
    dynamodb_table = "opentofu-state-lock"
  }
 
  encryption {
    key_provider "aws_kms" "main" {
      kms_key_id = "arn:aws:kms:ap-southeast-1:123456789012:key/kms-key"
    }
 
    method "aes_gcm" "main" {
      keys = key_provider.aws_kms.main
    }
 
    state {
      method = method.aes_gcm.main
    }
  }
}

State disimpan di S3 dengan versioning, dikunci lewat DynamoDB, dan dienkripsi dua lapis: server-side di S3 dan client-side oleh OpenTofu. Bahkan jika bucket bocor, state tetap berupa ciphertext yang tidak bisa dibaca tanpa key KMS.

#Dynamic Provider Iteration & Reusable Modules

Seluruh resource hidup di dalam modules, dan provider dikonfigurasi secara dinamis untuk mendukung banyak region dan environment. Seperti yang kita pelajari di episode 7 dan 10:

include "root" {
  path = find_in_parent_folders()
}
 
terraform {
  source = "../modules/vpc"
}
 
inputs = {
  env = "prod"
}

Dengan Terragrunt, backend dan provider dikonfigurasi sekali di root, lalu setiap environment (dev, staging, prod) cukup menunjuk module yang sama — tanpa menyalin konfigurasi. Dynamic provider iteration melengkapi ini sehingga satu modul bisa menyebar ke banyak region sekaligus.

#Kualitas: Framework Native tofu test

Sebelum kode menyentuh cloud, kualitasnya dipastikan dengan framework test bawaan OpenTofu:

run "bucket_private" {
  command = apply
 
  assert {
    condition     = google_storage_bucket.assets.force_destroy == false
    error_message = "Bucket assets tidak boleh force_destroy"
  }
}

Test ini memvalidasi invariant penting — bucket tidak boleh bisa dihancurkan secara tidak sengaja. Dengan tofu test, assertion berjalan di pipeline tanpa memerlukan bahasa pemrograman eksternal seperti Terratest.

#Pipeline: GitHub Actions dengan OIDC

Seluruh alur otomatis berjalan di GitHub Actions menggunakan OIDC — tanpa menyimpan kredensial AWS statis. Workflow berikut merangkum pipeline lengkap enterprise:

name: opentofu-pipeline
 
on:
  pull_request:
  push:
    branches: [main]
  schedule:
    - cron: "0 6 * * *"
 
permissions:
  id-token: write
  contents: read
  pull-requests: write
 
jobs:
  pipeline:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: opentofu/setup-opentofu@v1
 
      - name: Configure AWS OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-oidc
          aws-region: ap-southeast-1
 
      - name: Format, validate & test
        run: |
          tofu fmt -recursive -check
          tofu validate
          tofu test
 
      - name: Security scan
        run: checkov -d .
 
      - name: OPA policy gate
        run: |
          tofu plan -out=plan.tfplan
          tofu show -json plan.tfplan > plan.json
          opa eval --data policy/ --input plan.json \
            --fail-defined "data.infra.security.deny"
 
      - name: Apply to production
        if: github.event_name == 'push'
        run: tofu apply plan.tfplan -auto-approve

Perhatikan tiga lapis perlindungan di atas: tofu fmt -check dan tofu validate untuk kualitas, checkov untuk keamanan statis, dan gerbang OPA untuk compliance. Langkah apply hanya berjalan pada event push ke branch utama — yang artinya setiap perubahan produksi telah melewati review PR terlebih dahulu. Sementara itu, trigger schedule mengaktifkan drift detection setiap pagi, seperti yang kita rancang di episode 18.

#Checklist Kesiapan Produksi

Sebelum arsitektur ini disebut production-grade, pastikan semua item berikut terpenuhi:

• State: backend remote dengan locking, versioning, dan client-side encryption aktif.
• Kredensial: tidak ada secret di kode; semua akses cloud lewat OIDC atau secret manager.
• Modules: seluruh resource diorganisir dalam reusable modules dengan versi yang jelas.
• Testing: tofu test berjalan di pipeline untuk setiap PR.
• Security: Checkov dan Trivy memindai kode sebelum merge.
• Policy: gerbang OPA memblokir perubahan yang melanggar compliance.
• Drift: scheduled pipeline mendeteksi dan meremediasi drift secara otomatis.
• DR: prosedur pemulihan teruji dan dijalankan secara berkala.

#Panduan Code Review untuk OpenTofu

Code review infrastruktur memerlukan mata yang berbeda dari review aplikasi. Beberapa hal yang wajib diperiksa:

• Efek perubahan: apakah tofu plan menunjukkan perubahan yang sesuai ekspektasi?
• Destroy: adakah resource yang akan dihancurkan? Gunakan prevent_destroy untuk resource kritis.
• Sensitive data: apakah nilai rahasia ditandai sensitive = true dan tidak pernah dicetak?
• Scope: apakah perubahan terbatas pada module yang relevan?
• Konvensi: apakah tofu fmt sudah bersih dan nama variabel konsisten?
• Versioning: apakah provider dan module di-pin ke versi tertentu?

#Perjalanan 21 Episode

Selamat — kalian telah mencapai episode terakhir. Mari kita tengok kembali seluruh perjalanan:

• Episode 0-2: pre-requisites, setup environment, sejarah fork dari Terraform, dan core workflow tofu init, tofu plan, tofu apply.
• Episode 3-5: providers, resource declarations, variables, output, remote state, dan state locking.
• Episode 6-8: fitur eksklusif OpenTofu — native client-side state encryption, dynamic provider iteration, serta advanced expressions dan loops.
• Episode 9-11: state manipulation, import workflows, reusable modules, formatting, dan framework tofu test.
• Episode 12-14: integrasi Terragrunt, pipeline GitHub Actions dan GitLab CI, serta managed platforms dan Digger.
• Episode 15-16: secret management, state hardening, dan policy as code dengan OPA.
• Episode 17-19: provisioning multi-cloud, drift detection dan auto-remediation, serta disaster recovery dan encrypted state recovery.
• Episode 20: arsitektur enterprise production-grade yang menggabungkan semuanya.

#Penutup

Pada episode 20 ini, kita telah merancang Complete Production-Grade Enterprise OpenTofu Architecture — fondasi state terenkripsi dengan AWS KMS, dynamic provider iteration, reusable modules, framework tofu test, Terragrunt dan Digger dengan GitHub Actions OIDC, gerbang policy OPA, hingga drift detection otomatis — ditutup dengan checklist kesiapan produksi dan panduan code review.

Key takeaway:

• Arsitektur enterprise adalah integrasi tool, bukan sekadar satu tool.
• State terenkripsi plus locking dan versioning adalah fondasi yang tidak bisa ditawar.
• Dynamic provider iteration dan Terragrunt membuat multi-environment menjadi DRY.
• tofu test menjamin kualitas, Checkov menjaga keamanan, OPA menjaga compliance.
• OIDC menghilangkan kredensial statis dari pipeline.
• Drift detection otomatis membuat infrastruktur selalu converge ke kode.
• Checklist dan code review yang disiplin melindungi produksi dari kesalahan manusia.

Perjalanan kalian dimulai dari menjalankan tofu init pertama di episode 2, dan kini berakhir dengan kemampuan merancang arsitektur yang setara dengan yang digunakan perusahaan kelas dunia. OpenTofu adalah bukti bahwa infrastruktur open-source sepenuhnya bisa menjadi tulang punggung produksi — tanpa lock-in, tanpa biaya lisensi tersembunyi, dan dengan komunitas yang terus berkembang.

Terima kasih sudah bertahan hingga episode ke-20. Jangan berhenti di sini — terapkan yang kalian pelajari di project nyata, bagikan ilmu ke sesama engineer, dan teruslah membangun. Sampai jumpa di series berikutnya!