Örnek sorular
Terraform Testing Policy CicdZorluk 1
terraform fmt ne yapar?
- aYapılandırmayı biçimlendirdikten sonra hedef altyapıya uygular
- bYapılandırma dosyalarını mantığını değiştirmeden standart bir stile yeniden yazar.✓
- cResource argümanlarının gerçek provider attribute'larına referans verdiğini doğrular
- dProvider sürümlerini indirip bir lock dosyasına kilitler
Açıklama:terraform fmt yalnızca bir stil aracıdır: .tf dosyalarını standart HCL biçimine (girinti, hizalama, boşluk) yeniden yazar, gerçek mantığa dokunmaz veya doğruluğu kontrol etmez. Apply, validate ve provider kilitleme ayrı komutlardır (apply, validate, init).
Terraform Testing Policy CicdZorluk 1
terraform validate öncelikle neyi kontrol eder?
- aHedef cloud hesabının planlanan resource'ları oluşturacak yeterli kotaya sahip olup olmadığını
- bTanımlanan resource'ların zaten var olup olmadığını ve gerçek altyapıyla eşleşip eşleşmediğini
- cYapılandırmanın iç sözdizimi ve tutarlılığı.✓
- dCI pipeline'ının
terraform apply çalıştırma iznine sahip olup olmadığını
Açıklama:terraform validate, bir sözdizimi ve iç-tutarlılık kontrolü yapar: yapılandırmanın geçerli bir HCL yapısı olduğunu, zorunlu argümanların mevcut olduğunu ve referans verilen değerlerin yapılandırma içinde çözüldüğünü doğrular. Gerçek altyapıyla karşılaştırmak için cloud provider ile konuşmaz — bu terraform plan'ın işidir.
Terraform Testing Policy CicdZorluk 2
Bir pipeline, cloud credential'ları hiç yapılandırmadan terraform validate çalıştırıyor ve yine de başarılı oluyor. Bu neden mümkün?
- aValidate yalnızca yapılandırmanın iç yapısını kontrol eder, provider API'sine authenticate olması gerekmez.✓
- bValidate, authenticate olamadığı tüm resource'ları sessizce atlar, bazı takımların dayandığı bir bug'dır bu
- cValidate credential olmadan her zaman başarısız olur, bu senaryo imkânsızdır
- dValidate otomatik olarak son başarılı plan'ın önbelleğe alınmış bir kopyasına döner
Açıklama:Çünkü terraform validate tamamen yerel/statik bir kontroldür (tipler, zorunlu argümanlar, iç referanslar), provider API'sine ulaşmasına gerek yoktur. terraform plan ve terraform apply ise gerçek credential'lara ihtiyaç duyar çünkü yapılandırmayı gerçek uzak state ile karşılaştırırlar.
Terraform Testing Policy CicdZorluk 2
tflint, CI pipeline'ında sıklıkla terraform validate ile birlikte çalıştırılır. tflint, validate'in zaten kontrol ettiğine ek olarak ne katar?
- aAnlamlı bir şey katmaz — tflint ve validate tam olarak aynı şeyleri kontrol eder, ikisini de çalıştırmak gereksizdir
- btflint, gerçek altyapı değişikliklerini simüle edebildiği için
terraform plan ihtiyacını tamamen ortadan kaldırır - ctflint, production'dan önce runtime hatalarını yakalamak için yapılandırmayı bir sandbox hesabına uygular
- dtflint, genel HCL sözdizimi geçerliliğinin ötesine geçen provider'a özgü en-iyi-uygulama ve doğruluk kontrolleri ekler.✓
Açıklama:terraform validate yalnızca yapılandırmanın yapısal olarak geçerli HCL olduğunu doğrular. tflint ise çekirdek kuralları ve provider'a özgü plugin'leri (ör. AWS için) aracılığıyla, sözdizimsel olarak sorunsuz ama anlamsal olarak yanlış olan deprecated syntax, kullanılmayan tanımlar veya geçersiz provider'a özgü değerler gibi sorunları ek olarak işaretler.
Terraform Testing Policy CicdZorluk 1
Bir Terraform pipeline'ında 'policy as code' fikrinin genel mantığı nedir?
- aAltyapı politikaları hakkında iç dokümantasyonu pipeline'dan ayrı bir wiki'de yazmak
- bKurumsal kuralları, pipeline'ın bir plan'a karşı otomatik değerlendirdiği makine tarafından kontrol edilebilir kurallar olarak ifade etmek.✓
- cHer apply'dan önce her plan çıktısını otomasyon olmadan satır satır manuel olarak incelemek
- d
terraform validate'in yerini tamamen almak, çünkü policy araçları da HCL sözdizimini kontrol eder
Açıklama:Policy as code, kurumsal veya uyumluluk kurallarının (ör. Sentinel veya OPA ile) çalıştırılabilir kurallar olarak yazılması ve bir pipeline'ın bunları bir plan'a karşı otomatik olarak çalıştırması demektir, böylece ihlaller (ör. herkese açık bir resource) bir insanın kontrol etmeyi hatırlamasına bağlı kalmadan tutarlı ve otomatik biçimde yakalanır.
Terraform Testing Policy CicdZorluk 2
Merge etmeden önce bir pull-request kontrolünün parçası olarak terraform plan çalıştırıp çıktısını bir PR yorumu olarak paylaşmak neden yaygın bir uygulamadır?
- aÇünkü
terraform plan gerçek altyapıyı değiştirir, bu yüzden zaman kazanmak için merge'den önce yapılmalıdır - bÇünkü plan'ı paylaşmak Terraform'un kendisi tarafından zorunlu kılınır; CLI aksi halde apply'ı reddeder
- cBöylece reviewer'lar, bir PR'ın altyapı etkisini merge'i onaylamadan önce görebilir.✓
- dÇünkü
terraform plan, HCL sözdizimi hatalarını yakalayabilen tek komuttur
Açıklama:Plan çıktısını PR'da paylaşmak, reviewer'lara bir değişikliğin somut altyapı etkisini (ne oluşturulacak, değiştirilecek veya yok edilecek) normal kod review akışının bir parçası olarak görünürlük sağlar, istenmeyen değişiklikleri merge edilip sonradan apply edilmeden önce yakalar.