Konfigurasi Cloud Sering Berubah Diam-Diam? Kenali Infrastructure Drift sebelum Deployment Berantakan

Tim sering menyadari ada masalah ketika deployment berikutnya tiba-tiba ingin menghapus aturan firewall, mengganti ukuran server, atau mengubah konfigurasi jaringan yang sebenarnya masih dibutuhkan. Penyebabnya tidak selalu bug di aplikasi. Bisa jadi konfigurasi cloud sudah berubah di luar alur kerja yang disepakati.

Kondisi ketika konfigurasi nyata di cloud tidak lagi sama dengan konfigurasi yang didefinisikan di kode atau state disebut infrastructure drift. Masalah ini umum terjadi ketika seseorang mengubah resource langsung dari dashboard, menjalankan perintah manual saat keadaan darurat, atau memakai beberapa alat pengelolaan sekaligus.

Apa itu infrastructure drift?

Bayangkan ada cetak biru rumah, tetapi selama beberapa bulan penghuni menambah sekat, memindahkan pintu, dan mengganti instalasi listrik tanpa memperbarui cetak birunya. Rumahnya mungkin masih berdiri, tetapi orang yang membaca dokumen lama tidak lagi mengetahui kondisi sebenarnya.

Hal yang sama terjadi pada infrastruktur cloud. Kode Terraform, template CloudFormation, atau dokumentasi internal menggambarkan kondisi yang diharapkan. Sementara itu, resource di cloud memiliki kondisi aktual. Jika keduanya berbeda, muncul drift.

Contohnya:

• Port database dibuka sementara untuk proses troubleshooting, lalu lupa ditutup.
• Ukuran instance dinaikkan secara manual ketika trafik sedang tinggi.
• Aturan akses pada bucket storage diubah dari dashboard.
• Tag, variabel lingkungan, atau pengaturan backup diedit oleh anggota tim lain.
• Resource dibuat manual karena kebutuhan mendesak, tetapi tidak pernah dimasukkan ke kode infrastruktur.

Menurut dokumentasi HashiCorp, perubahan di luar alur Terraform dapat membuat state tidak selaras dengan infrastruktur nyata. Dalam kondisi seperti ini, terraform plan -refresh-only dapat digunakan untuk memeriksa perubahan tanpa langsung menerapkan perubahan ke resource. Dokumentasi HashiCorp menjelaskan proses tersebut.

Mengapa drift berbahaya?

Drift bukan sekadar masalah kerapian. Ia dapat memengaruhi keamanan, biaya, dan pemulihan ketika terjadi insiden.

1. Deployment bisa mengembalikan perubahan penting

Jika perubahan manual belum dicatat dalam kode, deployment berikutnya bisa menganggap perubahan itu tidak diinginkan. Alat Infrastructure as Code kemudian berpotensi mengembalikan resource ke konfigurasi lama. Dari sudut pandang sistem, perilaku ini benar. Namun bagi tim, hasilnya dapat terlihat seperti konfigurasi “hilang sendiri”.

2. Celah keamanan bisa tidak terlihat

Port yang terbuka, bucket yang terlalu permisif, atau aturan jaringan yang melemahkan pembatasan akses sering muncul dari perubahan kecil. Masalahnya menjadi lebih sulit dicari jika tidak ada catatan perubahan yang jelas.

3. Tagihan dapat meningkat tanpa segera disadari

Instance yang dibesarkan secara manual, volume tambahan, atau resource sementara yang tidak pernah dihapus bisa menambah biaya. Tanpa perbandingan antara kondisi yang direncanakan dan kondisi aktual, perubahan semacam ini mudah lolos.

4. Rencana pemulihan menjadi tidak dapat dipercaya

Dokumentasi dan kode mungkin mengatakan aplikasi memiliki dua server, backup harian, dan aturan jaringan tertentu. Namun jika kondisi produksi sudah berbeda, proses pemulihan dari kode tersebut belum tentu menghasilkan sistem yang sama.

Cara menemukan drift secara praktis

Langkah pertama bukan langsung memperbaiki semuanya. Cari tahu dulu perbedaan antara kondisi yang diharapkan dan kondisi aktual.

1. Inventarisasi resource. Catat server, database, jaringan, bucket, load balancer, DNS, dan layanan lain yang penting bagi aplikasi.
2. Tentukan sumber kebenaran. Pilih apakah konfigurasi resmi disimpan di Terraform, CloudFormation, Pulumi, atau sistem lain. Jangan membiarkan dashboard dan repository sama-sama dianggap sebagai sumber utama.
3. Jalankan pemeriksaan perubahan. Untuk Terraform, gunakan terraform plan dalam alur biasa atau terraform plan -refresh-only ketika ingin memeriksa perbedaan state dengan resource aktual.
4. Periksa riwayat konfigurasi cloud. Layanan seperti AWS Config dapat menyimpan riwayat perubahan konfigurasi resource yang direkam, sehingga tim bisa menelusuri kapan perubahan terjadi dan apa yang berubah.
5. Klasifikasikan setiap perbedaan. Pisahkan perubahan yang memang dibutuhkan, perubahan sementara, perubahan yang tidak sah, dan resource yang belum pernah masuk ke kode.

AWS menjelaskan bahwa AWS Config dapat membuat catatan konfigurasi untuk resource yang didukung dan menyimpan riwayat tersebut. Fitur ini membantu menjawab pertanyaan seperti kapan resource berubah dan konfigurasi apa yang diperkenalkan. Lihat konsep AWS Config.

Jangan langsung “merapikan” semuanya

Kesalahan yang sering terjadi adalah menjalankan apply tanpa membaca rencana perubahan. Jika drift sudah menumpuk, satu perintah dapat mengubah banyak resource sekaligus.

Sebelum memperbaiki, buat daftar dampaknya. Tanyakan:

• Apakah perubahan manual sedang melindungi layanan dari gangguan?
• Apakah ada konfigurasi penting yang belum masuk ke kode?
• Apakah aplikasi perlu diletakkan dalam mode pemeliharaan?
• Apakah perubahan akan memutus koneksi database, VPN, atau layanan pihak ketiga?
• Apakah state dan kredensial yang digunakan sudah benar untuk lingkungan production?

Jika perubahan manual memang diperlukan, masukkan keputusan tersebut ke kode setelah kondisi stabil. Jika perubahan tidak seharusnya ada, jadwalkan pengembaliannya dengan rencana rollback yang jelas.

Kebiasaan sederhana untuk mencegah drift

Batasi perubahan langsung di production

Dashboard tetap berguna untuk observasi dan kondisi darurat. Namun perubahan permanen sebaiknya melewati pull request, pemeriksaan, dan persetujuan. Akses tulis langsung ke production dapat dibatasi hanya untuk peran tertentu.

Gunakan pemeriksaan sebelum merge

Setiap perubahan infrastruktur sebaiknya menghasilkan rencana yang dapat dibaca. Tim tidak harus memahami semua detail cloud, tetapi harus tahu resource apa yang akan dibuat, diubah, atau dihapus.

Jadwalkan pemeriksaan berkala

Untuk proyek kecil, pemeriksaan mingguan mungkin sudah cukup. Untuk sistem yang sering berubah, lakukan pemeriksaan lebih sering melalui pipeline. HCP Terraform, misalnya, menyediakan pemeriksaan berbasis refresh-only untuk membandingkan konfigurasi aktual dengan state yang dilacak. Penjelasan resminya tersedia di dokumentasi HashiCorp.

Catat pengecualian

Tidak semua perubahan sementara adalah kesalahan. Yang penting, setiap pengecualian memiliki alasan, pemilik, tanggal kedaluwarsa, dan rencana pengembalian. Tiket insiden sederhana sudah lebih baik daripada mengandalkan ingatan.

Apa artinya bagi kita?

Infrastructure drift pada dasarnya adalah utang dokumentasi yang bisa berubah menjadi risiko operasional. Ia tidak selalu terlihat ketika aplikasi berjalan normal, tetapi biasanya muncul saat deployment, audit keamanan, migrasi, atau pemulihan bencana.

Mulailah dari satu layanan yang paling penting. Bandingkan kode dengan kondisi aktual, periksa riwayat perubahan, lalu rapikan alur persetujuannya. Tujuannya bukan melarang semua tindakan manual, melainkan memastikan setiap perubahan dapat dijelaskan, dilacak, dan diulang ketika dibutuhkan.

Cloud akan terasa lebih mudah dikelola ketika tim tidak hanya tahu di mana resource berada, tetapi juga tahu mengapa konfigurasi itu dibuat dan dokumen mana yang dapat dipercaya.

Sumber & bacaan lebih lanjut

• HashiCorp Terraform: Manage resource drift
• HashiCorp Terraform: terraform plan command reference
• HashiCorp: Detect infrastructure drift and enforce policies
• AWS Config terminology and concepts
• How AWS Config works

– Rio Yotto @rioyotto