27-7 · Bab 27 · 5 menit baca

Ketika State Infrastruktur Tidak Sesuai Kenyataan

Pelajari cara mendeteksi dan menangani drift pada infrastruktur sebagai kode (IaC) dengan Terraform, Pulumi, dan alat CI/CD. Panduan praktis untuk DevOps, SRE, dan platform engineer.

Ketika State Infrastruktur Tidak Sesuai Kenyataan

Anda sudah menyiapkan infrastruktur sebagai kode. Terraform, Pulumi, atau alat apa pun yang Anda pilih. Semuanya terlacak, berversi, dan dapat diulang. File state Anda mengatakan server produksi memiliki 4 CPU dan 16 GB RAM. Hidup terasa baik-baik saja.

Lalu suatu hari, seseorang masuk ke konsol cloud dan mengubah ukuran server itu secara manual. Mungkin ada masalah performa, dan tim dukungan perlu bertindak cepat. Mungkin seseorang menjalankan skrip yang tidak ada di basis kode Anda. Apa pun alasannya, file state Anda masih mengatakan 4 CPU dan 16 GB, tetapi server sebenarnya sekarang berjalan dengan 8 CPU dan 32 GB.

Kesenjangan antara apa yang dikatakan state Anda dan apa yang sebenarnya ada disebut drift. Dan ini masalah yang lebih besar dari yang disadari kebanyakan tim.

Mengapa Drift Terjadi

Drift tidak jarang terjadi. Ini lebih sering terjadi dari yang Anda kira, dan biasanya karena alasan yang bisa dimengerti:

Seseorang membuat perubahan cepat di konsol cloud saat insiden
Tim lain menjalankan otomatisasi mereka sendiri yang menyentuh sumber daya Anda
Alat monitoring melakukan auto-scaling tanpa memperbarui state
Seorang pengembang memodifikasi sumber daya secara langsung untuk menguji sesuatu dan lupa mengembalikannya

Niatnya hampir tidak pernah jahat. Tapi hasilnya sama: state Anda menjadi tidak dapat diandalkan. Dan ketika state tidak dapat diandalkan, setiap deployment berikutnya menjadi pertaruhan. Anda mungkin mencoba memperbarui sumber daya yang sudah tidak sesuai dengan konfigurasi Anda. Atau Anda mungkin menemukan bahwa sumber daya yang Anda kira ada telah dimodifikasi atau dihapus. Lain kali Anda menjalankan pipeline, Anda akan mendapatkan kejutan, bukan hasil yang dapat diprediksi.

Biaya Nyata dari Drift

Drift tidak hanya merusak otomatisasi Anda. Ini merusak kepercayaan pada seluruh proses pengiriman Anda. Ketika tim Anda tidak bisa percaya bahwa infrastruktur sebagai kode benar-benar mencerminkan kenyataan, mereka mulai membuat perubahan manual lagi. Dan perubahan manual menyebabkan lebih banyak drift. Ini adalah spiral ke bawah.

Untuk lingkungan produksi, drift sangat berbahaya. Sumber daya yang dimodifikasi di luar proses Anda mungkin berperilaku berbeda di bawah beban. Grup keamanan yang diubah secara manual mungkin meninggalkan celah. Instance database yang diubah ukurannya tanpa memperbarui state dapat menyebabkan biaya atau masalah performa yang tidak terduga. Dan ketika sesuatu salah, Anda tidak memiliki catatan yang dapat diandalkan tentang apa yang sebenarnya berubah.

Mendeteksi Drift: Cara Sederhana

Pendekatan paling dasar untuk deteksi drift adalah perbandingan manual. Dengan Terraform, menjalankan terraform plan menunjukkan perbedaan antara kode Anda, state Anda, dan infrastruktur aktual. Sumber daya apa pun yang diubah di luar kode Anda akan muncul sebagai modifikasi yang tidak terduga.

Berikut adalah perintah yang dijalankan dan apa yang harus dicari:

# Jalankan terraform plan tanpa perubahan kode untuk mendeteksi drift
terraform plan

# Contoh output yang menunjukkan drift (tidak ada perubahan kode yang dibuat)
# Terraform will perform the following actions:
#
#   # aws_instance.web_server will be updated in-place
#   ~ resource "aws_instance" "web_server" {
#       ~ instance_type = "t3.large" -> "t3.medium"
#         id            = "i-0abcd1234efgh5678"
#         tags          = {}
#         # (12 unchanged attributes hidden)
#     }
#
# Plan: 0 to add, 1 to change, 0 to destroy.

# Setiap perubahan yang muncul saat Anda tidak mengubah kode = drift

Ini berfungsi untuk pemeriksaan sesekali. Tapi deteksi manual memiliki masalah mendasar: Anda hanya menemukan drift saat Anda mencarinya. Jika Anda memeriksa seminggu sekali, drift bisa ada selama berhari-hari sebelum Anda menyadarinya. Dan dalam waktu itu, itu bisa menyebabkan masalah nyata.

Mengotomatiskan Deteksi Drift

Untuk lingkungan yang membutuhkan kontrol yang konsisten, deteksi drift harus berjalan secara otomatis. Banyak tim menyiapkan pipeline terjadwal yang menjalankan terraform plan atau perintah setara secara rutin. Ketika drift terdeteksi, pipeline mengirimkan notifikasi ke tim.

Beberapa alat sudah memiliki fitur ini. Terraform Cloud dan Atlantis sama-sama menawarkan deteksi drift otomatis. Pulumi memiliki kemampuan serupa. Tapi bahkan tanpa alat-alat ini, Anda dapat menyiapkan cron job sederhana atau pipeline CI terjadwal yang menjalankan validasi infrastruktur Anda dan memberi peringatan ketika ada yang tidak cocok.

Deteksi otomatis sangat penting untuk lingkungan produksi. Drift di produksi tidak menunggu pemeriksaan mingguan Anda. Ini memengaruhi pengguna secara langsung.

Apa yang Harus Dilakukan Saat Menemukan Drift

Deteksi hanyalah setengah dari masalah. Setelah Anda tahu drift ada, Anda perlu memutuskan apa yang harus dilakukan. Anda memiliki dua opsi utama:

Diagram alir berikut merangkum dua jalur utama untuk menangani drift:

flowchart TD A[Drift Terdeteksi] --> B{Apakah perubahannya disengaja?} B -->|Tidak| C[Sesuaikan kembali ke kode] B -->|Ya| D{Haruskah ini menjadi standar baru?} D -->|Tidak| C D -->|Ya| E[Perbarui state agar sesuai kenyataan] C --> F[Jalankan apply untuk mengembalikan state yang diinginkan] E --> G[Impor sumber daya & perbarui kode] F --> H[Verifikasi tidak ada drift tersisa] G --> H H --> I[Dokumentasikan perubahan]

Opsi 1: Sesuaikan kembali ke kode Anda. Jalankan konfigurasi Anda lagi untuk mengembalikan infrastruktur ke keadaan yang diinginkan. Ini adalah pilihan teraman untuk lingkungan produksi. Ini menegaskan bahwa kode Anda adalah sumber kebenaran, dan perubahan manual tidak akan bertahan.

Opsi 2: Perbarui state Anda agar sesuai dengan kenyataan. Impor infrastruktur saat ini ke dalam state Anda, lalu perbarui kode Anda agar sesuai. Ini masuk akal ketika perubahan manual itu disengaja dan harus menjadi standar baru. Tapi hati-hati: menerima drift ke dalam state Anda berarti Anda menerima bahwa infrastruktur dapat diubah di luar proses yang Anda tetapkan.

Sebagian besar tim yang matang memilih opsi satu untuk produksi. Mereka menyesuaikan infrastruktur kembali ke keadaan yang diinginkan. Praktik ini disebut reconciliation, dan ini adalah ide inti di balik alat seperti Kubernetes operator dan alur kerja GitOps. Sistem terus-menerus memeriksa bahwa kenyataan sesuai dengan keadaan yang diinginkan, dan secara otomatis memperbaiki drift yang ditemukan.

Membangun Praktik Deteksi Drift

Jika Anda menyiapkan deteksi drift untuk pertama kalinya, mulailah dengan sederhana. Jalankan plan terjadwal terhadap lingkungan paling kritis Anda. Kirim hasilnya ke saluran obrolan di mana tim dapat melihatnya. Buat drift terlihat sebelum Anda mencoba mengotomatiskan responsnya.

Setelah tim terbiasa melihat notifikasi drift, mulailah mengotomatiskan respons untuk lingkungan non-produksi. Biarkan pipeline secara otomatis menyesuaikan lingkungan staging dan development. Untuk produksi, pertahankan manusia dalam loop sampai Anda yakin dengan otomatisasi Anda.

Dan selalu ingat ini: deteksi drift bukan hanya tentang menangkap kesalahan. Ini tentang menjaga kepercayaan pada infrastruktur sebagai kode Anda. Ketika tim Anda tahu bahwa state akurat, mereka dapat membuat perubahan dengan percaya diri. Ketika tidak, semuanya melambat.

Daftar Periksa Praktis

Jalankan terraform plan atau yang setara secara terjadwal untuk lingkungan produksi
Kirim notifikasi drift ke saluran tim
Tentukan kebijakan yang jelas: sesuaikan ke kode atau perbarui state
Otomatiskan rekonsiliasi untuk lingkungan non-produksi terlebih dahulu
Dokumentasikan cara menangani perubahan manual yang disengaja
Tinjau pola drift setiap bulan untuk mengidentifikasi celah proses

Intisari

Drift bukanlah kegagalan alat Anda. Ini adalah sinyal bahwa proses Anda memiliki celah. Seseorang perlu membuat perubahan, dan proses yang ditetapkan tidak berhasil bagi mereka. Mungkin terlalu lambat. Mungkin mereka tidak memiliki akses. Mungkin mereka tidak tahu proses itu ada.

Ketika Anda menemukan drift, jangan hanya memperbaiki infrastrukturnya. Perbaiki proses yang memungkinkan drift terjadi. Buatlah lebih mudah bagi orang untuk membuat perubahan melalui jalur yang benar daripada di sekitarnya. Itulah cara Anda membangun sistem yang tetap konsisten tanpa kewaspadaan terus-menerus.