Saat Satu Konfigurasi Infrastruktur Harus Melayani Banyak Environment

Anda memiliki konfigurasi Terraform yang mendefinisikan VPC, subnet, dan load balancer. Konfigurasi tersebut bekerja sempurna untuk environment development Anda. Sekarang Anda membutuhkan pengaturan yang sama untuk staging dan production. Pendekatan naifnya adalah menyalin seluruh folder tiga kali dan mengubah beberapa nilai variabel. Itu berhasil sampai Anda perlu memperbarui aturan security group, dan Anda sadar harus melakukan perubahan yang sama di tiga tempat, berharap tidak ada yang terlewat.

Masalahnya bukan tentang menulis kode infrastruktur. Masalahnya adalah mengelola kode yang sama di berbagai environment tanpa menduplikasi semuanya atau tanpa sengaja merusak production saat mengerjakan development.

Dua pendekatan umum mengatasi hal ini: workspaces dan root modules terpisah. Keduanya menangani masalah yang sama dengan cara yang fundamental berbeda, dan memilih di antara keduanya tergantung pada bagaimana tim Anda beroperasi dan seberapa besar pemisahan yang dibutuhkan environment Anda.

Workspaces: Satu Codebase, Banyak State

Workspaces adalah fitur bawaan alat seperti Terraform yang memungkinkan Anda menggunakan kode sumber yang sama dengan file state yang berbeda. Anggap saja seperti memiliki satu folder konfigurasi yang dapat menghasilkan tiga environment berbeda. Kodenya identik. Yang berubah adalah file state yang melacak apa yang telah di-deploy.

Alur kerjanya sederhana. Anda membuat workspace untuk setiap environment, lalu beralih ke workspace yang benar sebelum menjalankan perubahan apa pun. Alat secara otomatis mengarahkan pembacaan dan penulisan state ke lokasi backend yang benar berdasarkan workspace mana yang aktif. Jika Anda berada di workspace development, perubahan Anda hanya memengaruhi state development. State production tetap tidak tersentuh.

Diagram di bawah mengilustrasikan perbedaan struktural antara kedua pendekatan.

Berikut adalah tampilan alur kerja tersebut dalam praktik:

# Membuat workspace untuk setiap environment
terraform workspace new dev
terraform workspace new staging
terraform workspace new prod

# Beralih ke workspace development
export TF_WORKSPACE=dev
# Atau gunakan: terraform workspace select dev

# Plan dan apply perubahan untuk workspace yang aktif
export TF_VAR_instance_type=t3.micro
terraform plan -out=dev.tfplan
terraform apply dev.tfplan

# Beralih ke production saat siap
export TF_WORKSPACE=prod
export TF_VAR_instance_type=t3.large
terraform plan -out=prod.tfplan
terraform apply prod.tfplan

Ini bekerja dengan baik ketika environment Anda serupa dan perbedaannya hanya terbatas pada nilai variabel. Mungkin development menggunakan ukuran instance yang lebih kecil, staging menggunakan instance medium, dan production menggunakan yang terbesar. Strukturnya sama. Hanya angkanya yang berubah.

Tetapi workspaces memiliki biaya tersembunyi. Karena semua environment berada dalam codebase yang sama, risiko beroperasi di workspace yang salah itu nyata. Seorang pengembang yang bekerja di workspace development dapat secara tidak sengaja menjalankan plan atau apply terhadap production jika mereka lupa beralih. Alat tidak mencegah hal ini. Alat hanya melacak workspace mana yang aktif. Perhatian manusia menjadi penghalang keamanan.

Ada batasan lain. Ketika Anda mengubah struktur konfigurasi, setiap environment mendapatkan perubahan pada waktu yang sama. Anda tidak dapat meng-upgrade staging terlebih dahulu, memverifikasinya berfungsi, lalu menggulirkan perubahan yang sama ke production sehari kemudian. Semua environment bergerak bersama karena mereka berbagi kode yang sama. Jika perubahan merusak sesuatu, kerusakan terjadi di mana-mana secara bersamaan.

Root Modules: Folder Terpisah, Logika Bersama

Alternatifnya adalah memberikan setiap environment root module-nya sendiri. Alih-alih satu folder dengan tiga workspace, Anda memiliki tiga folder: dev, staging, dan prod. Setiap folder berisi file konfigurasi utama dan konfigurasi backend state-nya sendiri. Mereka sepenuhnya independen.

Tetapi Anda tidak menulis ulang logika infrastruktur tiga kali. Setiap root module memanggil shared module yang sama dari direktori modules. Definisi VPC, logika subnet, konfigurasi load balancer semuanya berada di modul yang dapat digunakan kembali. Root module hanya memanggil modul-modul tersebut dengan variabel khusus environment.

Keuntungannya jelas. Anda tidak dapat secara tidak sengaja memodifikasi production saat bekerja di development karena Anda harus secara eksplisit mengganti direktori. Pemisahannya bersifat fisik, bukan hanya logis. Anda juga dapat memperbarui environment secara independen. Production dapat tetap berada di versi modul yang stabil sementara development menggunakan versi terbaru dengan perubahan eksperimental. Staging dapat diperbarui terlebih dahulu, diuji, dan baru kemudian dipromosikan ke production.

Kekurangannya adalah duplikasi, tetapi itu adalah duplikasi struktural, bukan duplikasi logis. Anda mengulangi pemanggilan modul dan definisi variabel untuk setiap environment. Anda tidak mengulangi logika infrastruktur yang sebenarnya. Modul berisi logika, dan modul-modul itu dibagikan. Duplikasinya ada pada wiring, bukan pada implementasi.

Kapan Menggunakan yang Mana

Workspaces cocok untuk tim kecil dengan sedikit environment dan perbedaan minimal di antaranya. Jika Anda memiliki dua environment yang hampir identik, workspaces mengurangi overhead. Anda menulis kode sekali, dan workspace menangani pemisahan state.

Root modules bekerja lebih baik untuk tim yang lebih besar, environment yang membutuhkan pemisahan ketat, atau situasi di mana setiap environment memerlukan alur kerja persetujuan yang berbeda. Jika perubahan production memerlukan review pull request, persetujuan manajer, dan window perubahan, sementara perubahan development dapat diterapkan langsung, root modules membuat pemisahan itu menjadi alami. Setiap folder environment dapat memiliki pipeline CI/CD sendiri dengan gate yang berbeda.

Banyak tim memulai dengan workspaces karena lebih sederhana untuk diatur. Seiring pertumbuhan tim dan bertambahnya jumlah environment, mereka bermigrasi ke root modules. Migrasinya tidak menyakitkan karena modul sudah dipisahkan. Anda cukup membuat folder root baru yang memanggil modul yang sama.

Daftar Periksa Praktis

Sebelum memilih pendekatan Anda, jawablah pertanyaan-pertanyaan ini:

• Berapa banyak environment yang Anda kelola? Lebih dari tiga cenderung ke root modules.
• Apakah environment memerlukan proses persetujuan yang berbeda? Jika ya, gunakan root modules.
• Bisakah kesalahan di satu environment memengaruhi environment lain? Jika ya, root modules mengurangi risiko itu.
• Apakah ukuran tim Anda lebih dari lima orang? Tim yang lebih besar diuntungkan oleh pemisahan folder yang eksplisit.
• Apakah Anda perlu meng-upgrade environment pada waktu yang berbeda? Root modules memungkinkan peluncuran bertahap.

Jika Anda menjawab ya untuk tiga atau lebih dari pertanyaan ini, mulailah dengan root modules. Jika Anda menjawab tidak untuk sebagian besar, workspaces akan melayani Anda dengan baik untuk saat ini.

Intisari Konkret

Workspaces dan root modules memecahkan masalah yang sama dengan trade-off yang berbeda. Workspaces mengurangi duplikasi kode tetapi meningkatkan risiko operasional. Root modules menambah duplikasi struktural tetapi memberi Anda batasan yang jelas antar environment. Pilih berdasarkan cara tim Anda bekerja dan seberapa besar isolasi yang dibutuhkan environment Anda. Mulailah dengan yang sederhana, tetapi ketahui kapan harus beralih. Tujuannya bukan memilih pendekatan yang sempurna pada hari pertama. Tujuannya adalah mengenali kapan pendekatan Anda saat ini mulai menimbulkan lebih banyak masalah daripada yang dipecahkan.