Belajar OpenTofu - Infrastructure Drift Detection & Auto-Remediation

#Pendahuluan

Di episode 17 sebelumnya kita merancang infrastruktur multi-cloud lengkap — AWS, GCP, Cloudflare, hingga Kubernetes — semuanya dideklarasikan sebagai kode. Namun deklarasi yang bagus punya musuh yang diam-diam: drift. Realita cloud bisa menyimpang dari kode tanpa kita sadari, dan jika dibiarkan, drift menggerogoti kepercayaan kita pada IaC.

Di episode 18 kali ini, kita akan membahas Infrastructure Drift Detection & Auto-Remediation. Kita akan belajar mendeteksi ketidaksesuaian antara realitas cloud dan state file, mengotomasi pemeriksaan berkala dengan tofu plan -detailed-exitcode, dan merancang strategi remediasi yang aman agar infrastruktur selalu kembali ke kondisi yang dideklarasikan.

#Apa Itu Infrastructure Drift?

Infrastructure drift adalah kondisi ketika konfigurasi resource di cloud sudah berbeda dari yang tercatat di state file maupun yang dideklarasikan di kode. Sumber drift paling umum adalah manual ClickOps: seorang engineer masuk ke konsol cloud, mengubah security group, menambah instance, atau menonaktifkan encryption — semua tanpa mengubah kode.

Anggap state file sebagai resep masakan dan cloud sebagai hidangan yang sudah jadi. Drift adalah ketika dapur secara diam-diam mengganti bahan — garam diganti gula — tanpa memberi tahu kita. Hidangan yang terlihat sama ternyata rasanya sudah berbeda, dan kita baru sadar ketika pelanggan mengeluh.

#Dampak Drift yang Sering Terlupakan

Drift bukan sekadar masalah estetika. Beberapa dampaknya:

• Kehilangan kontrol — resource yang tidak tercatat state menjadi "yatim", tidak ada yang mengelola lifecycle-nya.
• Risiko keamanan — konfigurasi yang melenceng sering kali lebih longgar dari standar.
• Plan tidak terduga — tofu plan berikutnya menampilkan perubahan tak terduga yang membingungkan reviewer.
• Rollback sulit — ketika insiden terjadi, state tidak lagi mencerminkan kenyataan sehingga pemulihan menjadi teka-teki.

Karena itu, deteksi drift harus berjalan terus-menerus, bukan hanya saat engineer ingat menjalankan tofu plan.

#Mendeteksi Drift dengan -detailed-exitcode

Perintah tofu plan biasa selalu mengembalikan exit code 0 ketika plan berhasil dibuat — tanpa peduli apakah ada perubahan atau tidak. Padahal kita perlu membedakan tiga keadaan. Di sinilah flag -detailed-exitcode berperan:

tofu plan -detailed-exitcode -out=plan.tfplan
echo "Exit code: $?"

Exit code: 2

Flag -detailed-exitcode mengubah perilaku tofu plan menjadi jauh lebih informatif:

Exit code 2 adalah sinyal utama drift. Dengan memeriksa kode ini secara terprogram, mesin bisa mengetahui kapan infrastruktur menyimpang tanpa perlu membaca output teks yang panjang.

#Automasi Drift Detection dengan Scheduled Pipeline

Menjalankan tofu plan secara manual bukanlah strategi. Kita otomasi dengan GitHub Actions menggunakan trigger schedule dengan cron — seperti yang kita bangun kerangkanya di episode 13:

name: drift-detect
 
on:
  schedule:
    - cron: "0 6 * * *"
  workflow_dispatch:
 
permissions:
  id-token: write
  contents: read
 
jobs:
  detect:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - uses: opentofu/setup-opentofu@v1
 
      - name: Configure AWS credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-oidc
          aws-region: ap-southeast-1
 
      - name: Detect drift
        id: plan
        run: |
          tofu init
          tofu plan -detailed-exitcode -no-color > plan.log
          status=$?
          echo "plan_exit=$status" >> "$GITHUB_OUTPUT"
          if [ "$status" -eq 2 ]; then
            echo "drift-found=true" >> "$GITHUB_OUTPUT"
          fi

Workflow ini berjalan setiap pukul 06.00 pagi dan bisa juga dipicu manual. Yang menarik: dengan ekspresi schedule, pipeline mendeteksi drift tanpa menunggu ada PR. Jika status bernilai 2, maka variabel drift-found bernilai true dan siap dikonsumsi langkah berikutnya.

#Strategi Remediasi Otomatis

Menemukan drift itu setengah pekerjaan; memperbaikinya adalah setengah lainnya. Ada beberapa strategi dengan tingkat agresivitas berbeda:

#Strategi 1: Sinkronkan State Saja

Jika drift terjadi karena perubahan kecil di cloud yang memang diinginkan, kita bisa mencatatnya ke state tanpa mengubah resource:

tofu apply -refresh-only

Perintah tofu apply -refresh-only memperbarui state agar sesuai realita cloud tanpa mengubah satu resource pun. Berguna ketika perubahan di cloud dilakukan secara sah dan kita hanya ingin state mengikutinya.

#Strategi 2: Auto-Apply Plan

Jika kita yakin kode adalah sumber kebenaran, drift di-remediasi dengan menjalankan plan hasil deteksi:

      - name: Auto-remediate drift
        if: steps.plan.outputs.drift-found == 'true'
        run: |
          tofu apply plan.tfplan -auto-approve

Alur ini otomatis mengembalikan infrastruktur ke kondisi yang dideklarasikan. Inilah makna sesungguhnya dari convergence: sistem terus-menerus menuju keadaan ideal.

#Strategi 3: Pemberitahuan dan Tinjauan

Untuk infrastruktur kritis, remediasi otomatis penuh mungkin terlalu berisiko. Alternatifnya adalah mengirim notifikasi ke tim — misalnya menambahkan langkah yang membuka issue di repository atau mengirim pesan ke Slack — lalu menunggu manusia memutuskan. Strategi ini menempatkan manusia di dalam loop, bukan di luar.

#Praktik Terbaik Deteksi Drift

Beberapa hal yang perlu diperhatikan agar sistem deteksi drift berjalan sehat:

• Jalankan deteksi di setiap environment, bukan hanya produksi.
• Simpan log hasil plan sebagai artifact pipeline untuk audit.
• Pisahkan drift dari perubahan yang direncanakan — perhatikan apakah drift-found muncul di luar window deploy.
• Kombinasikan dengan prevent_destroy dan lifecycle untuk resource yang tidak boleh dihapus otomatis.
• Gunakan data source remote state agar tiap environment memeriksa state-nya sendiri.

#Penutup

Pada episode 18 ini, kita telah membahas Infrastructure Drift Detection & Auto-Remediation. Kita sudah belajar apa itu drift, bagaimana tofu plan -detailed-exitcode membedakan tiga keadaan, cara mengotomasi pemeriksaan dengan scheduled pipeline, serta strategi remediasi dari yang pasif hingga yang agresif.

Key takeaway:

• Drift adalah ketidaksesuaian antara realitas cloud, state, dan kode — umumnya akibat ClickOps.
• tofu plan -detailed-exitcode mengembalikan exit code 0, 1, atau 2.
• Exit code 2 berarti ada perubahan dan bisa jadi tanda drift.
• Scheduled pipeline dengan schedule membuat deteksi berjalan otomatis setiap hari.
• tofu apply -refresh-only menyinkronkan state tanpa mengubah resource.
• Auto-apply mengembalikan infrastruktur ke kondisi ideal, tapi harus dibatasi ke environment yang tidak kritis.

Deteksi dan remediasi otomatis membuat infrastruktur kalian selalu terkendali, bahkan ketika manusia membuat kesalahan di konsol. Namun semua sistem ini tidak berarti apa-apa jika state kalian rusak atau hilang. Di episode 19 nanti, kita akan membahas Disaster Recovery & Encrypted State Recovery — cara memulihkan diri ketika yang terburuk terjadi. Sampai jumpa!