Ketika Infrastruktur Berubah di Luar Pipeline: Latihan Deteksi Drift

Anda memiliki konfigurasi Terraform yang mendefinisikan sebuah security group. Namanya sudah benar, aturan inbound-nya tepat, dan tag-nya sesuai. Pipeline Anda berjalan sukses, resource berhasil dibuat, dan state file Anda bersih. Semuanya tampak baik-baik saja.

Lalu seseorang login ke cloud console dan melakukan perubahan kecil. Mungkin mereka mengganti nama security group karena dianggap membingungkan. Mungkin mereka menambahkan aturan inbound untuk menguji sesuatu dengan cepat. Mungkin mereka menghapus tag yang dirasa tidak perlu. Tidak ada perubahan kode. Tidak ada pipeline yang berjalan. Hanya ubahan manual di console.

Infrastruktur Anda sekarang berbeda dari apa yang seharusnya menurut kode Anda. Perbedaan itu disebut drift. Dan jika Anda tidak tahu itu terjadi, deployment Anda berikutnya bisa merusak sesuatu dengan cara yang tidak Anda duga.

Seperti Apa Drift Sebenarnya

Drift terjadi ketika kondisi aktual infrastruktur Anda menyimpang dari kondisi yang diinginkan (desired state) yang didefinisikan dalam kode. Ini bukan masalah teoretis. Ini terjadi sepanjang waktu di tim nyata:

  • Seseorang memperbaiki masalah mendesak langsung di produksi karena pipeline terlalu lama.
  • Penyedia cloud secara otomatis merotasi sertifikat atau mengubah pengaturan default.
  • Anggota tim tidak sengaja menghapus resource saat membersihkan hal lain.
  • Kebijakan otomatis di luar pipeline Anda memodifikasi resource untuk alasan kepatuhan.

Masalahnya bukan karena drift itu ada. Masalahnya adalah Anda tidak tahu tentangnya sampai ada yang rusak.

Latihan Sederhana untuk Melihat Drift dalam Aksi

Anda bisa mensimulasikan drift di lingkungan Anda sendiri dengan pengaturan minimal. Anda perlu akun cloud dengan resource tier gratis, atau bisa menggunakan simulator lokal seperti LocalStack. Bahkan file state tiruan pun cukup untuk tujuan pembelajaran.

Mulailah dengan membuat satu resource menggunakan Terraform. Security group di AWS atau storage bucket di penyedia cloud mana pun bisa digunakan. Jalankan pipeline Anda sampai resource terbuat dan state file tersimpan. Pastikan Anda bisa melihat resource tersebut di cloud console.

Berikut adalah konfigurasi Terraform minimal yang bisa Anda gunakan untuk mengikuti latihan ini:

# main.tf
provider "aws" {
  region = "us-east-1"
}

resource "aws_security_group" "web_sg" {
  name        = "web-server-sg"
  description = "Allow HTTP and SSH traffic"

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/8"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "web-server-sg"
    Env  = "test"
  }
}

Jalankan terraform init dan terraform apply untuk membuat security group. Kemudian, di AWS console, ubah nama security group secara manual menjadi web-server-sg-manual dan hapus tag Env. Terakhir, jalankan terraform plan untuk melihat drift:

$ terraform plan
aws_security_group.web_sg: Refreshing state... [id=sg-0123456789abcdef0]

Terraform will perform the following actions:

  # aws_security_group.web_sg will be updated in-place
  ~ resource "aws_security_group" "web_sg" {
        id          = "sg-0123456789abcdef0"
      ~ name        = "web-server-sg-manual" -> "web-server-sg"
        tags        = {
          - "Env"  = "test" -> null
            "Name" = "web-server-sg"
        }
        # (6 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Plan tersebut menunjukkan bahwa Terraform akan mengembalikan nama dan menambahkan kembali tag yang hilang. Inilah drift dalam aksi.

Sekarang, tanpa menyentuh kode Terraform Anda, buka cloud console dan lakukan perubahan manual. Berikut beberapa hal yang bisa Anda coba:

  • Ubah nama security group.
  • Tambahkan aturan inbound yang tidak ada di kode Anda.
  • Hapus tag yang didefinisikan oleh kode Anda.
  • Ubah pengaturan akses publik bucket.

Tujuannya adalah menciptakan situasi di mana resource aktual tidak lagi cocok dengan kode Anda. Inilah drift.

Diagram alir berikut mengilustrasikan urutan kejadian dalam latihan deteksi drift ini:

flowchart TD A[Desired State: Konfigurasi Terraform] --> B[Pipeline Membuat Resource] B --> C[Kondisi Aktual Cocok dengan Konfigurasi] C --> D[Perubahan Manual di Console] D --> E[Kondisi Aktual Menyimpang dari Konfigurasi] E --> F[Jalankan terraform plan] F --> G{Plan Menunjukkan Perubahan?} G -- Ya --> H[Drift Terdeteksi] G -- Tidak --> I[Tidak Ada Drift] H --> J{Keputusan Rekonsiliasi} J -- Terima Perubahan --> K[Perbarui Kode Terraform] J -- Kembalikan Konfigurasi --> L[Jalankan terraform apply] K --> M[Pipeline Berjalan, Kondisi Cocok] L --> M

Menjalankan Terraform Plan Setelah Drift

Setelah Anda melakukan perubahan manual, jalankan terraform plan di terminal Anda. Perhatikan outputnya dengan saksama. Terraform akan membandingkan state file Anda dengan resource aktual dan menunjukkan apa yang akan diubah jika Anda menjalankan apply.

Perhatikan sesuatu yang penting: plan mungkin menunjukkan perubahan yang tidak Anda duga. Mungkin ia ingin mengembalikan nama security group ke nama aslinya. Mungkin ia ingin menghapus aturan yang ditambahkan seseorang. Tapi mungkin juga ia menunjukkan perubahan pada resource lain yang bergantung pada resource yang Anda modifikasi. Penggantian nama sederhana bisa memengaruhi load balancer, target group, atau kebijakan IAM yang mereferensi security group berdasarkan nama.

Inilah mengapa Anda tidak bisa begitu saja percaya pada plan setelah drift terjadi. Plan mungkin benar, tetapi Anda perlu memverifikasi setiap perubahan yang diusulkan. Plan yang terlihat bersih di permukaan bisa menyembunyikan efek berantai yang merusak bagian lain dari infrastruktur Anda.

Mendeteksi Drift Secara Eksplisit

Terraform memiliki perintah bernama terraform refresh yang memperbarui state file Anda dengan kondisi aktual resource Anda. Jalankan perintah itu, lalu jalankan terraform plan lagi. Anda akan melihat drift yang sama, tetapi sekarang state file Anda mencerminkan kenyataan. Ini berguna untuk memahami apa yang berubah, tetapi tidak memperbaiki drift. Ia hanya mengakuinya.

Beberapa platform seperti Spacelift atau Terragrunt memiliki deteksi drift bawaan yang berjalan secara terjadwal. Mereka dapat memberi tahu Anda saat drift terdeteksi, dan beberapa bahkan dapat memicu rekonsiliasi otomatis. Namun untuk latihan ini, deteksi manual sudah cukup untuk memahami mekanismenya.

Catat resource mana yang mengalami drift dan apa yang berubah. Catatan ini akan membantu Anda berpikir tentang langkah selanjutnya.

Membuat Keputusan Rekonsiliasi

Sekarang Anda punya pilihan. Anda tahu infrastruktur telah mengalami drift. Anda tahu apa yang berubah. Apa yang akan Anda lakukan?

Tanyakan pada diri Anda pertanyaan-pertanyaan ini:

  • Apakah perubahan manual itu disengaja? Apakah seseorang melakukannya untuk alasan yang sah, seperti memperbaiki masalah mendesak?
  • Apakah perubahan itu masih diperlukan? Mungkin keadaan darurat sudah selesai dan resource harus kembali ke kondisi semula.
  • Apakah aman untuk mengembalikan perubahan? Mengembalikan perubahan mungkin merusak sesuatu yang sekarang bergantung pada konfigurasi baru.
  • Apakah ada anggota tim yang tahu mengapa perubahan itu dilakukan? Apakah ada catatan di tiket atau log obrolan?

Jika Anda memutuskan untuk melakukan rekonsiliasi, jalankan terraform apply. Resource akan kembali ke kondisi yang didefinisikan dalam kode Anda. Verifikasi bahwa semuanya berfungsi seperti yang diharapkan.

Jika Anda memutuskan untuk mengadopsi perubahan, perbarui kode Terraform Anda agar sesuai dengan kondisi aktual. Kemudian jalankan pipeline Anda seperti biasa. Drift sekarang terselesaikan karena kode dan infrastruktur Anda kembali selaras.

Variasi untuk Dicoba

Setelah Anda memahami skenario dasar, cobalah variasi yang lebih kompleks:

  • Buat perubahan sementara, seperti meningkatkan kapasitas instance selama lonjakan lalu lintas. Lihat bagaimana deteksi drift menangkapnya setelah lonjakan selesai.
  • Ubah resource yang memiliki dependensi, seperti memodifikasi konfigurasi load balancer yang terhubung ke target group. Amati bagaimana plan menunjukkan efek berantai.
  • Buat perubahan yang sulit dikembalikan, seperti menghapus resource yang bergantung pada resource lain. Lihat bagaimana Terraform menangani rantai dependensi.

Setiap variasi mengajarkan Anda sesuatu tentang bagaimana drift berperilaku di sistem nyata. Semakin kompleks skenarionya, semakin jelas bahwa deteksi dan rekonsiliasi drift membutuhkan pemikiran yang cermat, bukan sekadar otomatisasi.

Daftar Periksa Praktis untuk Manajemen Drift

Sebelum Anda melanjutkan, berikut adalah daftar periksa singkat yang bisa diterapkan di lingkungan Anda sendiri:

  • Siapkan deteksi drift otomatis pada resource infrastruktur kritis Anda.
  • Tentukan proses yang jelas untuk menangani drift: siapa yang mendapat notifikasi, bagaimana keputusan dibuat, dan kapan rekonsiliasi dipicu.
  • Simpan catatan perubahan manual, bahkan yang bersifat sementara, sehingga tim tahu mengapa drift ada.
  • Uji proses rekonsiliasi Anda di lingkungan non-produksi sebelum menerapkannya ke produksi.
  • Tinjau laporan drift secara teratur, bukan hanya saat ada yang rusak.

Apa yang Dipelajari dari Latihan Ini

Drift bukanlah konsep teoretis. Ini adalah masalah operasional nyata yang dihadapi setiap tim ketika infrastruktur dikelola melalui kode. Latihan ini menunjukkan bahwa drift bisa terjadi secara diam-diam, bahwa ia bisa memengaruhi lebih dari sekadar resource yang diubah, dan bahwa keputusan rekonsiliasi selalu bergantung pada konteks.

Anda tidak bisa mencegah semua drift. Orang akan melakukan perubahan manual. Penyedia cloud akan memodifikasi resource. Keadaan darurat akan terjadi. Yang bisa Anda lakukan adalah mendeteksi drift sejak dini, memahami dampaknya, dan membuat keputusan yang tepat tentang apakah akan mengembalikan atau mengadopsi perubahan.

Lain kali seseorang berkata "Saya hanya melakukan perbaikan cepat di console," Anda akan tahu persis apa artinya itu bagi infrastruktur Anda. Dan Anda akan memiliki proses yang siap untuk menanganinya.