Hampir semua akun cloud berawal dengan cara yang sama. Seseorang membuat server, database, dan beberapa security group lewat web console, dan semuanya jalan. Dua tahun kemudian tidak ada yang ingat kenapa port 8080 terbuka, staging berbeda dari production tanpa ada yang bisa menyebutkan bedanya di mana, dan membangun ulang environment setelah insiden butuh berhari-hari menebak-nebak. Infrastructure as code menyelesaikan masalah ini dengan menuliskan seluruh pengaturan di file yang disimpan di Git. Terraform adalah tool yang paling banyak dipakai untuk itu.
Manfaat Infrastructure as Code
- Setiap perubahan lewat pull request, jadi terlihat siapa mengubah apa dan alasannya, dan bisa di-rollback.
- Staging dan production dibangun dari kode yang sama, sehingga keduanya tetap mirip.
- Environment baru untuk klien atau region lain bisa jadi dalam satu jam, padahal dulu butuh seminggu.
- Kodenya sekaligus jadi dokumentasi yang tidak pernah ketinggalan zaman.
- Review keamanan bisa dilakukan sebelum perubahan diterapkan, jauh sebelum ada insiden.
Cara Kerja Terraform
Resource seperti VPC, database, atau record DNS dituliskan di file HCL. Provider menerjemahkan tulisan itu menjadi panggilan API ke AWS, Google Cloud, Azure, Cloudflare, Kubernetes, dan ratusan layanan lain. terraform plan membandingkan kode dengan kondisi yang ada dan menampilkan persis apa yang akan dibuat, diubah, atau dihapus. terraform apply menjalankan perubahan itu. Terraform mencatat semua yang dikelolanya di file state, dan dari situlah Terraform tahu bahwa resource di kode sama dengan resource yang sudah ada di cloud.
State Itu Sensitif dan Dipakai Bersama
File state lokal bawaan langsung bermasalah begitu ada dua orang yang mengurus infrastruktur yang sama. Pindahkan ke remote backend sejak hari pertama, misalnya bucket S3, Google Cloud Storage, atau Terraform Cloud. Aktifkan locking supaya dua apply tidak bisa berjalan bersamaan. Sejak Terraform 1.10, backend S3 bisa melakukan locking dengan lock file di bucket itu sendiri, tanpa tabel DynamoDB terpisah. State sering berisi rahasia seperti password database dalam bentuk teks biasa, jadi enkripsi bucket-nya, aktifkan versioning, dan batasi siapa saja yang bisa membacanya.
Susun Kode dengan Module dan Pisahkan Environment
| Pendekatan | Cara kerja | Cocok untuk |
|---|---|---|
| Satu direktori per environment | envs/staging dan envs/production masing-masing punya state sendiri dan memanggil module bersama dengan variabel berbeda | Sebagian besar tim. Pemisahannya jelas, dan kesalahan di staging tidak bisa menyentuh state production |
| Terraform workspace | Satu konfigurasi dengan beberapa state bernama yang dipilih lewat terraform workspace select | Banyak salinan berumur pendek dari pengaturan yang sama, seperti preview environment |
| Akun atau project terpisah per environment | Setiap environment juga berada di akun cloud-nya sendiri dengan kredensial sendiri | Sistem production yang aksesnya harus dipisah dengan ketat |
Masukkan bagian yang bisa dipakai ulang, seperti VPC standar, database lengkap dengan backup dan alarm, atau layanan beserta load balancer-nya, ke dalam module dengan input dan output yang jelas. Kunci versi module dan provider supaya upgrade terjadi karena memang disengaja. Jaga ukuran tiap state tetap wajar. Satu state yang berisi semua hal membuat plan lambat dan setiap apply jadi berisiko.
Jalankan Terraform dari CI
- 1Di setiap pull request, jalankan terraform fmt -check, terraform validate, dan security scanner seperti Checkov atau Trivy.
- 2Jalankan terraform plan dan kirim hasilnya sebagai komentar supaya reviewer melihat dampak nyata dari perubahan.
- 3Perhatikan resource yang ditandai akan diganti atau dihapus. Resource yang diganti namanya bisa berarti database yang terhapus.
- 4Setelah disetujui dan di-merge, jalankan apply dari plan yang tersimpan di CI, dengan kredensial cloud berumur pendek lewat OIDC sebagai pengganti access key permanen.
- 5Blokir perubahan manual lewat console untuk production, atau minimal pasang alert kalau ada yang melakukannya.
Ambil Alih Infrastruktur yang Sudah Ada
Jarang sekali kita mulai dari akun kosong. Terraform 1.5 menambahkan import block, dan terraform plan -generate-config-out bisa menulis draf awal konfigurasi untuk resource yang di-import. Mulai dari bagian yang risikonya rendah seperti record DNS dan bucket, rapikan kode hasil generate, lalu lanjut ke jaringan dan database setelah tim mulai terbiasa. Setelah itu jalankan plan secara rutin. Kalau plan menemukan perbedaan pada kode yang tidak diubah siapa pun, itu tanda ada perubahan manual di luar Terraform.
Terraform atau OpenTofu?
Pada 2023 HashiCorp memindahkan lisensi Terraform dari open source ke Business Source License. Komunitas lalu membuat fork dari versi open source terakhir dengan nama OpenTofu, yang sekarang dikelola di bawah Linux Foundation. Untuk perusahaan yang memakai Terraform untuk mengelola infrastrukturnya sendiri, perubahan lisensi ini umumnya tidak berpengaruh. OpenTofu masuk akal dipilih kalau Anda ingin lisensi open source atau butuh fitur yang dimilikinya, misalnya enkripsi state bawaan. Keduanya masih berbagi sebagian besar sintaks dan provider, tapi pelan-pelan makin berbeda, jadi pilih salah satu untuk tiap codebase.
Perubahan production yang tidak bisa di-review lewat pull request hanya menambah daftar hal yang harus diingat seseorang.
Kami membantu tim memindahkan akun cloud yang sudah berjalan ke Terraform tanpa downtime, dan pelatihan DevOps kami mencakup lab Terraform langsung dengan remote state, module, dan pipeline CI.
Poin penting
- Infrastructure as code mengubah perubahan cloud menjadi pull request yang di-review dan bisa diulang.
- Pakai backend state yang remote, terenkripsi, ber-versioning, dan ber-locking sejak hari pertama.
- Pisahkan tiap environment ke state-nya sendiri dan bagikan kode lewat module yang diberi versi.
- Review terraform plan di CI dan waspadai resource yang akan diganti atau dihapus.
- Import resource yang sudah ada secara bertahap dan jalankan plan rutin untuk menangkap perubahan manual.
