Ketika Infrastruktur Drift Membuat Rencana Terraform Anda Tidak Berguna

Anda menjalankan pipeline untuk men-deploy versi aplikasi baru. Terraform plan berjalan, dan keluarannya menunjukkan bahwa ia ingin mengubah ukuran instance database produksi Anda. Tidak ada seorang pun di tim yang berniat menyentuh database. Reviewer pull request menatap plan tersebut dengan bingung. Apakah ini efek samping dari versi baru? Persyaratan keamanan yang terlewat? Seseorang menyetujuinya hanya untuk membuka blokir rilis, dan tiba-tiba database Anda berjalan di perangkat keras yang lebih kecil saat lalu lintas puncak.

Skenario ini bukan hipotetis. Ini terjadi ketika infrastruktur telah menyimpang dari apa yang didefinisikan oleh kode Anda. Dan begitu drift terjadi, alat Anda yang paling tepercaya untuk perubahan infrastruktur yang aman menjadi tidak dapat diandalkan.

Apa Arti Drift Sebenarnya

Infrastruktur drift adalah celah antara apa yang dikatakan kode Anda tentang infrastruktur dan apa yang sebenarnya ada di lingkungan cloud Anda. Anda menulis kode Terraform, Pulumi, atau CloudFormation yang mendefinisikan sumber daya Anda. Seseorang masuk ke konsol cloud dan mengubah tipe instance, menambahkan aturan security group, atau menyesuaikan parameter database. Perubahan itu tidak pernah menyentuh repositori kode Anda. Itu tidak pernah melalui pipeline. Itu hanya terjadi.

Infrastruktur masih berfungsi. Aplikasi masih berjalan. Tapi kode Anda tidak lagi menggambarkan kenyataan. Ia menggambarkan seperti apa kenyataan dulu.

Rencana yang Berbohong kepada Anda

Alat Infrastructure as Code seperti Terraform bekerja dengan membandingkan dua hal: definisi kode Anda dan file state (yang melacak apa yang ada di cloud). Ketika keduanya cocok, plan yang Anda dapatkan akurat. Ia menunjukkan dengan tepat apa yang akan berubah berdasarkan komit kode terbaru Anda.

Diagram alir berikut menunjukkan bagaimana drift menciptakan ketidakcocokan antara kode, state, dan infrastruktur aktual, yang mengarah ke plan yang tidak akurat:

flowchart TD A[Definisi Kode] --> B[Rencana Terraform] C[File State] --> B D[Infrastruktur Aktual] -.->|drift| C D -.->|tidak sinkron| B B --> E[Plan Menunjukkan Perubahan yang Tidak Diinginkan] style D fill:#f9f,stroke:#333,stroke-width:2px style E fill:#f96,stroke:#333,stroke-width:2px

Drift merusak perbandingan ini. File state menjadi usang karena infrastruktur aktual berubah di luar pipeline. Ketika Terraform menjalankan plan, ia membaca state yang basi dan membandingkannya dengan kode Anda. Hasilnya terlihat seperti Terraform ingin membuat perubahan, tetapi perubahan itu sebenarnya adalah koreksi untuk mengembalikan infrastruktur ke apa yang dikatakan kode Anda. Bukan perubahan yang Anda maksudkan untuk dilakukan.

Ini adalah plan drift: sebuah plan yang mencerminkan perbedaan yang sudah ada sebelumnya antara kode dan kenyataan, bukan perubahan yang benar-benar ingin Anda deploy.

Tiga Cara Drift Merusak Pipeline Anda

Penghancuran yang Tidak Terduga

Ini adalah hasil yang paling berbahaya. Bayangkan sebuah network security group yang dibuat secara manual oleh tim keamanan Anda untuk mengisolasi beban kerja sensitif. Sumber daya itu tidak ada dalam kode IaC Anda. Ketika pipeline Anda menjalankan terraform apply menggunakan kode yang tidak pernah mendefinisikan sumber daya itu, Terraform melihatnya sebagai sesuatu yang seharusnya tidak ada. Ia menghancurkannya. Konfigurasi keamanan Anda lenyap secara diam-diam, dan tidak ada yang menyadarinya sampai sesuatu rusak.

Waktu Review yang Terbuang

Reviewer pull request melihat plan yang menunjukkan perubahan pada sumber daya yang tidak terkait dengan fitur yang sedang di-deploy. Mereka tidak dapat membedakan apakah ini efek samping yang tidak disengaja, pembaruan yang diperlukan, atau sesuatu yang mencurigakan. Waktu dihabiskan untuk menyelidiki perubahan yang sebenarnya bukan bagian dari pekerjaan. Siklus review menjadi lebih panjang. Tim mulai mengajukan pertanyaan seperti "Apakah seseorang menyentuh produksi lagi?" alih-alih fokus pada perubahan kode yang sebenarnya.

Kepercayaan pada Otomatisasi yang Rusak

Ketika plan terus menunjukkan perubahan yang tidak terduga, tim berhenti mempercayai pipeline. Mereka melakukan pengecekan manual sebelum men-deploy. Mereka mulai membuat perubahan langsung di konsol karena pipeline terasa tidak dapat diandalkan. Ironisnya brutal: semakin banyak perubahan terjadi di luar pipeline, semakin parah driftnya. Pipeline menjadi kurang dapat dipercaya, sehingga orang lebih sering melewatinya, yang membuatnya semakin tidak dapat dipercaya.

Mengapa Drift Terjadi di Tim Nyata

Drift tidak disebabkan oleh engineer yang buruk. Ini terjadi karena pekerjaan nyata menciptakan situasi di mana pipeline bukanlah jalur tercepat:

  • Sebuah insiden memerlukan perubahan segera. Engineer yang sedang on-call memperbaikinya di konsol karena menulis kode, melakukan commit, dan menunggu pipeline memakan waktu terlalu lama.
  • Seorang administrator database menyesuaikan parameter langsung di konsol cloud karena mereka tidak bekerja dengan alat IaC setiap hari.
  • Sebuah tim keamanan menambahkan aturan firewall sementara selama audit dan lupa mendokumentasikannya.
  • Seorang pengembang perlu menguji sesuatu dengan cepat dan secara manual membuat sumber daya, berencana untuk "menambahkannya ke kode nanti."

Masing-masing tindakan ini masuk akal secara terpisah. Bersama-sama, mereka menciptakan celah antara kode dan kenyataan yang tumbuh hingga pipeline tidak dapat dipercaya.

Mendeteksi Drift Sebelum Merugikan

Perbaikannya bukan melarang akses konsol. Pendekatan itu gagal karena keadaan darurat dan kebutuhan operasional yang sah akan selalu melewati aturan yang kaku. Perbaikannya adalah mendeteksi drift secara otomatis dan menampilkannya sebelum seseorang menjalankan plan.

Sebagian besar alat IaC menawarkan fitur deteksi drift. Terraform Cloud dan Enterprise memiliki deteksi drift yang menjalankan plan sesuai jadwal dan memberi peringatan ketika infrastruktur nyata berbeda dari state. OpenTofu, fork open-source dari Terraform, menyertakan kemampuan serupa. Anda juga dapat membangun deteksi Anda sendiri menggunakan pipeline terjadwal yang membandingkan state terhadap sumber daya cloud aktual.

Kuncinya adalah membuat drift terlihat. Ketika anggota tim mengubah sesuatu di konsol, pemeriksaan drift terjadwal berikutnya harus menandainya. Tim kemudian dapat memutuskan: perbarui kode agar sesuai dengan perubahan, atau kembalikan perubahan ke apa yang didefinisikan kode. Kedua pilihan itu valid, selama itu disengaja dan dilacak.

Daftar Periksa Deteksi Drift Praktis

Jika Anda mengelola infrastruktur dengan IaC, pertimbangkan untuk menambahkan pemeriksaan ini ke rutinitas Anda:

  • Jadwalkan deteksi drift mingguan untuk lingkungan produksi
  • Beri peringatan pada tim ketika drift ditemukan, bukan hanya ketika menyebabkan kegagalan
  • Tinjau laporan drift dalam sinkronisasi tim rutin Anda
  • Dokumentasikan proses yang jelas untuk merekonsiliasi drift: perbarui kode atau kembalikan perubahan
  • Perlakukan perubahan konsol manual sebagai solusi sementara, bukan solusi permanen

Biaya Nyata Mengabaikan Drift

Drift tidak langsung merusak infrastruktur Anda. Ia mengikis keandalan pipeline Anda secara perlahan. Setiap drift yang tidak terdeteksi membuat plan berikutnya kurang dapat dipercaya. Setiap plan yang mengejutkan tim membuat mereka kurang bersedia untuk mengotomatisasi. Pada akhirnya, infrastruktur Anda menjadi kotak hitam di mana tidak ada yang tahu apa yang sebenarnya berjalan, dan repositori kode menjadi dokumen aspirasional daripada sumber kebenaran.

Tujuannya bukan untuk menghilangkan drift sepenuhnya. Beberapa drift tidak dapat dihindari dalam sistem yang kompleks. Tujuannya adalah mendeteksinya dengan cepat, membuatnya terlihat, dan memberi tim Anda jalur yang jelas untuk merekonsiliasinya. Ketika plan Anda hanya menunjukkan perubahan yang Anda maksudkan, Anda dapat mempercayai pipeline Anda lagi.