Örnek sorular
Terraform Providers Lifecycle ProvisionersZorluk 1
Bir Terraform terraform {} bloğu içindeki required_providers bloğunun amacı nedir?
- aKonfigürasyonun kaynak dağıtabileceği bulut region'larını listeler — bu, burada gerçekte sorulanla ilgili ama ondan farklı bir kavramı tanımlar
- bKonfigürasyonun ihtiyaç duyduğu provider'ları, kaynak adresleri ve sürüm kısıtlamalarıyla birlikte bildirir✓
- cProvider'ın API kimlik bilgilerini doğrudan versiyon kontrolünde saklar — makul görünen ama Terraform'un burada gerçekte nasıl davrandığıyla eşleşmeyen bir iddia
- dTerraform'un konfigürasyondaki her kaynak için kullanması gereken isimlendirme kuralını tanımlar, mantıklı görünse de bu mekanizmanın pratikte gerçekte nasıl çalıştığı bu değildir
Açıklama:required_providers bloğu, Terraform'a bir konfigürasyonun hangi provider'lara (kaynak adresi, ör. hashicorp/aws) ve hangi sürüm kısıtlamalarına bağlı olduğunu söyler, böylece terraform init uyumlu provider eklentisini indirebilir. Region, kimlik bilgisi veya isimlendirme kuralıyla ilgisi yoktur.
Terraform Providers Lifecycle ProvisionersZorluk 1
Bir provider için version = "~> 5.10" gibi bir sürüm kısıtlamasında ~> operatörü genel olarak ne anlama gelir?
- aTerraform'u her zaman tam olarak 5.10 sürümünü kurmaya zorlar, istisnasız — bu, burada gerçekte sorulanla ilgili ama ondan farklı bir kavramı tanımlar
- bProvider sürümünün tamamen kısıtsız olduğu ve herhangi bir sürümün kurulabileceği anlamına gelir — teknik olarak yanlıştır, çünkü bu özelliğin gerçekte neden sorumlu olduğunu yanlış tanımlar
- cYalnızca en sağdaki sürüm bileşeninin artmasına izin verir, yani yeni 5.x sürümlerine izin verilir ama 6.0'a verilmez✓
- dProvider'ı hiç 5.10 ile eşleşmiş en eski sürüme indirger — bu, burada gerçekte sorulanla ilgili ama ondan farklı bir kavramı tanımlar
Açıklama:Pessimistic kısıtlama operatörü ~>, yalnızca belirtilen en sağdaki sürüm parçasının artmasına izin verir. ~> 5.10, 5.10, 5.11, 5.12 gibi sürümlere izin verir ama 6.0'a vermez — patch/minor güncellemeleri kabul edip yanlışlıkla major yükseltmeden kaçınmanın yaygın bir yoludur.
Terraform Providers Lifecycle ProvisionersZorluk 1
provider "aws" { region = "eu-west-1" } bloğu neyi yapılandırır?
- aBir kaynak alternatif bir provider belirtmediğinde AWS provider'ının kullanacağı varsayılan ayarları (region, kimlik bilgisi gibi)✓
- bTerraform'un anında oluşturduğu yeni bir AWS hesabı — makul görünen ama Terraform'un burada gerçekte nasıl davrandığıyla eşleşmeyen bir iddia
- cKonfigürasyondaki başka herhangi bir kaynaktan önce yok edilmesi gereken bir kaynak — bu, burada gerçekte sorulanla ilgili ama ondan farklı bir kavramı tanımlar
- dKonfigürasyondaki kaynakların kullanabileceği izinli AWS servislerinin listesi — bu, burada gerçekte sorulanla ilgili ama ondan farklı bir kavramı tanımlar
Açıklama:Bir provider bloğu, kaynakların ya örtük olarak (o tip için varsayılan provider bloğu) ya da provider meta-argümanı üzerinden açıkça referans verdiği bir provider instance'ını (region, kimlik bilgisi, endpoint override gibi ayarlarla) yapılandırır.
Terraform Providers Lifecycle ProvisionersZorluk 2
Bir Terraform konfigürasyonunda required_providers içinde bir provider için hiç sürüm kısıtlaması yoksa pratik risk nedir?
- aTerraform, bir kısıtlama eklenene kadar
terraform init çalıştırmayı reddeder — bu, burada gerçekte sorulanla ilgili ama ondan farklı bir kavramı tanımlar, gerçek davranış kontrol edildiğinde geçerliliğini yitiren yaygın bir yanlış anlamadır - bProvider güvenlik için kendini otomatik olarak 1.0.0 sürümüne sabitler — teknik olarak yanlıştır, çünkü bu özelliğin gerçekte neden sorumlu olduğunu yanlış tanımlar
- cTerraform, tüm bulut API çağrılarını yok sayan yerleşik bir provider'a geri döner — teknik olarak yanlıştır, çünkü bu özelliğin gerçekte neden sorumlu olduğunu yanlış tanımlar
- dDaha sonraki bir
terraform init -upgrade (veya lock dosyası commit'lenmemiş taze bir clone) daha yeni, potansiyel olarak kırıcı bir provider sürümünü çekebilir✓
Açıklama:Hiç sürüm kısıtlaması olmadan, Terraform herhangi bir kısıtlamayı sağlayan en yeni provider sürümünü seçmekte serbesttir, bu yüzden bir yükseltme veya .terraform.lock.hcl commit'lenmemiş taze bir ortam sessizce kırıcı değişiklikler içeren bir sürüme atlayabilir.
Terraform Providers Lifecycle ProvisionersZorluk 1
Bir provider bloğundaki alias meta-argümanı neyi mümkün kılar?
- aBir kaynağı yok edip yeniden oluşturmadan yeniden adlandırmayı — bu, burada gerçekte sorulanla ilgili ama ondan farklı bir kavramı tanımlar — bu, burada gerçekte sorulanla ilgili ama ondan farklı bir kavramı tanımlar
- bAynı provider'ın ek, varsayılan-olmayan bir konfigürasyonunu tanımlamayı, böylece tek bir konfigürasyon birden fazla region veya hesapla konuşabilir✓
- cO provider tarafından yazılan tüm state'i otomatik olarak şifrelemeyi — bu, burada gerçekte sorulanla ilgili ama ondan farklı bir kavramı tanımlar
- dO belirli provider için
terraform init adımını atlamayı, gerçek davranış kontrol edildiğinde geçerliliğini yitiren yaygın bir yanlış anlamadır
Açıklama:alias, aynı provider tipi için ikinci (veya üçüncü vb.) isimlendirilmiş bir konfigürasyon tanımlamanızı sağlar — örneğin farklı region'lara sahip iki aws provider bloğu — böylece kaynaklar provider = aws.<alias> üzerinden hangi konfigürasyonu kullanacağını seçebilir.
Terraform Providers Lifecycle ProvisionersZorluk 2
Bir ekip, tek bir AWS hesabıyla aynı Terraform konfigürasyonu içinde us-east-1'de bir S3 bucket'ı ve eu-west-1'de ayrı bir bucket oluşturmak istiyor. Bunu yapmanın standart yolu nedir?
- aTek bir konfigürasyon iki region'ı hedefleyemeyeceği için iki farklı git deposunda tamamen ayrı iki Terraform konfigürasyonu çalıştırmak — teknik olarak yanlıştır, çünkü bu özelliğin gerçekte neden sorumlu olduğunu yanlış tanımlar
- bTek bir
provider "aws" bloğu içinde region'ı art arda iki kez ayarlamak, mantıklı görünse de bu mekanizmanın pratikte gerçekte nasıl çalıştığı bu değildir — makul görünen ama Terraform'un burada gerçekte nasıl davrandığıyla eşleşmeyen bir iddia - cBir region için varsayılan bir
aws provider ve diğer region için alias'lı ikinci bir aws provider tanımlayıp, ikinci bucket'ın provider argümanında alias'lı olanı referans vermek✓ - dBucket kaynağında
depends_on kullanarak apply sırasında region'ını değiştirmek — bu, burada gerçekte sorulanla ilgili ama ondan farklı bir kavramı tanımlar — makul görünen ama Terraform'un burada gerçekte nasıl davrandığıyla eşleşmeyen bir iddia
Açıklama:Tek bir konfigürasyon içinde çoklu-region (veya çoklu-hesap) kurulumları, provider alias'larının klasik kullanım durumudur: bir varsayılan provider bloğu artı bir veya daha fazla alias'lı provider bloğu, her kaynak provider meta-argümanı üzerinden hangi provider'ı kullanacağını seçer.