Di Mana Sebaiknya Anda Menyimpan State Infrastruktur? Panduan Praktis

Anda baru saja selesai menulis konfigurasi Terraform yang menyediakan beberapa server dan sebuah database. Anda menjalankan terraform apply di laptop, dan semuanya berfungsi. Rekan kerja Anda, yang perlu menambahkan load balancer, menjalankan konfigurasi yang sama dari mesinnya. Tiba-tiba, database tersebut menghilang. Bukan karena kode yang salah, tetapi karena file state lokal rekan Anda tidak mengetahui bahwa database sudah ada sebelumnya.

Skenario ini bukan hipotetis. Ini terjadi setiap hari di tim yang menyimpan state infrastruktur sebagai file lokal di mesin masing-masing pengembang. Masalahnya sederhana: ketika banyak orang mengelola infrastruktur yang sama, state lokal setiap orang dengan cepat menjadi usang. Resource menjadi tertimpa, terduplikasi, atau tidak sengaja terhapus. Perbaikannya juga sederhana: simpan state di lokasi bersama yang aman yang dapat diakses oleh semua anggota tim.

Apa Itu State, dan Mengapa Itu Penting?

State adalah catatan dari semua yang telah dibuat oleh alat infrastruktur Anda. Ini berisi ID resource, alamat IP, nilai konfigurasi, dan terkadang bahkan kata sandi atau kunci API yang disimpan sebagai teks biasa. Ketika Anda menjalankan terraform plan, alat tersebut membaca state saat ini untuk memahami apa yang sudah ada dan apa yang perlu diubah. Tanpa state yang akurat, alat tidak dapat mengetahui apakah sebuah resource harus dibuat, diperbarui, atau dibiarkan saja.

Jika state hilang atau rusak, alat tersebut kehilangan jejak infrastruktur Anda. Anda akan berakhir dengan resource yatim piatu yang menghabiskan biaya tetapi tidak lagi dikelola. Atau lebih buruk lagi, Anda tidak sengaja membuat ulang resource yang sudah berjalan, menyebabkan waktu henti.

Jebakan File Lokal

Cara termudah untuk menyimpan state adalah sebagai file di mesin Anda sendiri. Untuk pembelajaran atau proyek pribadi, ini berfungsi dengan baik. Anda adalah satu-satunya orang yang menyentuh infrastruktur, jadi tidak ada konflik.

Tetapi begitu orang kedua bergabung, state lokal menjadi bermasalah. Inilah yang terjadi:

  • Anda membuat server. File state Anda mencatatnya.
  • Rekan Anda menjalankan konfigurasi yang sama. File state mereka kosong, sehingga alat tersebut mencoba membuat server lain dengan nama yang sama.
  • Penyedia cloud menolak duplikat, atau lebih buruk lagi, alat tersebut menimpa server yang sudah ada karena tidak mengetahui keberadaannya.

Bahkan jika Anda berbagi file state melalui version control, Anda akan mengalami konflik penggabungan. Dua orang tidak dapat mengedit file state yang sama pada waktu yang sama tanpa menimpa perubahan satu sama lain. Inilah sebabnya mengapa tim yang mengelola infrastruktur bersama harus menggunakan remote backend.

Untuk membantu Anda memutuskan pendekatan mana yang sesuai dengan situasi Anda, berikut adalah diagram alur keputusan:

flowchart TD A[Berapa banyak orang yang mengelola infra?] --> B[Satu] A --> C[Banyak] B --> D[File lokal OK] C --> E[Perlu remote backend] E --> F[Pilih tipe backend] F --> G[S3 + DynamoDB] F --> H[GCS] F --> I[Azure Storage] F --> J[Terraform Cloud] F --> K[Consul] G --> L[Mendukung locking & versioning] H --> L I --> L J --> M[Dikelola, lebih sedikit beban operasional] K --> M L --> N[Atur access control] M --> N N --> O[Siap digunakan tim]

Remote Backend: Sumber Kebenaran Bersama

Remote backend menyimpan state di lokasi yang dapat diakses oleh semua anggota tim. Pilihan umum termasuk bucket S3 di AWS, bucket GCS di Google Cloud, atau kontainer Azure Storage. Semua orang mengarahkan alat infrastruktur mereka ke backend yang sama, sehingga state selalu konsisten.

Berikut adalah konfigurasi backend Terraform minimal yang menggunakan bucket S3 untuk penyimpanan state dan tabel DynamoDB untuk penguncian:

terraform {
  backend "s3" {
    bucket         = "my-company-terraform-state"
    key            = "production/network/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-state-locks"
    encrypt        = true
  }
}

Sebelum menggunakan konfigurasi ini, buat bucket S3 dengan versioning diaktifkan dan tabel DynamoDB dengan primary key bernama LockID (tipe String). Pengaturan encrypt = true memastikan file state dienkripsi saat diam.

Tetapi remote backend bukan sekadar folder bersama. Anda perlu memikirkan beberapa hal sebelum memilihnya.

Access Control Bersifat Non-Negotiable

File state berisi informasi sensitif. ID resource, alamat IP, dan terkadang kredensial disimpan dalam teks biasa. Jika seseorang di luar tim Anda mendapatkan akses baca ke state, mereka dapat melihat detail seluruh infrastruktur Anda. Jika mereka mendapatkan akses tulis, mereka dapat merusak atau menghapus resource.

Amankan bucket atau kontainer tempat state disimpan. Gunakan kebijakan IAM atau akses berbasis peran untuk memastikan hanya orang dan sistem yang berwenang yang dapat membaca atau menulis state. Perlakukan bucket state seperti Anda memperlakukan database produksi.

Trade-Off Kecepatan dan Biaya

State lokal cepat karena file ada di mesin Anda. Remote backend memerlukan pengunduhan state sebelum plan atau apply, dan pengunggahan setelahnya. Untuk tim kecil dengan beberapa lusin resource, ini menambah satu atau dua detik. Untuk infrastruktur besar dengan ribuan resource, pengunduhan dan pengunggahan dapat memakan waktu menit.

Beberapa backend mengenakan biaya per operasi atau per gigabyte penyimpanan. S3, misalnya, mengenakan biaya untuk permintaan PUT dan GET. Jika tim Anda menjalankan terraform plan puluhan kali sehari, biaya tersebut akan bertambah. Pilih backend yang sesuai dengan pola penggunaan tim Anda.

Versioning Menyelamatkan Anda dari Kesalahan

Beberapa remote backend mendukung versioning. S3 dapat menyimpan riwayat setiap perubahan file state. Jika seseorang menerapkan perubahan yang merusak, Anda dapat kembali ke versi state sebelumnya dan memulihkannya.

Versioning tidak diaktifkan secara default. Anda harus mengaktifkannya secara eksplisit. Jangan berasumsi bahwa backend Anda secara otomatis menyimpan riwayat. Periksa dokumentasi dan aktifkan versioning sebelum Anda membutuhkannya.

Managed Backend Mengurangi Beban Operasional

Jika Anda tidak ingin mengelola bucket, kebijakan akses, dan versioning sendiri, pertimbangkan managed backend seperti Terraform Cloud atau HashiCorp Consul. Layanan ini dirancang khusus untuk manajemen state. Mereka menyertakan versioning, riwayat, locking, dan integrasi dengan pipeline CI/CD.

Trade-off-nya adalah biaya dan vendor lock-in. Managed backend mengenakan biaya per pengguna atau per workspace. Anda juga bergantung pada uptime dan ketersediaan API penyedia. Untuk tim yang ingin fokus pada infrastruktur daripada manajemen state, trade-off ini seringkali sepadan.

Locking Mencegah Perubahan Bersamaan

Bahkan dengan remote backend, dua orang dapat menjalankan terraform apply pada waktu yang sama. Tanpa locking, kedua operasi membaca state yang sama, membuat perubahan, dan menulis kembali. Penulisan kedua menimpa yang pertama, dan perubahan orang pertama hilang.

Sebagian besar remote backend mendukung locking. S3 dengan DynamoDB, misalnya, menggunakan tabel DynamoDB untuk menahan kunci. Ketika seseorang memulai operasi, alat tersebut memperoleh kunci. Operasi lain harus menunggu sampai kunci dilepaskan. Ini mencegah kerusakan state dari penulisan bersamaan.

Locking tidak opsional untuk tim. Jika backend Anda tidak mendukungnya, temukan yang mendukung.

Daftar Periksa Praktis untuk Penyimpanan State

Sebelum Anda memutuskan di mana akan menyimpan state, jalankan daftar periksa ini:

  • Apakah backend dapat diakses oleh semua orang yang membutuhkannya?
  • Apakah akses dibatasi hanya untuk orang dan sistem yang berwenang?
  • Apakah backend mendukung versioning?
  • Apakah backend mendukung locking?
  • Apakah biayanya dapat diterima untuk penggunaan tim Anda?
  • Apakah latensinya dapat diterima untuk alur kerja Anda?

Jika Anda menjawab ya untuk keenamnya, Anda memiliki backend state yang solid.

Kesimpulan Konkret

Jangan simpan state infrastruktur di laptop Anda. Gunakan remote backend yang mendukung access control, versioning, dan locking. Beberapa menit yang dihabiskan untuk menyiapkan backend state yang tepat akan menyelamatkan Anda dari berjam-jam debugging ketika seseorang tidak sengaja menghapus resource atau menimpa perubahan rekan kerja. Infrastruktur Anda hanya dapat diandalkan sejauh state yang melacaknya. Pastikan state tersebut berada di tempat yang aman.