Infrastruktur Cloud Anda Melenceng dari Kode. Begini Cara Mendeteksinya.

Anda sudah menulis infrastruktur sebagai kode. Anda sudah menjalankan terraform plan, meninjau keluarannya, dan menerapkan perubahannya. Sumber daya muncul di konsol cloud. Tim merayakan keberhasilan deployment lainnya. Pekerjaan selesai.

Tapi benarkah?

Seminggu kemudian, seseorang dengan akses admin masuk ke server dan mengubah konfigurasi untuk memperbaiki masalah mendesak. Tim keamanan menambahkan aturan firewall melalui dashboard cloud tanpa memberi tahu siapa pun. Penyedia cloud Anda menghentikan sebuah endpoint API, dan konfigurasi yang berfungsi sempurna bulan lalu kini diam-diam tidak melakukan apa pun yang berguna.

Tak satu pun dari perubahan ini menyentuh repositori Anda. Tak satu pun melalui proses review kode. Tak satu pun tercatat di mana pun yang bisa ditemukan tim Anda nanti. Infrastruktur Anda kini berbeda dari apa yang dijelaskan oleh kode Anda. Anda punya masalah.

Situasi ini punya nama: drift. Artinya, keadaan infrastruktur Anda yang sebenarnya tidak lagi sesuai dengan keadaan yang diinginkan (desired state) yang didefinisikan dalam kode. Drift berbahaya karena diam-diam merusak janji infrastructure as code. Jika Anda perlu membuat ulang lingkungan dari awal, hasilnya akan berbeda. Jika terjadi insiden, Anda tidak bisa percaya bahwa menjalankan kode yang sama akan memulihkan keadaan yang aman. Anda kehilangan kemampuan untuk mereproduksi infrastruktur secara andal.

Bagaimana Drift Terjadi dalam Praktik

Drift tidak disebabkan oleh aktor jahat atau tim yang tidak kompeten. Ini terjadi melalui tindakan normal dan berniat baik yang melewati pipeline.

Seorang pengembang perlu menguji sesuatu dengan cepat dan mengubah aturan security group secara manual. Seorang database administrator menyesuaikan parameter untuk menangani lonjakan beban mendadak. Seorang platform engineer menambal server secara langsung karena proses patch otomatis terlalu lambat. Setiap tindakan ini masuk akal pada saat itu. Masing-masing menciptakan celah antara apa yang dikatakan kode Anda dan apa yang sebenarnya berjalan.

Masalahnya bertambah seiring waktu. Satu perubahan manual menjadi dua, lalu sepuluh. Setelah beberapa bulan, infrastruktur yang berjalan di produksi hampir tidak mirip dengan kode di repositori Anda. Lain kali seseorang menjalankan terraform apply dengan harapan keadaan bersih, mereka mendapatkan daftar panjang perubahan tak terduga. Tidak ada yang tahu perubahan mana yang disengaja dan mana yang kecelakaan. Kepercayaan pada kode infrastruktur pun terkikis.

Mendeteksi Drift Sebelum Menimbulkan Masalah

Solusinya bukan melarang perubahan manual. Terkadang Anda perlu bertindak cepat, dan pipeline terlalu lambat. Solusinya adalah mendeteksi drift secara otomatis dan teratur, sehingga Anda mengetahuinya sebelum menyebabkan insiden.

Deteksi drift adalah proses yang membandingkan keadaan infrastruktur Anda yang sebenarnya dengan keadaan yang diinginkan dalam kode. Proses ini berjalan sesuai jadwal atau dipicu oleh peristiwa tertentu. Ketika menemukan perbedaan, ia mencatat detailnya: sumber daya mana yang berubah, bagian konfigurasi mana yang berbeda, dan apa nilai yang benar seharusnya.

Sebagian besar alat infrastructure as code mendukung deteksi drift secara native. Terraform memiliki terraform plan yang menunjukkan perbedaan antara state dan konfigurasi. Pulumi memiliki perintah preview. AWS CloudFormation memiliki deteksi drift bawaan di layanannya. Kuncinya adalah menjalankan pemeriksaan ini secara otomatis, bukan hanya ketika seseorang ingat melakukannya.

Berikut adalah perintah sederhana yang bisa Anda jalankan di pipeline CI untuk mendeteksi drift secara otomatis:

#!/bin/bash
# Run terraform plan and exit with a non-zero code if drift is detected
terraform init -input=false
terraform plan -detailed-exitcode -input=false -out=tfplan
PLAN_EXIT_CODE=$?

if [ $PLAN_EXIT_CODE -eq 2 ]; then
  echo "Drift detected! Infrastructure does not match code."
  # Send alert to Slack or your incident management tool
  curl -X POST -H 'Content-type: application/json' \
    --data '{"text":"Drift detected in production environment. Run terraform apply to reconcile."}' \
    YOUR_SLACK_WEBHOOK_URL
  exit 1
elif [ $PLAN_EXIT_CODE -eq 1 ]; then
  echo "Error running terraform plan."
  exit 1
else
  echo "No drift detected. Infrastructure matches code."
fi

Skrip ini menggunakan -detailed-exitcode untuk membedakan antara keadaan bersih (exit code 0), kesalahan (exit code 1), dan drift (exit code 2).

Membangun Deteksi Drift ke dalam Pipeline Anda

Pipeline deteksi drift yang praktis terlihat seperti ini:

Berikut adalah gambaran visual dari pipeline deteksi drift:

flowchart TD A[Code Commit] --> B[Plan] B --> C[Apply] C --> D{Drift Check} D -- Periodic or Event-Triggered --> E{Drift Found?} E -- No --> D E -- Yes --> F[Alert Team] F --> G{Decision} G -- Revert --> H[Reconcile] G -- Accept --> I[Update Code] H --> D I --> D

  1. Jadwalkan pemeriksaan rutin. Jalankan deteksi drift setiap beberapa jam atau setiap hari, tergantung seberapa kritis infrastruktur Anda. Untuk lingkungan produksi, pemeriksaan yang lebih sering lebih baik. Untuk lingkungan staging, pemeriksaan harian mungkin sudah cukup.

  2. Picu pada peristiwa mencurigakan. Beberapa penyedia cloud mengeluarkan peristiwa ketika sumber daya dimodifikasi di luar pipeline Anda. Gunakan webhook atau log peristiwa untuk memicu pemeriksaan drift ketika peristiwa ini terjadi.

  3. Laporkan hasilnya. Ketika drift terdeteksi, kirim notifikasi ke tim. Gunakan Slack, email, atau buat issue di tracker Anda. Notifikasi harus mencakup sumber daya mana yang melenceng dan apa nilai yang diharapkan.

  4. Biarkan tim memutuskan apa yang harus dilakukan. Tidak semua drift buruk. Perubahan manual mungkin sah dan harus dimasukkan ke dalam kode. Perubahan lain mungkin tidak disengaja dan perlu dikembalikan. Tim perlu melihat drift dan membuat keputusan.

Rekonsiliasi Otomatis: Hati-hati

Beberapa tim melangkah lebih jauh dengan deteksi drift dan mengotomatiskan koreksi. Ketika pipeline mendeteksi drift, ia segera menjalankan apply untuk mengembalikan infrastruktur ke keadaan yang diinginkan. Pendekatan ini bekerja dengan baik untuk lingkungan yang harus tetap konsisten, seperti staging atau sistem produksi yang dikontrol ketat.

Namun rekonsiliasi otomatis memiliki risiko. Pertimbangkan auto-scaling: infrastructure as code Anda mendefinisikan jumlah minimum dan maksimum instans. Sebuah grup auto-scaling menambahkan instans berdasarkan beban. Pemeriksaan deteksi drift melihat instans tambahan sebagai drift dan menghentikannya. Pengguna Anda mengalami outage karena sistem sedang melakukan apa yang seharusnya dilakukan.

Aturan praktisnya: hanya otomatiskan rekonsiliasi untuk sumber daya yang tidak boleh berubah di luar pipeline. Untuk yang lainnya, beri tahu tim dan biarkan mereka memutuskan.

Checklist Deteksi Drift Praktis

Berikut adalah checklist singkat untuk membantu Anda memulai deteksi drift:

  • Pilih jadwal untuk pemeriksaan drift (setiap 6 jam untuk produksi, setiap hari untuk staging)
  • Konfigurasikan notifikasi ke saluran yang tepat (Slack, email, atau alat manajemen insiden)
  • Putuskan lingkungan mana yang mendapatkan rekonsiliasi otomatis dan mana yang memerlukan tinjauan manual
  • Uji proses deteksi drift dengan membuat perubahan manual kecil dan memverifikasi peringatan
  • Tinjau laporan drift mingguan sebagai tim untuk mengidentifikasi pola atau masalah berulang

Apa yang Diberikan Deteksi Drift kepada Anda

Deteksi drift tidak mencegah perubahan manual. Ini tidak menghilangkan kebutuhan akan respons insiden. Yang dilakukannya adalah memberi Anda visibilitas ke dalam celah antara kode dan kenyataan. Ketika Anda tahu tentang drift, Anda bisa memutuskan apakah akan menerimanya, mengembalikannya, atau memperbarui kode Anda untuk mencerminkannya.

Tanpa deteksi drift, infrastructure as code Anda hanyalah fiksi. Anda mungkin percaya sistem Anda dapat direproduksi, tetapi Anda tidak punya cara untuk memverifikasinya. Dengan deteksi drift, kode Anda tetap menjadi sumber kebenaran tunggal karena Anda secara aktif mempertahankan kebenaran itu.

Lain kali seseorang berkata "kami menggunakan infrastructure as code," tanyakan kepada mereka: "Bagaimana Anda tahu infrastruktur Anda masih sesuai dengan kode?" Jika mereka tidak bisa menjawab, mereka memiliki drift. Dan drift adalah bom waktu yang siap meledak saat insiden berikutnya.