Örnek sorular
Terraform State Backend LockingZorluk 1
Terraform state dosyasının birincil amacı nedir?
- aCloud kaynakları üzerinde yapılan her manuel değişikliği açıklayan, insan tarafından yazılan bir changelog saklar
- bProvider plugin binary'lerinin tekrar indirilmemesi için önbelleğe alınmış bir kopyasını saklar
- cKonfigürasyonda tanımlanan kaynakları, Terraform'un oluşturduğu gerçek dünya nesneleriyle ve bunların attribute'larıyla eşler✓
- dTerraform CLI'ın kendi sürüm geçmişini ve güncelleme bildirimlerini saklar
Açıklama:State dosyası, Terraform'un hangi gerçek altyapı nesnelerinin konfigürasyondaki hangi resource bloklarına karşılık geldiğine ve izlenen attribute'larına dair kaydıdır. Terraform, plan/apply sırasında diff'i bu eşleme üzerinden hesaplar. (a) yanlış çünkü state dosyası makine tarafından üretilen bir JSON kaydıdır, elle tutulan bir changelog değildir.
Terraform State Backend LockingZorluk 1
terraform.tfstate JSON dosyasını doğrudan elle düzenlemek neden genel olarak güvensiz kabul edilir?
- aTerraform CLI dosyayı fiziksel olarak salt-okunur izinlerle kilitler, bu yüzden elle düzenleme teknik olarak imkânsızdır
- bElle yapılan bir düzenleme, gerçek altyapıyla artık eşleşmeyen içsel olarak tutarsız bir state üretebilir ve beklenmedik plan'lara yol açar✓
- c.tfstate dosya formatı derlenmiş binary'dir, JSON değildir, bu yüzden bir metin editörü onu hiç açamaz
- dDosyayı elle düzenlemek, içinde listelenen her kaynağın otomatik olarak destroy edilmesini tetikler
Açıklama:State dosyasının, Terraform'un tutarlı olmasına güvendiği içsel bir yapısı vardır (resource adresleri, bağımlılık metadata'sı, attribute değerleri); elle yapılan bir düzenleme bu tutarlılığı sessizce bozabilir ve teşhis edilmesi zor yanlış plan'lara veya drift'e yol açabilir. Terraform bunun yerine güvenli değişiklikler için özel komutlar sunar (state mv/rm/import). (a) yanlış — dosyayı bir metin editöründe açmayı engelleyen hiçbir şey yoktur; risk mantıksaldır, teknik bir kilit değildir.
Terraform State Backend LockingZorluk 1
Remote backend kullanmak (ör. S3, azurerm, GCS), Terraform'un varsayılan local state'ine kıyasla hangi temel sorunu çözer?
- aBir ekibin, her mühendisin senkron dışı kalabilen kendi yerel kopyası yerine tek, merkezi olarak saklanan bir state dosyasını paylaşmasını sağlar✓
- bTerraform'un herhangi bir resource attribute'unu izleme ihtiyacını tamamen ortadan kaldırır
- cBulutta ne varsa .tf konfigürasyon dosyalarını otomatik olarak buna göre yeniden yazar
- dBackend değişiklikleri kendi zamanlamasına göre uyguladığı için 'terraform plan'ı gereksiz kılar
Açıklama:Terraform varsayılan olarak state'i yerel bir terraform.tfstate dosyasına yazar. Bir remote backend, aynı state'i merkezi olarak saklar, böylece her ekip üyesi ve CI job'u aynı doğruluk kaynağını okur/yazar, farklılaşan yerel kopyaları önler. (b) yanlış — backend hâlâ aynı resource-attribute eşlemesini saklar, sadece bu verinin nerede yaşadığını değiştirir.
Terraform State Backend LockingZorluk 1
S3 backend'li bir Terraform kurulumunda, S3 bucket'ının yanındaki bir DynamoDB tablosunun tarihsel rolü nedir?
- aState dosyasının tam bir yedek kopyasını saklar, herhangi bir locking mekanizmasıyla ilgisi yoktur
- b'terraform init' tekrar indirmesin diye provider plugin binary'lerini saklar
- cTerraform CLI'ın AWS provider için kimlik doğrulama bilgilerini saklar
- dBir işlem çalışırken bir lock kaydı tutarak state locking sağlar, eşzamanlı apply'ları önler✓
Açıklama:S3'ün kendisi, eşzamanlı yazıcıları koordine eden yerleşik bir mekanizması olmayan bir object store'dur, bu yüzden geleneksel olarak plan/apply sırasında bir lock item tutması için bir DynamoDB tablosu eşlenmiştir, aynı anda yalnızca bir işlemin state'i değiştirmesini sağlar. (a) yanlış — tablo state dosyasının tamamının bir kopyasını değil, küçük bir lock kaydını tutar.
Terraform State Backend LockingZorluk 2
State locking hangi sorunu önler?
- aKonfigürasyon değişikliklerinden bağımsız olarak bir kaynağın asla destroy edilmesini önler
- bİki eşzamanlı Terraform işleminin aynı state dosyasını aynı anda okuyup yazmasını önler✓
- cProvider'ın bulut platformuna herhangi bir API çağrısı yapmasını önler
- dMühendislerin state dosyasının içeriğini görüntülemesini tamamen önler
Açıklama:State locking erişimi sıralar: bir işlem (plan/apply) lock'u tutarken, aynı state'i hedefleyen başka bir eşzamanlı işlem başlamaktan engellenir, bu da iki sürecin aynı state dosyasına çakışan güncellemeler yazmasını önler. (a) yanlış — locking, state dosyasına erişimi koordine etmekle ilgilidir, kaynaklardaki destroy işlemlerini engellemekle değil.
Terraform State Backend LockingZorluk 2
Bir mühendis, bir meslektaşının aynı remote state'e karşı apply'ı zaten devam ederken ve lock'u tutuyorken 'terraform apply' çalıştırıyor. Beklenen varsayılan davranış nedir?
- aİki apply aynı anda devam eder ve Terraform ortaya çıkan iki state'i otomatik olarak birleştirir
- bİkinci apply, hiçbir uyarı vermeden birinci mühendisin devam eden değişikliklerinin üzerine sessizce yazar
- cİkinci apply başarısız olur veya bekler, state'in başka bir işlem tarafından kilitlendiğini bildirir✓
- dTerraform mevcut lock'u otomatik olarak siler, böylece her zaman en son komut kazanır
Açıklama:Terraform'un aktif bir lock'la karşılaştığında varsayılan davranışı, lock'u (kimin tuttuğunu, ne zaman oluşturulduğunu) bildirmek ve devam etmek yerine ya beklemek ya da hata vermektir — bu tam olarak locking'in sağlaması gereken koordinasyondur. (a) yanlış — Terraform'un eşzamanlı çalıştırmalar için bir state birleştirme yeteneği yoktur; bu tam olarak locking'in önlediği bozulma senaryosudur.