Saat Menjalankan Terraform dari Laptop Tidak Lagi Cukup

Anda selama ini mengelola infrastruktur dengan Terraform dari terminal. Semua berjalan baik ketika Anda satu-satunya yang membuat perubahan. Anda menjalankan terraform plan, memeriksa keluarannya, menjalankan terraform apply, dan melanjutkan pekerjaan. File state ada di mesin Anda, dan Anda tahu persis apa yang Anda ubah dan kapan.

Kemudian seorang rekan bergabung ke proyek. Mereka meng-clone repositori, menjalankan terraform init, dan mendapatkan plan yang berbeda dari yang Anda lihat kemarin. File state di laptop mereka sudah usang. Seseorang menerapkan perubahan tanpa memberi tahu siapa pun. Seminggu kemudian, tidak ada yang ingat siapa yang memodifikasi aturan security group atau mengapa.

Inilah momen ketika workflow berbasis laptop mulai bermasalah. Masalahnya bukan pada Terraform itu sendiri, tetapi pada koordinasi, visibilitas, dan akuntabilitas. Ketika infrastruktur digunakan bersama, menjalankan perintah dari mesin masing-masing menciptakan kebingungan, risiko, dan penyimpangan diam-diam (silent drift).

Memindahkan Workflow ke dalam Pipeline

Alih-alih menjalankan terraform plan dan terraform apply dari laptop masing-masing, Anda dapat memindahkan workflow tersebut ke dalam pipeline CI/CD. Setiap perubahan infrastruktur kemudian melalui jalur yang sama, tercatat, dan dapat ditinjau oleh tim sebelum diterapkan.

Pendekatan pipeline mengubah perubahan infrastruktur menjadi sesuatu yang mirip dengan perubahan kode aplikasi. Anda menulis konfigurasi, membuka pull request, mendapatkan umpan balik, dan hanya setelah disetujui perubahan tersebut diterapkan. Perbedaannya adalah Terraform menambahkan langkah perencanaan yang menunjukkan dengan tepat apa yang akan terjadi pada sumber daya cloud Anda sebelum semuanya dijalankan.

Contoh berikut menunjukkan konfigurasi pipeline CI generik yang mengimplementasikan workflow write-plan-apply:

stages:
  - validate
  - plan
  - apply

validate:
  stage: validate
  script:
    - terraform fmt -check
    - terraform validate
  only:
    - merge_requests

plan:
  stage: plan
  script:
    - terraform plan -out=plan.tfplan
  artifacts:
    paths:
      - plan.tfplan
  only:
    - merge_requests

apply:
  stage: apply
  script:
    - terraform apply plan.tfplan
  when: manual
  only:
    - main

Tiga Tahap: Write, Plan, Apply

Cara paling umum untuk mengintegrasikan Terraform ke dalam pipeline adalah dengan membagi workflow menjadi tiga tahap yang sesuai dengan alur alami dalam membuat perubahan.

Diagram urutan berikut mengilustrasikan bagaimana ketiga tahap tersebut berinteraksi:

Write: Tangkap Masalah Sebelum Review

Tahap write dimulai ketika seseorang memodifikasi file konfigurasi Terraform dan membuka pull request. Pada titik ini, pipeline dapat menjalankan pemeriksaan dasar secara otomatis. terraform fmt memverifikasi bahwa kode mengikuti format standar. terraform validate memeriksa bahwa konfigurasi benar secara sintaksis dan semua argumen yang diperlukan sudah ada.

Pemeriksaan ini adalah padanan infrastruktur dari menjalankan linter pada kode aplikasi. Mereka menangkap kesalahan sederhana sejak awal, sebelum seorang reviewer menghabiskan waktu melihat pull request. Jika format salah atau field yang diperlukan hilang, pipeline langsung gagal, dan penulis memperbaikinya sebelum orang lain terlibat.

Plan: Tunjukkan Apa yang Akan Berubah

Setelah pull request dibuka, pipeline menjalankan terraform plan secara otomatis. Output dari plan kemudian diposting sebagai komentar pada pull request. Di sinilah review menjadi bermakna.

Output plan menunjukkan dengan tepat apa yang akan dilakukan Terraform: sumber daya mana yang akan dibuat, mana yang akan dimodifikasi, dan mana yang akan dihapus. Seorang reviewer dapat melihat bahwa pull request mengubah tipe instance server dari small ke medium, atau menambahkan aturan firewall baru, atau menghapus grup subnet database lama. Jika ada yang terlihat salah, reviewer menolak pull request sebelum perubahan mencapai production.

Tahap ini sangat penting karena mengubah review infrastruktur dari "percayalah, saya sudah menjalankan plan" menjadi "ini plan-nya, periksa sendiri." Plan menjadi bagian dari percakapan pull request, dan keputusan untuk menyetujui atau menolak didasarkan pada output konkret, bukan pada kepercayaan semata.

Apply: Eksekusi Hanya Setelah Persetujuan

Tahap apply hanya berjalan setelah pull request disetujui dan di-merge ke branch utama. Pipeline di branch utama kemudian mengeksekusi terraform apply menggunakan plan yang sudah di-review.

Cara teraman untuk melakukan ini adalah dengan menyimpan output plan dari tahap sebelumnya sebagai file dan meneruskan file tersebut ke terraform apply. Teknik ini disebut saved plan. Ini menjamin bahwa apply menjalankan perubahan yang persis sama dengan yang di-review, bukan plan baru yang mungkin berbeda karena seseorang mendorong commit lain antara review dan apply.

Tanpa saved plan, pipeline akan menjalankan terraform plan lagi selama tahap apply. Jika konfigurasi berubah di antaranya, plan baru bisa berbeda dari yang sudah di-review. Itu menghilangkan tujuan dari adanya review.

Mengelola State dalam Pipeline

Manajemen state menjadi mudah ketika Terraform berjalan dalam pipeline. File state harus disimpan di lokasi bersama, seperti bucket penyimpanan cloud atau backend Terraform yang dikonfigurasi tim sekali. Setiap kali pipeline menjalankan plan atau apply, ia mengambil state dari lokasi bersama tersebut, bukan dari salinan lokal yang mungkin sudah usang.

Pipeline juga harus mengaktifkan state locking. Terraform dapat mengunci file state saat plan atau apply sedang berjalan, mencegah dua proses memodifikasi state secara bersamaan. Tanpa penguncian, dua pipeline bisa menjalankan apply secara simultan, menyebabkan korupsi atau hasil yang tidak terduga.

Apa yang Didapatkan dari Workflow Ini

Setelah workflow write-plan-apply berjalan dalam pipeline, perubahan infrastruktur mengikuti disiplin yang sama seperti perubahan kode aplikasi. Setiap perubahan melalui pull request, di-review oleh anggota tim, diuji dengan plan otomatis, dan hanya berjalan setelah disetujui. Seluruh riwayat perubahan tercatat di Git dan di log pipeline.

Anda tidak lagi bertanya-tanya siapa yang mengubah server atau kapan itu terjadi. Anda tidak lagi khawatir tentang file state usang di laptop seseorang. Anda tidak lagi mendengar "di mesin saya berhasil" tentang infrastruktur.

Daftar Periksa Praktis untuk Pengaturan Ini

• Konfigurasikan backend jarak jauh untuk penyimpanan state sebelum menyiapkan pipeline. Backend harus dapat diakses oleh runner pipeline.
• Siapkan state locking. Sebagian besar backend seperti S3 dengan DynamoDB atau GCS dengan versioning objek mendukung ini secara native.
• Tambahkan terraform fmt dan terraform validate sebagai pemeriksaan awal di pipeline pull request.
• Jalankan terraform plan pada setiap pull request dan posting outputnya sebagai komentar.
• Gunakan saved plans. Simpan file plan sebagai artefak pipeline dan teruskan ke tahap apply.
• Batasi terraform apply untuk berjalan hanya di branch utama setelah merge.
• Pastikan runner pipeline memiliki izin minimum yang diperlukan untuk mengeksekusi plan dan apply. Jangan gunakan kredensial admin.

Apa Selanjutnya

Setelah pipeline menangani workflow write-plan-apply secara otomatis, pertanyaan berikutnya adalah bagaimana mengelola lingkungan yang berbeda. Staging dan production jarang menggunakan nilai konfigurasi yang sama. Pipeline perlu menangani variabel khusus lingkungan, file state, dan gerbang persetujuan tanpa menduplikasi seluruh workflow untuk setiap lingkungan.

Tapi itu masalah untuk nanti. Untuk saat ini, langkah pentingnya adalah berhenti menjalankan Terraform dari laptop dan mulai memperlakukan perubahan infrastruktur seperti perubahan kode. Pipeline memberi Anda satu sumber kebenaran untuk apa yang berubah, siapa yang menyetujuinya, dan kapan itu diterapkan. Itu saja sudah menghilangkan sebagian besar kebingungan yang muncul dengan infrastruktur bersama.