Apa yang Sebenarnya Diperiksa terraform validate?

terraform validate adalah subperintah bawaan Terraform yang melakukan analisis statis pada berkas konfigurasi Anda. Ia membaca setiap berkas .tf dan .tfvars di direktori kerja saat ini (dan secara rekursif modul lokal apa pun), mengurainya, lalu memeriksa apakah konfigurasi konsisten secara internal dan valid secara struktur.

Analisis statis, bukan eksekusi

Ciri utama terraform validate adalah ia sepenuhnya statis. Tidak ada koneksi jaringan yang dibuat, tidak ada API provider yang dipanggil, dan tidak ada berkas state yang dibaca. Pemeriksaan terjadi sepenuhnya di memori pada mesin yang menjalankan perintah. Ini membuatnya aman dijalankan di lingkungan apa pun, termasuk runner CI tanpa kredensial cloud, dan selesai di bawah dua detik pada sebagian besar konfigurasi nyata.

Ini berbeda dari terraform plan, yang melakukan semua pemeriksaan statis yang sama lalu terhubung ke API provider untuk menghitung selisih terhadap infrastruktur nyata. Validate adalah filter pertama yang ringan; plan adalah filter menyeluruh sebelum penerapan. Menjalankan keduanya secara berurutan memberi cakupan terluas sebelum Anda menyetujui perubahan infrastruktur.

Tiga mode operasi

• Mode default - berjalan setelah terraform init; memeriksa sintaks, skema terhadap plugin provider yang diunduh, dan referensi antar berkas
• Tanpa init - jika direktori .terraform tidak ada, validate tetap berjalan tetapi melewati pemeriksaan skema provider dan hanya melaporkan galat parsing HCL serta masalah referensi yang bisa diselesaikan tanpa metadata provider
• Mode JSON (-json) - mengeluarkan objek JSON terstruktur dengan boolean valid, bilangan bulat error_count, dan array diagnostics yang cocok untuk diproses CI dan integrasi editor

Memahami tiga kategori yang dicakup terraform validate membantu Anda tahu persis apa yang dijamin oleh validasi yang lolos, dan di mana jaminan itu berakhir.

1. Kebenaran sintaks HCL

Pass pertama mengurai setiap berkas .tf untuk sintaks HCL2 yang valid. Ini menangkap kurung kurawal yang tidak ditutup, tanda sama dengan yang hilang pada penetapan atribut, definisi blok yang tidak valid, penggunaan sintaks heredoc yang salah, dan konstruksi lain yang bukan HCL valid. Berkas yang gagal pada pemeriksaan ini tidak bisa dibaca Terraform sama sekali: plan dan apply juga akan gagal. Validate menangkap galat ini segera dengan path berkas dan nomor baris.

2. Kesesuaian dengan skema provider

Setelah parsing, validate memeriksa setiap blok resource, blok sumber data, dan konfigurasi provider terhadap skema yang didefinisikan plugin provider terkait. Skema menentukan argumen mana yang valid, mana yang wajib dan mana yang opsional, serta tipe apa yang diharapkan setiap argumen (string, number, bool, list, map, object). Validate menangkap argumen yang tidak ada untuk tipe resource tertentu, argumen dengan tipe salah (misalnya memberikan string padahal butuh number), dan argumen wajib yang sama sekali tidak ada.

3. Keabsahan referensi internal

Kategori ketiga adalah pemeriksaan referensi silang di dalam konfigurasi. Konfigurasi Terraform rutin mereferensikan resource lain, variabel, local, keluaran modul, dan sumber data berdasarkan nama. Validate memeriksa bahwa setiap referensi (misalnya var.region, local.common_tags, aws_vpc.main.id, module.networking.subnet_ids) menunjuk ke sesuatu yang benar-benar dideklarasikan di suatu tempat dalam konfigurasi. Variabel yang tidak dideklarasikan, salah ketik pada referensi resource, atau keluaran modul yang hilang akan tertangkap di sini.

Batas terraform validate sama pentingnya dengan cakupannya. Banyak pengembang mengetahui batas ini setelah konfigurasi yang lolos validasi gagal saat penerapan. Setiap kategori ini memerlukan terraform plan, uji integrasi, atau alat kebijakan seperti tflint atau Checkov.

Nilai argumen resource yang sebenarnya

Validate memeriksa bahwa argumen ada dan bertipe benar, tetapi tidak bisa memeriksa apakah nilainya valid di dunia nyata. Resource aws_instance bisa punya argumen ami berupa string (tipe benar), tetapi validate tidak punya cara mengetahui apakah AMI ID itu ada di akun atau region AWS Anda. AMI tidak valid, ID security group yang tidak ada, atau nama zona ketersediaan yang salah akan lolos validate dan hanya gagal di plan atau apply.

Berkas state dan infrastruktur yang sudah ada

Validate tidak pernah membaca berkas state Terraform Anda. Ia tidak bisa mendeteksi bahwa resource yang Anda definisikan berkonflik dengan yang sudah ada, bahwa sebuah resource dihapus di luar Terraform (pergeseran state), atau bahwa perubahan yang direncanakan melanggar batasan yang hanya bisa dievaluasi terhadap infrastruktur nyata saat ini. Semua itu urusan fase plan dan apply.

Ekspresi dinamis yang bergantung pada sumber data

Ekspresi count, for_each, dan kondisional adalah HCL valid dan validate mengurainya tanpa masalah. Tetapi jika nilainya bergantung pada sumber data (misalnya for_each = toset(data.aws_availability_zones.available.names)), ekspresi itu tidak bisa dievaluasi sepenuhnya saat validasi karena sumber data belum dikueri. Validate memastikan sintaks ekspresinya benar; ia tidak bisa memastikan hasil saat berjalan.

Autentikasi dan izin provider

Validate tidak membuat panggilan API sama sekali. Ia tidak akan mendeteksi bahwa kredensial AWS Anda kedaluwarsa, bahwa akun layanan Anda kurang izin IAM yang diperlukan, atau bahwa konfigurasi provider menunjuk region atau proyek yang salah. Semua galat autentikasi hanya muncul di fase plan atau apply, ketika klien provider benar-benar diinisialisasi dan panggilan dilakukan.

Kebijakan keamanan dan aturan kepatuhan

Validate tidak punya konsep kebijakan keamanan. Bucket S3 yang dikonfigurasi publik, instans EC2 tanpa enkripsi, atau security group dengan ingress 0.0.0.0/0 pada port 22 semuanya akan lolos validate tanpa peringatan. Pemeriksaan keamanan dan kepatuhan memerlukan alat kebijakan khusus seperti Checkov, tfsec, atau HashiCorp Sentinel.

Sumber kebingungan paling umum tentang terraform validate adalah bedanya dengan terraform plan. Keduanya banyak tumpang tindih tetapi bekerja pada level berbeda, dan keduanya diperlukan untuk alur lengkap sebelum penerapan.

terraform validate memeriksa apakah konfigurasi valid secara sintaks dan konsisten secara internal, terlepas dari variabel yang diberikan atau state yang ada.

Di mana keduanya tumpang tindih

Kedua perintah mengurai berkas HCL Anda dan mencari galat sintaks. Keduanya memeriksa skema provider bila plugin provider tersedia. Keduanya memvalidasi referensi internal. Galat konfigurasi yang ditangkap terraform validate juga akan ditangkap terraform plan: validate hanya lebih cepat dan tidak memerlukan kredensial cloud atau backend state.

Di mana plan melangkah lebih jauh

terraform plan menginisialisasi klien provider, melakukan autentikasi ke API cloud, membaca state saat ini, dan mengueri sumber data. Ini memungkinkannya menangkap hal yang tidak bisa dilakukan validate: nilai argumen yang ditolak API provider, kueri sumber data dengan hasil tak terduga, galat kuota atau batas laju, dan konflik antara konfigurasi yang diusulkan dengan infrastruktur yang sudah ada di state.

Menjalankan terraform validate itu sederhana, tetapi langkah di sekitarnya penting agar perintah ini memberi hasil maksimal.

# Validasi dasar
terraform validate

# Keluaran JSON untuk diproses di CI
terraform validate -json

# Contoh struktur keluaran JSON
{
  "valid": false,
  "error_count": 2,
  "diagnostics": [
    {
      "severity": "error",
      "summary": "Unsupported argument",
      "detail": "An argument named 'regoin' is not expected here. Did you mean 'region'?",
      "range": {
        "filename": "main.tf",
        "start": { "line": 8, "column": 3 }
      }
    }
  ]
}

terraform validate sangat cocok untuk pipeline CI karena tidak memerlukan kredensial cloud, berjalan dalam hitungan detik, dan menangkap sebagian besar kesalahan penulisan sebelum menghabiskan satu eksekusi plan atau sampai ke tinjauan kode. Pola standarnya adalah menjalankannya pada setiap pull request yang mengubah berkas .tf.

Contoh GitHub Actions

Workflow di bawah memasang Terraform, menjalankan init dengan -backend=false agar tidak butuh kredensial state, lalu menjalankan validate. Jika validate gagal, workflow berakhir dengan kode bukan nol dan memblokir pull request untuk di-merge.

name: Terraform Validate

on:
  pull_request:
    paths:
      - '**.tf'
      - '**.tfvars'

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: '1.8.0'

      - name: Terraform Init (no backend)
        run: terraform init -backend=false

      - name: Terraform Validate
        run: terraform validate -json | tee validate-output.json
        # Exit code 1 on any error - fails the workflow automatically

Menggabungkan validate dengan tflint

tflint adalah linter yang menangkap masalah yang dilewatkan terraform validate: pemeriksaan aturan khusus provider (seperti tipe instans AWS yang tidak valid), deklarasi tidak terpakai, dan aturan kebijakan sendiri. Menjalankan tflint setelah validate di job CI yang sama memberi cakupan analisis statis lebih luas. tflint punya plugin aturan khusus untuk AWS, Azure, dan GCP yang memeriksa nilai argumen terhadap opsi valid yang diketahui, menangkap galat yang tidak bisa dijangkau pemeriksaan skema generik validate.

• terraform fmt -check - memverifikasi kode mengikuti konvensi gaya Terraform (gagal jika ada berkas yang perlu diformat ulang)
• terraform validate - memeriksa sintaks, kesesuaian skema, dan referensi internal
• tflint - aturan khusus provider, deteksi variabel tidak terpakai, penerapan kebijakan sendiri
• Checkov atau tfsec - pemindaian kebijakan keamanan dan kepatuhan
• terraform plan - validasi runtime di lingkungan staging dengan kredensial nyata

terraform validate adalah fondasi, bukan langit-langit. Alur kerja Terraform yang matang menumpuk beberapa teknik validasi untuk menangkap kelas galat yang berbeda pada titik yang tepat dalam siklus pengembangan.

Format dulu, baru validasi

Jalankan terraform fmt sebelum validate di setiap alur, lokal maupun CI. Pemformatan HCL kanonis bukan hanya soal gaya: ia mencegah kasus tepi saat spasi atau penempatan komentar yang tidak konsisten menyembunyikan galat nyata pada keluaran parsing. Format HCL dari Aback Tools memberi normalisasi yang sama di browser tanpa perlu memasang Terraform, berguna untuk tinjauan cepat atau mengedit di mesin yang tidak bisa menjalankan terraform fmt.

Selalu init sebelum validate di CI

Menjalankan validate tanpa init hanya memberi analisis parsial: parsing HCL dan pemeriksaan referensi, tetapi tanpa validasi skema provider. Melewati pemeriksaan skema berarti Anda bisa merge konfigurasi yang memakai nama argumen dengan salah ketik atau meneruskan tipe salah ke atribut resource. Beberapa detik tambahan yang ditambahkan init -backend=false ke job CI sepadan dengan cakupannya.

Gunakan -json untuk keluaran CI terstruktur

Keluaran default validate yang mudah dibaca jelas untuk debugging lokal, tetapi keluaran JSON jauh lebih berguna di pipeline otomatis. Dengan -json, Anda bisa memproses array diagnostics untuk mengekstrak path berkas dan nomor baris, menganotasi diff pull request dengan komentar galat sebaris menggunakan API GitHub Checks, atau mengirim galat ke notifikasi Slack khusus. Periksa dulu boolean valid: jika true, array diagnostics masih bisa memuat peringatan yang layak ditampilkan.

Validasi setiap modul secara mandiri

terraform validate di modul root juga memeriksa modul lokal yang dipanggil, tetapi modul jarak jauh hanya diperiksa setelah init mengunduhnya. Untuk repositori modul, jalankan validate terpisah di setiap direktori modul selama pengembangan. Ini memunculkan galat skema pada modul itu sendiri sebelum konsumen mulai merujuknya.

Jaga berkas .tf tetap terformat sebelum commit

Gunakan hook pre-commit yang menjalankan terraform fmt -check dan gagal jika ada berkas .tf yang tidak dalam format kanonis. Ini menjaga seluruh basis kode konsisten, menghindari diff yang hanya soal gaya pada tinjauan kode, dan membuat keluaran validate lebih mudah dibaca karena kodenya berstruktur rapi. Hapus komentar pengembangan dari konfigurasi produksi dengan Penghapus komentar Terraform HCL agar berkas yang di-commit tetap bersih dan mudah dibaca.