Terraform ile çoklu ortam yönetimi: workspace mi, tfvars mı, ayrı dizin mi?

Aynı altyapıyı farklı ortamlarda çalıştırmak

Çoğu ekip aynı altyapıyı geliştirme, test ve üretim ortamlarında çalıştırmak ister. Ortamlar genelde aynı bileşenlerden oluşur, ama boyut, sayı ve erişim kuralları farklıdır: üretimde daha büyük makine ve daha sıkı yetki, geliştirmede küçük ve ucuz kaynaklar. Terraform bu ihtiyacı yaygın yöntemlerle karşılar: workspace'ler, ortam başına değişken dosyaları (tfvars) ve ortam başına ayrı dizin ya da state.

Bu yöntemlerin hiçbiri her durumda doğru değildir. Seçim; ortamlar arasındaki fark ne kadar büyük, ortamlar için ayrı kimlik bilgisi gerekiyor mu, ekip kaç kişi ve hataya ne kadar tolerans var sorularına bağlıdır. Aşağıdaki bölümler her yöntemin işleyişini ve sınırını gösterir.

Workspace ile ayrım

Workspace, aynı yapılandırma için birden fazla ayrı state dosyası tutmanıza izin verir. Terraform varsayılan olarak default adlı bir workspace ile başlar ve bu silinemez. Her yeni workspace kendi state'ini taşır; bu nedenle bir workspace'te plan çalıştırmak diğer workspace'lerdeki kaynaklara dokunmaz. Bu kaynaklar yerinde durur, yönetmek için workspace değiştirmeniz gerekir.

Yapılandırmada o anki workspace adına terraform.workspace ifadesiyle ulaşılır. Bu değeri adlandırmada ya da etiketlemede, ayrıca ortama göre farklı boyut seçmek için kullanabilirsiniz. Örneğin üretim dışındaki workspace'lerde daha küçük makine boyutu seçen bir koşul yazılabilir.

Workspace her backend'de desteklenmez; HashiCorp belgeleri bulut depolama tabanlı backend'ler dahil, Consul, Postgres ve Remote gibi seçenekleri destekler olarak sayar. Uzak backend'de çalışan ekip, workspace'leri aynı bucket içinde ayrı anahtar altında saklar.

Workspace'in sınırı: ne zaman uygun değildir?

HashiCorp belgelerindeki net uyarı şudur: workspace'ler sistem ayrıştırması için ya da ayrı kimlik bilgisi ve erişim denetimi gerektiren dağıtımlar için uygun değildir. Bunun pratik anlamı şudur: geliştirme ve üretim ortamları farklı bulut hesaplarında çalışıyor, farklı kişiler tarafından yönetiliyorsa ve üretim state'ine erişim kısıtlanmalıysa, aynı backend içinde workspace ayrımı bu ihtiyacı karşılamaz. Çünkü workspace'ler aynı yapılandırmayı ve çoğunlukla aynı kimlik bilgisini paylaşır.

Workspace'ler küçük farklarla birbirine çok benzeyen kısa ömürlü ortamlar için uygundur: bir özellik dalı için geçici test ortamı, aynı mimarinin kopyaları gibi. Üretim ve geliştirme arasında hesap ya da yetki sınırı gerekiyorsa ayrı dizin ve ayrı backend daha güvenli bir seçimdir.

tfvars dosyalarıyla ortam parametreleri

Ortamlar arasındaki fark yalnızca değerlerdeyse (boyut, sayı, ad), her ortam için ayrı bir değişken dosyası tutulabilir: dev.tfvars, test.tfvars, prod.tfvars. Komut satırında -var-file seçeneğiyle istenen dosya verilir:

terraform plan -var-file=dev.tfvars

HashiCorp belgelerine göre değişken değerleri belirli bir öncelik sırasıyla çözülür. En yüksek öncelik komut satırındaki -var ve -var-file seçeneklerindedir. Sonra sırasıyla *.auto.tfvars dosyaları, terraform.tfvars.json, terraform.tfvars, TF_VAR_ ile başlayan ortam değişkenleri ve en sonda variable bloğundaki default gelir. Bu sıra, ortak değerleri varsayılanda, ortama özgü değerleri tfvars dosyasında, geçici değişiklikleri komut satırında tutmanızı sağlar.

Bu yöntemin zayıflığı state ayrımının tek başına çözülmemesidir. -var-file değiştirmek, aynı backend ve aynı state üzerinde çalışıyorsanız ortamları birbirine karıştırabilir. Bu yüzden tfvars genellikle ayrı state ile birlikte kullanılır.

Ortam başına dizin ve ayrı backend

En katı ve en güvenli ayrım, her ortam için ayrı bir kök dizin ve ayrı backend (ayrı state) kullanmaktır. Ortak kod bir modüle çıkarılır; her ortamın dizini bu modülü kendi değerleriyle çağırır. Örnek yapı:

• modul/ağ: ortak kod
• ortamlar/dev: modülü küçük boyutlarla çağırır, kendi backend'ini kullanır
• ortamlar/prod: aynı modülü üretim değerleriyle çağırır, ayrı hesap ve ayrı state kullanır

Bu düzende üretim state'ine erişim ayrı yönetilir, bir ortamdaki bozulma diğerine yansımaz ve her ortam için ayrı CI görevi çalıştırılabilir. Bedeli biraz daha çok dosya ve tekrar eden backend yapılandırmasıdır. Modüller bu tekrarı azaltır; ortak mantığı bir yerde tutup ortamlara parametre geçirmek kodun tutarlı kalmasını sağlar.

Hangi yöntemi seçmeli? Karar ölçütleri

Ölçüt: ortamlar arasındaki yetki sınırı. Üretim ayrı hesapta ve kısıtlı erişimliyse ayrı dizin ve backend seçin. Aynı hesapta, aynı ekibin yönettiği kısa ömürlü ortamlar için workspace yeterli olabilir.

Ölçüt: ortamlar arası fark. Yalnız değer farkı varsa tfvars ve parametrik modül yeterlidir; mimari farklar da varsa ayrı dizin daha doğal olur.

Ölçüt: hata riski. Workspace ile çalışırken yanlış workspace'te apply çalıştırmak klasik bir kazadır; komut istemine mevcut workspace adını yazdırmak ya da CI'da workspace'i otomatik seçmek bu riski azaltır.

Ölçüt: ekip büyüklüğü. Küçük ekipte workspace ve tfvars yeterli basitliği sunar. Büyüdükçe ayrı dizin ve ayrı pipeline gereksinimi ortaya çıkar.

Örneğin yeni başlayan bir ekip geliştirme ve test için workspace, üretim için ayrı dizin ve backend kullanabilir; bu karma yaklaşım pratikte sık görülür.

Sık yapılan hatalar ve Mindset programlarında yeri

• Yanlış workspace'te apply çalıştırmak: Komuttan önce terraform workspace show ile kontrol edin ya da pipeline'da otomatik seçim kullanın.
• Ortamları aynı state'te karıştırmak: tfvars değiştirmek tek başına state'i ayırmaz.
• Üretim sırlarını tfvars dosyasına yazıp depoya yüklemek: Hassas değerleri sır deposundan okuyun.
• Ortamlar arası sürüklenmeyi izlememek: Ortamların kodu zamanla ayrışır; kodu modülle paylaşıp farkı yalnız değişkenlerde tutun.
• Workspace'i kimlik ayrımı için kullanmak: Belgeler bunun uygun olmadığını açıkça söyler.

Mindset'in Terraform ile Altyapı Otomasyonu programı durum yönetimi ve backend, modüler Terraform mimarisi, CI/CD ile Terraform iş akışları ve çok bulutlu strateji gibi modülleri kapsar. Platform ve DevOps ekipleri, ortam stratejisini birlikte belirleyerek ortak bir standart oluşturabilir.