Ketika Konsol Cloud dan Kode IaC Tidak Sepakat: Mendeteksi Drift Infrastruktur Secara Otomatis

Anda telah mengelola infrastruktur melalui Terraform selama berbulan-bulan. Semuanya didefinisikan dalam kode, ditinjau melalui pull request, dan di-deploy melalui pipeline. Suatu hari, seorang anggota tim perlu memperbaiki masalah konfigurasi dengan cepat. Alih-alih melalui pipeline, mereka masuk ke konsol cloud, mengubah aturan security group secara manual, dan melanjutkan pekerjaan. Perubahan itu berhasil. Tidak ada yang memikirkannya lagi.

Beberapa minggu kemudian, Anda menjalankan deployment baru. Terraform berencana mengembalikan perubahan security group itu karena kode masih memiliki definisi lama. Jika Anda menerapkannya, perubahan yang sengaja dibuat seseorang akan ditimpa. Jika Anda melewatkannya, kode Anda tidak lagi sesuai dengan kenyataan. Anda sekarang memiliki infrastruktur drift.

Drift adalah kesenjangan antara apa yang seharusnya ada menurut kode infrastruktur Anda dan apa yang sebenarnya ada di lingkungan cloud Anda. Ini bukan masalah teoretis. Ini terjadi di setiap tim yang mengelola infrastruktur dalam skala besar. Pertanyaannya bukan apakah drift akan terjadi, tetapi seberapa cepat Anda akan menemukannya.

Mengapa Deteksi Drift Manual Gagal

Anda secara teknis dapat mendeteksi drift dengan membuka konsol cloud, memeriksa setiap resource, dan membandingkannya dengan kode IaC Anda. Ini berfungsi ketika Anda mengelola lima resource. Ini berhenti berfungsi ketika Anda mengelola lima puluh, lima ratus, atau lima ribu resource.

Deteksi manual memiliki tiga masalah. Pertama, lambat. Satu perbandingan saja bisa memakan waktu beberapa menit. Kalikan dengan ratusan resource, dan Anda menghabiskan waktu berjam-jam untuk sesuatu yang seharusnya diotomatisasi. Kedua, tidak dapat diandalkan. Mata manusia melewatkan perbedaan kecil, terutama ketika resource memiliki puluhan bidang konfigurasi. Ketiga, tidak konsisten. Anggota tim yang berbeda mungkin memeriksa hal yang berbeda, atau lupa memeriksa sama sekali.

Masalah sebenarnya adalah waktu. Drift dapat terjadi kapan saja. Pemeriksaan manual seminggu sekali berarti Anda mungkin hidup dengan perubahan yang tidak terdeteksi selama berhari-hari. Jika perubahan itu memperkenalkan kerentanan keamanan atau merusak dependensi, Anda akan mengetahuinya dengan cara yang sulit selama insiden berikutnya.

Bagaimana Deteksi Drift Otomatis Bekerja

Deteksi drift otomatis mengikuti prinsip sederhana: menjalankan perbandingan antara keadaan infrastruktur aktual Anda dan definisi IaC Anda secara terjadwal. Proses ini disebut pemindaian drift. Pemindaian drift tidak mengubah apa pun. Ia hanya menemukan perbedaan dan melaporkannya.

Pendekatan yang paling umum menggunakan alat yang sama yang sudah Anda gunakan untuk mengelola infrastruktur. Terraform, misalnya, memiliki perintah plan yang membandingkan file state Anda dengan resource cloud aktual. File state Anda adalah catatan yang disimpan Terraform secara lokal atau jarak jauh, menyimpan resource apa yang telah dibuat dan konfigurasi saat ini. Ketika Anda menjalankan terraform plan tanpa mengubah kode apa pun, alat ini memeriksa apakah file state cocok dengan apa yang sebenarnya ada di cloud. Jika seseorang memodifikasi resource secara langsung di konsol, rencana akan menampilkannya sebagai perubahan yang ingin dilakukan Terraform.

Ini adalah fondasi deteksi drift: jalankan plan secara berkala dan periksa perubahan yang tidak terduga.

Berikut adalah skrip bash minimal yang menjalankan pemindaian drift dan memberi tahu tim Anda ketika drift ditemukan:

#!/bin/bash
# drift-scan.sh - Run a Terraform drift scan and notify on changes

set -euo pipefail

cd /path/to/terraform/project

terraform init -input=false

# Refresh state from live resources, then plan with detailed exit code
terraform plan -refresh-only -detailed-exitcode -out=drift.tfplan
PLAN_EXIT_CODE=$?

if [ $PLAN_EXIT_CODE -eq 2 ]; then
    # Exit code 2 means there are changes (drift detected)
    echo "Drift detected in $(date)"
    
    # Generate a human-readable summary
    terraform show drift.tfplan > drift-summary.txt
    
    # Send notification to Slack (adjust webhook URL)
    curl -X POST -H 'Content-type: application/json' \
        --data "{\"text\":\"🚨 Drift detected in production!\n$(cat drift-summary.txt)\"}" \
        https://hooks.slack.com/services/YOUR/WEBHOOK/URL
elif [ $PLAN_EXIT_CODE -eq 1 ]; then
    echo "Error during plan execution"
    exit 1
else
    echo "No drift detected"
fi

Skrip ini dapat dipicu oleh cron job atau pipeline CI/CD terjadwal untuk berjalan setiap beberapa jam.

Diagram alir berikut menunjukkan siklus deteksi drift yang lengkap:

flowchart TD A[Kode IaC<br/>Keadaan yang Diinginkan] -->|terraform apply| B[Resource Cloud<br/>Keadaan Aktual] B -->|Perubahan manual di konsol| C[Resource yang Melenceng] C -->|Plan atau refresh terjadwal| D{Drift Terdeteksi?} D -->|Ya| E[Notifikasi<br/>Slack atau Email] D -->|Tidak| B E --> F{Keputusan Respons} F -->|Rekonsiliasi| G[terraform apply mengembalikan perubahan] F -->|Terima| H[Perbarui kode IaC agar sesuai dengan keadaan aktual] G --> B H --> A

Melampaui Plan Dasar: Mendapatkan Hasil yang Akurat

Ada detail yang halus namun penting di sini. terraform plan standar membandingkan file state dengan resource aktual. Tetapi bagaimana jika file state itu sendiri sudah usang? Jika seseorang membuat perubahan di konsol, file state mungkin tidak mencerminkannya. Plan tidak akan mendeteksi drift karena membandingkan dua hal yang sama-sama tidak sinkron.

Beberapa alat menangani ini dengan lebih baik. Terraform Cloud dan OpenTofu menawarkan deteksi drift yang lebih dalam. Alih-alih hanya membandingkan state dengan resource, mereka pertama-tama menyegarkan state dengan menarik konfigurasi aktual dari cloud, kemudian membandingkan state yang telah disegarkan itu dengan kode Anda. Ini memberi Anda perbandingan dari kode ke resource aktual, bukan dari state ke resource. Hasilnya lebih akurat karena menangkap perubahan yang terjadi di luar file state sama sekali.

Perbedaan ini penting. Jika Anda hanya mengandalkan output plan dasar, Anda mungkin melewatkan drift yang diperkenalkan sebelum file state terakhir diperbarui. Pemindaian drift yang tepat harus selalu dimulai dengan menyegarkan state dari lingkungan langsung.

Penjadwalan dan Notifikasi

Pemindaian drift perlu berjalan sesuai jadwal. Seberapa sering tergantung pada seberapa sering perubahan terjadi di luar pipeline Anda. Tim yang mengelola infrastruktur produksi kritis sering menjalankan pemindaian setiap beberapa jam. Tim dengan aktivitas yang lebih sedikit mungkin menjalankannya sekali sehari. Kuncinya adalah konsistensi: pemindaian harus berjalan secara otomatis tanpa campur tangan manusia.

Anda dapat menjadwalkan pemindaian menggunakan cron job di server CI/CD Anda, pemicu pipeline terjadwal, atau penjadwal bawaan dari alat IaC Anda. Yang penting adalah jadwalnya dapat diandalkan dan tidak bergantung pada seseorang yang ingat untuk menjalankannya.

Ketika drift terdeteksi, langkah selanjutnya adalah notifikasi. Peringatan otomatis harus dikirim ke saluran komunikasi tim Anda, apakah itu Slack, email, atau sistem tiket. Notifikasi yang baik mencakup tiga hal: resource mana yang melenceng, apa yang berubah, dan kapan terdeteksi. Jika penyedia cloud Anda mencatat siapa yang membuat perubahan, sertakan informasi itu juga. Ini mempercepat investigasi secara signifikan.

Apa yang Terjadi Setelah Deteksi

Menemukan drift hanyalah langkah pertama. Setelah Anda tahu itu ada, Anda memiliki dua opsi.

Opsi pertama adalah rekonsiliasi: mengembalikan resource ke keadaan yang ditentukan dalam kode Anda. Ini adalah respons default untuk sebagian besar tim. Anda menjalankan terraform apply atau yang setara, dan alat mengembalikan perubahan manual. Ini berfungsi dengan baik ketika drift tidak disengaja atau tidak sah.

Opsi kedua adalah penerimaan: perubahan manual itu disengaja dan harus dipertahankan. Dalam kasus ini, Anda memperbarui kode IaC Anda agar sesuai dengan keadaan aktual. Ini adalah pilihan yang tepat ketika perubahan adalah perbaikan yang sah yang dilakukan dengan cepat di konsol, dan kode perlu mengejar ketinggalan. Bahayanya adalah jika Anda terlalu sering melakukan ini, kode Anda berhenti menjadi sumber kebenaran dan menjadi catatan sejarah saja.

Keputusan antara rekonsiliasi dan penerimaan tergantung pada kebijakan tim Anda. Beberapa tim selalu melakukan rekonsiliasi kecuali ada pengecualian yang didokumentasikan. Yang lain mengizinkan penerimaan tetapi memerlukan pull request tindak lanjut dalam jangka waktu yang ditentukan. Yang penting adalah keputusan itu disengaja, bukan tidak sengaja.

Daftar Periksa Praktis untuk Deteksi Drift Otomatis

Jika Anda menyiapkan deteksi drift untuk pertama kalinya, berikut adalah daftar periksa singkat untuk memulai:

  • Pilih alat deteksi Anda: Gunakan deteksi drift bawaan alat IaC Anda yang sudah ada atau alat khusus seperti Terraform Cloud, OpenTofu, atau skrip kustom yang menjalankan plan secara berkala.
  • Tetapkan jadwal pemindaian: Mulai dengan sekali sehari untuk lingkungan non-kritis dan setiap beberapa jam untuk produksi. Sesuaikan berdasarkan seberapa sering perubahan manual terjadi.
  • Konfigurasikan notifikasi: Kirim peringatan ke chat tim atau sistem tiket Anda. Sertakan nama resource, perubahan spesifik, dan stempel waktu.
  • Tentukan kebijakan respons: Putuskan apakah akan melakukan rekonsiliasi atau menerima drift. Dokumentasikan prosesnya sehingga semua orang di tim mengikuti pendekatan yang sama.
  • Uji prosesnya: Perkenalkan perubahan manual yang disengaja di lingkungan staging, biarkan pemindaian menangkapnya, dan verifikasi bahwa notifikasi dan respons berfungsi seperti yang diharapkan.

Intisari Konkret

Infrastruktur drift bukanlah tanda tim yang buruk. Ini adalah tanda bahwa tim Anda bergerak cepat dan kadang-kadang mengambil jalan pintas. Masalahnya bukan pada jalan pintas itu sendiri. Masalahnya adalah tidak mengetahuinya sampai menyebabkan insiden.

Deteksi drift otomatis mengubah masalah yang tidak terlihat menjadi masalah yang terlihat. Ini tidak mencegah orang membuat perubahan di konsol. Ini memastikan bahwa ketika mereka melakukannya, seluruh tim mengetahuinya dengan cepat dan dapat memutuskan apa yang harus dilakukan selanjutnya. Visibilitas itulah yang menjaga infrastruktur Anda tetap andal, bahkan ketika kode dan cloud tidak setuju.