PEBD6027 · RPS minggu 11 · 2x50 menit
Terraform IaC Infrastructure as Code · HCL · State · Module · Plan/Apply Workflow Hari ini kita masuk Infrastructure as Code IaC dengan Terraform. Setelah compute storage networking database security manual via console, sekarang bagaimana otomasi semua itu. Terraform adalah tool de-facto IaC multi-cloud. Setelah hari ini, Anda bisa mendefinisikan infra dalam kode, version di Git, deploy konsisten ke dev staging prod. Konteks Indonesia: Bank Jago dan fintech modern pakai Terraform untuk reproducibility dan compliance audit. Buku pegangan: Brikman Terraform Up and Running edisi ke-2. Peta Pembelajaran Hari Ini Sub-CPMK 10: menerapkan Terraform untuk provisioning AWS. Empat indikator.
IaC konsep & manfaat HCL anatomi: provider, resource, variable State file & backend remote Module reusable pattern Workflow: init, plan, apply, destroy Best practice: GitOps & lock state Posisi 14P: setelah IAM P9, hari ini Terraform IaC. P11 Kubernetes container orchestration.
Empat indikator: tulis HCL dasar, manage state remote, design module reusable, jalankan workflow plan-apply. IaC mengubah infra dari click-ops manual menjadi kode version. Manfaat: reproducible, auditable, reviewable via PR, disaster recovery cepat. Studi HashiCorp 2023 menunjukkan tim yang pakai Terraform reduce deployment time 60 sampai 80 persen dan human error 90 persen. Kita akan tulis Terraform konkret untuk VPC dan EC2. Mengapa Infrastructure as Code (IaC)? IaC = definisikan infra dalam kode. Bukan click di console manual. Manfaat strategis.
Reduksi Human Error
~90%
Studi HashiCorp 2023 — konfigurasi otomatis vs manual
Speed Deploy
60-80%
Provisioning 50 server: dari jam ke menit
Click-ops manual tidak sustainable. Tidak audit trail, tidak reproducible, dan drift antar environment pasti terjadi.
Infrastructure as Code IaC adalah definisikan infra dalam kode, bukan click di console manual. Manfaat strategis. Studi HashiCorp 2023 menunjukkan reduksi human error sekitar 90 persen dengan konfigurasi otomatis vs manual. Speed deploy 60 sampai 80 persen: provisioning 50 server dari jam menjadi menit. Click-ops manual tidak sustainable. Tidak audit trail karena tidak ada PR review, tidak reproducible karena sulit ulang, dan drift antar environment dev staging prod pasti terjadi karena manual. IaC solve semua ini: kode version di Git, review via PR, deploy konsisten. Tools populer: Terraform, CloudFormation, Pulumi, CDK. Bagian 1 · 1/4
HCL Anatomy
Diskusi: bila startup punya 3 environment dev staging prod, bagaimana cara konsisten infra?
Jawaban: IaC dengan Terraform workspace atau module terpisah per env. Definisikan VPC EC2 RDS dalam kode HCL sekali, deploy ke dev staging prod dengan variable berbeda. Konsistensi guaranteed. Tanpa IaC, tim akan click manual di console untuk 3 env, drift pasti terjadi, debug sulit. Pola populer: 1 module reusable, 3 root module call dengan tfvars berbeda per env. State file terpisah per env untuk isolasi blast radius. HCL Block: Provider, Resource, Variable Tiga block fundamental HCL. Pahami sebelum tulis kode Terraform.
# Provider declaration
provider "aws" {
region = "ap-southeast-3"
}
# Resource: EC2 instance
resource "aws_instance" "web" {
ami = "ami-0abc123"
instance_type = var.instance_type
tags = { Name = "web-server" }
}
# Variable
variable "instance_type" {
type = string
default = "t3.micro"
} Plugin cloud target aws, google, azurerm Konfigurasi region & credential Version via required_providers Resource infra nyata aws_instance, aws_s3_bucket Argument sesuai dokumentasi Computed: id, arn, ip Input parameter kode type, default, validation Dilewatkan via tfvars Output untuk expose value HCL mirip JSON tapi lebih readable. Comment dengan #. String bisa di-interpolasi ${var.x}.
Tiga block fundamental HCL HashiCorp Configuration Language. Provider adalah plugin cloud target seperti aws google azurerm, konfigurasi region dan credential, version via required providers. Resource adalah resource infra nyata seperti aws instance aws s3 bucket, argument sesuai dokumentasi, computed attribute seperti id arn ip. Variable adalah input parameter kode dengan type default validation, dilewatkan via tfvars file, output untuk expose value. HCL mirip JSON tapi lebih readable, comment dengan hashtag, string bisa di-interpolasi dollar kurung kurawal var x. Contoh kode menunjukkan provider AWS region ap-southeast-3, resource aws instance dengan ami dan instance type dari variable, variable instance type dengan default t3.micro. Terraform State File State = mapping realitas infra ke kode. File JSON, wajib di-manage dengan baik.
Track resource yang dibuat Terraform Detect drift realita vs kode Enable plan: preview changes Performance cache resource attribute Remote backend: S3 + DynamoDB lock Jangan commit ke Git (sensitif) Workspace terpisah per env State locking wajib (no concurrent apply) State berisi sensitive value (password, key). Remote backend + encryption wajib. Jangan commit ke Git.
Terraform State file adalah mapping realitas infra ke kode. File JSON, wajib di-manage dengan baik. Fungsi State: track resource yang dibuat Terraform, detect drift realita vs kode, enable plan untuk preview changes, performance cache resource attribute. Best practice State: remote backend S3 plus DynamoDB lock untuk team collaboration, jangan commit ke Git karena berisi sensitive value, workspace terpisah per env untuk isolasi blast radius, state locking wajib untuk no concurrent apply. State berisi sensitive value seperti password key. Remote backend plus encryption wajib. Terraform Cloud atau Spacelift untuk managed state dan collaboration. AWS S3 plus DynamoDB adalah pattern remote backend paling umum. Studi Kasus: Bank Jago GitOps Terraform Bank Jago pakai GitOps workflow dengan Terraform untuk provisioning 50+ AWS account.
Bank Jago pattern (public case study AWS, dihedge): Terraform Enterprise sebagai control plane, 1 repository Git per AWS account, PR review wajib 2 approver dari DevOps & Security team, plan otomatis di CI comment PR, apply manual setelah merge, state lock via DynamoDB, audit via CloudTrail + Terraform Enterprise log.
Manual click per akun Drift antar env pasti Audit sulit Onboarding akun baru: minggu Module reusable per tipe akun Konsisten 100% Audit via Git history Onboarding: 1 hari Pelajaran Bisdig: IaC bukan teknis semata tapi governance. Compliance audit lebih mudah dengan Git history.
Bank Jago pakai GitOps workflow dengan Terraform untuk provisioning 50+ AWS account. Public case study AWS dihedge menunjukkan pattern: Terraform Enterprise sebagai control plane, 1 repository Git per AWS account untuk audit trail, PR review wajib 2 approver dari DevOps dan Security team, plan otomatis di CI comment PR untuk transparency, apply manual setelah merge untuk human gate, state lock via DynamoDB untuk no concurrent, audit via CloudTrail plus Terraform Enterprise log. Pra-Terraform: manual click per akun, drift antar env pasti, audit sulit, onboarding akun baru butuh minggu. Pasca-Terraform: module reusable per tipe akun, konsisten 100 persen, audit via Git history, onboarding 1 hari. Pelajaran Bisdig: IaC bukan teknis semata tapi governance. Hitung dari Nol: ROI Terraform untuk Startup Startup fintech 3 env (dev/staging/prod), 30 resource per env, onboarding 2x/bulan. Berapa ROI?
Langkah Aktivitas Time Save 1 Provision manual 30 resource (console) 8 jam × $50 = $400 2 Provision Terraform (apply) 30 menit × $50 = $25 3 Hemat per deploy $375 × 3 env = $1125 4 Deploy 2x/bulan × 12 = 24/bln $1125 × 24 = $27K/tahun 5 Initial Terraform setup cost 2 minggu × $50 × 40 = $4000 6 Maintenance cost (10%/tahun) $50/bln × 12 = $600 7 Net benefit tahun-1 $27K - $4600 = $22K+ 8 Plus: konsistensi, audit, no drift Bonus non-finansial (regulator)
Harga engineering $50/jam (dihedge). Bonus: compliance audit lebih mudah dengan Git history Terraform.
Mari hitung ROI Terraform untuk startup fintech dengan 3 env dev staging prod, 30 resource per env, onboarding 2 kali per bulan. Langkah 1 provision manual 30 resource via console: 8 jam kali 50 dolar setara 400 dolar. Langkah 2 provision Terraform apply: 30 menit kali 50 dolar setara 25 dolar. Langkah 3 hemat per deploy: 375 dolar kali 3 env setara 1125 dolar. Langkah 4 deploy 2 kali per bulan kali 12 setara 24 per bulan: 1125 kali 24 setara 27 ribu dolar per tahun. Initial Terraform setup cost 2 minggu kali 50 kali 40 setara 4000 dolar. Maintenance 10 persen per tahun 50 dolar per bulan kali 12 setara 600 dolar. Net benefit tahun pertama 27 ribu dikurangi 4600 setara 22 ribu dolar plus. Plus konsistensi audit no drift bonus non-finansial regulator. Bagian 2 · 2/4
Module & Reusability
Diskusi: bila startup punya 5 microservice yang semua butuh VPC+EC2+RDS, bagaimana DRY?
Jawaban: Terraform module. Definisikan 1 module microservice-infra dengan input service_name, env, instance_count. Panggil 5 kali dengan variable berbeda untuk 5 microservice. DRY don't repeat yourself. Module = function Terraform. Parameter via variable, output expose attribute. Pola: 1 modules folder dengan reusable module, multiple env folder dengan root module call. Terraform Registry publik untuk module community seperti terraform-aws-modules. Module Terraform Module = function Terraform. Kumpulan resource yang reusable dengan input variable dan output.
Folder dengan .tf files variables.tf: input outputs.tf: expose value main.tf: logic source: path lokal atau Registry Input via arguments Output di-read via module.NAME.ATTR Version pinning wajib Module = DRY untuk infra. 1 module bisa dipanggil banyak kali dengan variable berbeda.
Module Terraform adalah function Terraform. Kumpulan resource yang reusable dengan input variable dan output. Anatomi module: folder dengan dot tf files, variables tf untuk input, outputs tf untuk expose value, main tf untuk logic. Pemakaian module: source path lokal atau Registry Terraform, input via arguments, output di-read via module dot NAME dot ATTR, version pinning wajib untuk reproducibility. Module sama dengan DRY don't repeat yourself untuk infra. 1 module bisa dipanggil banyak kali dengan variable berbeda. Pola populer: 1 modules folder dengan reusable module, multiple env folder dengan root module call. Terraform Registry publik untuk module community seperti terraform-aws-modules yang sudah audited. Terraform Registry Registry = NPM/GitHub untuk Terraform module. Pre-built module AWS resmi & community.
terraform-aws-modules/vpc terraform-aws-modules/eks terraform-aws-modules/rds Maintained oleh AWS engineer Pin version (jangan latest) Review source code module Audit security via SAST Contribute upstream bila ada bug Jangan pakai module community tanpa audit. Module bisa berisi backdoor. Stick ke verified AWS/HashiCorp.
Terraform Registry adalah NPM atau GitHub untuk Terraform module. Pre-built module AWS resmi dan community. Official modules: terraform-aws-modules slash vpc, terraform-aws-modules slash eks, terraform-aws-modules slash rds, maintained oleh AWS engineer. Best practice pemakaian: pin version jangan latest untuk reproducibility, review source code module sebelum pakai, audit security via SAST static analysis, contribute upstream bila ada bug. Jangan pakai module community tanpa audit karena module bisa berisi backdoor. Stick ke verified AWS atau HashiCorp yang sudah audited. HashiCorp also provide Sentinel policy as code untuk governance module pemakaian di enterprise. Workspace & Multi-Env Strategy Tiga strategi manage multi-env dengan Terraform. Trade-off complexity vs isolation.
Strategi Trade-off Use Case Workspace (tf vars) 1 module, multiple state workspace Env identik, isolasi rendah Directory per env Folder terpisah, state terisolasi Env berbeda (umumnya) Terragrunt wrapper DRY config + state isolate Team besar, banyak account Module per service 1 module, N root call Microservice banyak Terraform Cloud State managed, VCS integration Enterprise, compliance ketat
Aturan praktis: production = directory per env (isolasi maksimal). Workspace hanya untuk dev/test.
Tiga strategi manage multi-env dengan Terraform dengan trade-off complexity vs isolation. Workspace tf vars: 1 module multiple state workspace, isolasi rendah, untuk env identik. Directory per env: folder terpisah state terisolasi, untuk env berbeda umumnya. Terragrunt wrapper: DRY config plus state isolate, untuk team besar banyak account. Module per service: 1 module N root call, untuk microservice banyak. Terraform Cloud: state managed VCS integration, untuk enterprise compliance ketat. Aturan praktis: production sama dengan directory per env untuk isolasi maksimal. Workspace hanya untuk dev test dimana blast radius rendah bila ada kesalahan konfigurasi. Bagian 3 · 3/4
Workflow & Best Practice
Diskusi: bila tim DevOps 5 orang semua bisa apply Terraform, bagaimana cegah chaos?
Jawaban: GitOps workflow. PR wajib untuk semua perubahan. CI auto-run terraform plan dan comment ke PR. Reviewer approve based on plan output. Apply manual setelah merge ke main branch. State lock via DynamoDB mencegah concurrent apply. Audit trail via Git history + CloudTrail. Bila chaos, revert PR + re-apply. Pola ini dipakai Bank Jago dan Tokopedia. Terraform Cloud atau Atlantis atau Spacelift untuk orchestrate GitOps. Workflow: init, plan, apply, destroy Empat command fundamental Terraform. Pahami lifecycle infra sebagai kode.
Command Fungsi Kapan Dipakai terraform init Download provider & module Setelah clone repo / add module baru terraform fmt Format kode HCL rapi Pre-commit hook terraform validate Cek syntax & type Pre-commit, CI terraform plan Preview changes (no apply) Sebelum apply, comment di PR terraform apply Provision real infra Setelah approve PR terraform destroy Delete semua resource Cleanup, hapus env
Plan selalu sebelum apply. Apply dengan -auto-approve hanya di dev. Production: manual review.
Empat command fundamental Terraform. Init download provider dan module, setelah clone repo atau add module baru. Format kode HCL rapi, pre-commit hook. Validate cek syntax dan type, pre-commit dan CI. Plan preview changes tanpa apply, sebelum apply dan comment di PR. Apply provision real infra, setelah approve PR. Destroy delete semua resource, cleanup atau hapus env. Plan selalu sebelum apply. Apply dengan -auto-approve hanya di dev. Production: manual review dan apply setelah PR merge. CI pipeline auto-run fmt validate plan, apply manual gated. Workflow ini memastikan setiap perubahan ter-audit dan tidak ada konfigurasi liar. Terraform vs CloudFormation vs Pulumi Tiga tool IaC populer. Trade-off: bahasa, multi-cloud, maturity, community.
Aspek Terraform CloudFormation Pulumi Bahasa HCL (custom) JSON/YAML TS/Python/Go/C# Multi-cloud Ya (AWS, GCP, Azure) Tidak (AWS only) Ya Maturity Sangat matang (2014) Sangat matang (AWS) Cukup matang (2018) Community Terbesar (HashiCorp) AWS-specific Growing State Manual/Cloud Managed AWS Managed Pulumi SaaS Learning curve HCL mudah YAML verbose Butuh coding skill Best For Multi-cloud, mature AWS-only, native Dev dengan coding skill
Pilihan tergantung strategi: multi-cloud → Terraform. AWS-only native → CloudFormation. Dev friendly → Pulumi.
Tiga tool IaC populer dengan trade-off bahasa multi-cloud maturity community. Terraform bahasa HCL custom, multi-cloud AWS GCP Azure, sangat matang sejak 2014 HashiCorp, community terbesar, state manual atau Terraform Cloud. CloudFormation bahasa JSON YAML, AWS only, sangat matang sebagai AWS native, community AWS-specific, state managed AWS. Pulumi bahasa TypeScript Python Go C-sharp, multi-cloud, cukup matang sejak 2018, community growing, state managed Pulumi SaaS. Learning curve: HCL mudah, YAML verbose, Pulumi butuh coding skill. Pilihan tergantung strategi: multi-cloud ke Terraform, AWS-only native ke CloudFormation, Dev dengan coding skill ke Pulumi. Sebagian besar perusahaan Indonesia pakai Terraform karena multi-cloud dan talent pool. GitOps Workflow dengan Atlantis/TF Cloud GitOps = PR-driven Terraform apply. Audit trail penuh via Git history. Standard enterprise.
Developer buka PR dengan .tf changes CI run terraform plan Atlantis comment plan output ke PR Reviewer approve based on plan Merge PR ke main branch Atlantis auto-run terraform apply CloudTrail log setiap API call Audit trail via Git + CloudTrail Atlantis open-source. Terraform Cloud SaaS managed. Spacelift & Scalr enterprise variant.
GitOps adalah PR-driven Terraform apply. Audit trail penuh via Git history. Standard enterprise. Cara kerja: developer buka PR dengan dot tf changes, CI run terraform plan, Atlantis comment plan output ke PR untuk transparency, reviewer approve based on plan. Apply workflow: merge PR ke main branch, Atlantis auto-run terraform apply, CloudTrail log setiap API call, audit trail via Git plus CloudTrail. Atlantis open-source bisa self-hosted. Terraform Cloud SaaS managed dengan collaboration feature. Spacelift dan Scalr enterprise variant dengan policy as code dan multi-cloud. Pola GitOps ini dipakai Bank Jago dan Tokopedia untuk governance infra perubahan. Bonus: PR-based review meningkatkan knowledge sharing dan reduce bus factor. Bagian 4 · 4/4
Security & Drift Management
Diskusi: bila developer darurat hotfix via console AWS (bukan Terraform), apa yang terjadi?
Jawaban: drift. Terraform state tidak match realitas. Bila terraform apply berikutnya run, bisa overwrite perubahan darurat atau gagal. Solusi: terraform import untuk import realita ke state, atau terraform refresh untuk sync state dengan realita, lalu update kode Terraform untuk match. Long-term: disable console access untuk production, force semua perubahan via Terraform PR. AWS Config rules bisa detect drift dan alert. Brikman bab 5 mendalami ini. Terraform Security: tfvars & Secrets Sensitive value (password, key) tidak boleh hardcoded. Pakai AWS Secrets Manager atau SSM Parameter Store.
Hardcoded password di .tf tfvars commit ke Git State file tanpa encryption Access key di provider block AWS Secrets Manager + data source tfvars via env variable atau SOPS State backend S3 encryption + KMS Provider via IAM role/SSO SOPS Mozilla untuk encrypt tfvars. AWS Secrets Manager untuk app secret. Jangan hardcoded password.
Sensitive value seperti password key tidak boleh hardcoded di Terraform. Pakai AWS Secrets Manager atau SSM Parameter Store. Yang salah: hardcoded password di dot tf, tfvars commit ke Git, state file tanpa encryption, access key di provider block. Yang benar: AWS Secrets Manager plus data source Terraform, tfvars via environment variable atau SOPS Mozilla, state backend S3 encryption plus KMS, provider via IAM role atau SSO. SOPS Mozilla untuk encrypt tfvars dengan KMS PGP. AWS Secrets Manager untuk app secret dengan auto-rotation. Jangan hardcoded password dalam kode Terraform apapun alasannya. tfsec dan checkov adalah SAST tools untuk scan Terraform code terhadap security best practice. Drift Detection & Remediation Drift = realita infra berbeda dari Terraform state. Wajib dideteksi & diperbaiki.
Manual hotfix via console Resource dimodifikasi tools lain AWS auto-healing/resource schedule Resource dihapus manual terraform plan detect drift AWS Config rule continuous terraform refresh sync state Update kode Terraform match realita Drift wajib diperbaiki dengan update kode Terraform, bukan terraform apply yang overwrite. Kode = source of truth.
Drift adalah realita infra berbeda dari Terraform state. Wajib dideteksi dan diperbaiki. Penyebab drift: manual hotfix via console darurat, resource dimodifikasi tools lain seperti kubectl untuk K8s, AWS auto-healing atau resource schedule, resource dihapus manual oleh tim lain. Deteksi dan remediasi: terraform plan detect drift via diff, AWS Config rule continuous monitoring, terraform refresh sync state dengan realita, update kode Terraform match realita. Drift wajib diperbaiki dengan update kode Terraform, bukan terraform apply yang overwrite perubahan. Kode adalah source of truth. Long-term solution: disable console access untuk production, force semua perubahan via Terraform PR. AWS CloudFormation Drift Detection adalah fitur native untuk CFN. Widget: HCL ↔ AWS Resource Mapper Klik tab di atas (provider, ec2, vpc, s3, rds, sg, iam) untuk lihat kode HCL di kiri dan resource AWS yang dibuat di kanan. Perhatikan bagaimana referensi aws_vpc.main.id membuat dependency graph otomatis.
Baik, sekarang mari kita klik tab ec2 dulu. Lihat blok kiri, ini deklarasi paling sering Anda pakai. Ami menentukan sistem operasi, instance_type menentukan CPU RAM, subnet_id dan vpc_security_group_ids adalah referensi ke resource lain. Di kanan lihat AWS akan membuat satu EC2 dengan tag wajib Owner dan Environment. Sekarang klik tab vpc, perhatikan aws_subnet memakai aws_vpc.main.id, ini dependency, Terraform otomatis membuat VPC dulu sebelum subnet, Anda tidak perlu urut manual. Klik tab iam, lihat assume_role_policy pakai jsonencode, ini trust policy yang mengizinkan Lambda memakai role. Ringkasan Kunci Pertemuan 10 Hari ini Anda menguasai Terraform IaC: HCL, state, module, workflow, security.
HCL & Resource
Provider, resource, variable. State file mapping realita ke kode.
Module & Registry
Module = DRY infra. Registry untuk module community AWS.
Workflow GitOps
init-plan-apply via PR. Atlantis/TF Cloud untuk orchestrate.
Tiga lensa P10: HCL sebagai sumber kebenaran · Module DRY · GitOps workflow.
Persiapan P11: Kubernetes. Baca Burns bab 1-3 Kubernetes Up and Running. Kuis 5 menit soal HCL resource & state.
Tiga pesan kunci: HCL dan resource provider resource variable dengan state file mapping realita ke kode. Module dan Registry module sama dengan DRY infra Registry untuk module community AWS seperti terraform-aws-modules. Workflow GitOps init-plan-apply via PR dengan Atlantis atau Terraform Cloud untuk orchestrate enterprise. Tiga lensa P10: HCL sebagai sumber kebenaran, Module DRY, GitOps workflow. P11 kita masuk Kubernetes container orchestration — baca Burns Kubernetes Up and Running bab 1 sampai 3. Kuis 5 menit HCL resource dan state di awal P11. Sampai jumpa.