Google PCD: Sürekli Teslimat, Yapılandırma ve Altyapı Otomasyonu — Çalışma kılavuzu

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Şunun bir parçası: Google Professional Cloud Developer — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Google sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Genel Bakış

Google Cloud’da sürekli teslimat, değişiklikleri güvenli bir şekilde tekrar tekrar teslim etmek için derleme otomasyonu, yapıt yönetimi, dağıtım orkestrasyonu, kod olarak altyapı ve güçlü yönetişimi entegre eder. Sağlam işlem hatları, değişmez yapıtları ve bildirimsel yapılandırmayı politika ve denetlenebilirlik ile birleştirir. Bu bölüm, Cloud Build, Cloud Deploy, Artifact Registry, Terraform, Kubernetes, özellik bayrakları ve yönetişim kontrollerini uçtan uca uygularken karşılaşılan tasarım seçimlerini, operasyonel uygulamaları ve yaygın hata modlarını açıklar.

Derleme ve Dağıtım Orkestrasyonu

Cloud Build

Tetikleyiciler (Triggers): Derlemeleri kaynak olaylarına (branch push’ları, etiketler, PR’lar) veya zamanlamalara bağlayın. Yalnızca hedeflenen referansların tetiklendiğinden emin olmak için branch veya etiket regex’ini tercih edin. Tetikleyiciler, en az ayrıcalık ilkesini uygulamak için belirli bir hizmet hesabı olarak çalışabilir; derlemelerin geniş API erişimine ihtiyacı varsa varsayılana güvenmeyin.
Derleme adımları (Build steps): Her adım bir container içinde çalışır. Varsayılan araç zinciri yetersiz olduğunda amaca yönelik derleyicileri (docker, gcloud) veya özel derleyicileri kullanın. Hataların kaynağının belirlenebilmesi ve etkili bir şekilde önbelleğe alınabilmesi için derleme, birim testi, entegrasyon testi, lint, güvenlik taramaları ve yapıt paketleme adımlarını ayırın.
Değişkenler (Substitutions): Parametreli derlemeler için yerleşik değişkenleri (PROJECT_ID, SHORT_SHA) ve özel değişkenleri (başına $_ koyarak) kullanın. Ortama özgü değerleri derleme mantığının dışında tutun; bunları değişken olarak geçirin veya daha sonra dağıtım sırasında çözümleyin.
Hizmet hesapları (Service accounts): Cloud Build hizmet hesabı (PROJECT_NUMBER@cloudbuild.gserviceaccount.com) açık roller gerektirir (örneğin, Artifact Registry yazma, Cloud Deploy yayın yöneticisi). Proje başına minimum rolleri ve kapsamı atayın. Özel kaynaklar için VPC bağlantılı Özel Havuzları (Private Pools) kullanın.
Yapıtlar (Artifacts): Değişmez imajları Artifact Registry’de yayınlayın ve isteğe bağlı olarak container olmayan yapıtları artifacts bölümü aracılığıyla Cloud Storage’a yükleyin. İmajları hem anlamsal bir sürümle hem de commit özetiyle (digest) etiketleyin; etiket kaymasını (tag drift) önlemek için dağıtımlarda imaj özetlerini kullanın.

Örnek Cloud Build yapılandırması:

cloudbuild.yaml:

undefined

Tetikleyici örneği:

undefined

Cloud Deploy

Teslimat işlem hatları (Delivery pipelines), sıralı aşamaları (stages) ve hedefleri (targets) tanımlar. Hedefler, GKE kümelerine, Cloud Run hizmetlerine veya diğer desteklenen çalışma zamanlarına referans verir. Yükseltmeyi (promotion) denetlemek için üretim aşamalarını requireApproval ile işaretleyin.
Dağıtımlar (Rollouts) bir sürümü (release) bir hedefe eşler; yükseltme (promotion) ise bir sürümü hedefler arasında ilerletir. Dağıtım öncesi/sonrası kontroller için aşamalı teslimatı (canary, blue/green) ve kancaları (hooks) kullanın.
Hata modları: Değişebilir etiketler kullanmak istenmeyen yükseltmelere neden olur; her zaman özetleri (digest) sabitleyin. Dağıtıcı hesabının IAM izinlerinin eksik olması dağıtımları engeller. Oluşturulamayan manifestolar veya ortama özgü yapılandırma kaymaları yükseltme hatalarına yol açar; manifestoları derleme sırasında doğrulayın.

Örnek Cloud Deploy tanımları:

delivery-pipeline.yaml:

undefined

targets.yaml:

undefined

Sürüm (Release) ve yükseltme (promotion):

undefined

Yapıtlar ve Tedarik Zinciri Bütünlüğü

Artifact Registry

Depolar (Repositories): IAM ve temizliği kapsamlandırmak için ekip veya ortam başına ayrı depolar oluşturun. Giden trafik (egress) ve gecikmeyi azaltmak için derleyicilere ve çalışma zamanlarına yakın bölgesel depolar kullanın. Paket formatları arasında Docker imajları ve dil paketleri (Maven, npm, PyPI) bulunur.
Saklama (Retention): Geri alma (rollback) için bir güvenlik penceresi bırakarak, referans verilmeyen veya eski etiketleri kaldırmak için temizleme politikaları tanımlayın. Bilinen son iyi sürümü kaldıran agresif saklama politikalarından kaçının.
Kaynak kanıtı (Provenance) ve SBOM: İmajların SLSA uyumlu onaylar (attestations) taşıması için derleme kaynak kanıtını etkinleştirin. Derleme sırasında SBOM’lar oluşturun ve bunları onay olarak saklayarak güvenlik açığı triyajını iyileştirin.
Güvenlik açığı taraması: Container analizini etkinleştirin ve mevcut düzeltmeler veya politika istisnaları olmadan yüksek önem dereceli CVE’ler tespit edildiğinde derlemeyi durdurun veya yükseltmeyi engelleyin.
Artıları ve eksileri: Tüm yapıtları tek bir projede merkezileştirmek yönetişimi basitleştirir ancak bir patlama yarıçapı (blast radius) oluşturabilir; ortama veya uygulamaya özel depolar riski azaltır ancak yönetim yükünü artırır.

Tedarik zinciri zorlaması

GKE üzerindeki Binary Authorization, onaylar (örneğin, “X projesindeki Cloud Build tarafından derlendi”, “kritik CVE yok”) gerektirebilir. Uyumlu olmayan sürümleri durdurmak için Cloud Deploy denetim kapılarıyla (gates) entegre edin.
Hata modları: Değişebilir etiketlere, devre dışı bırakılmış taramaya veya kimliği doğrulanmamış çekme (pull) işlemlerine güvenmek, doğrulanmamış yazılımların üretime ulaşmasına neden olabilir. Özetleri (digest) sabitleyin ve onaylar (attestations) gerektirin.

Kod Olarak Altyapı ve GitOps

Terraform

Yapılandırma ve modüller: Açık girdileri/çıktıları ve anlamsal sürümleri (semantic versions) olan yeniden kullanılabilir modüller oluşturun. Modülleri paylaşılan bir repo’da veya registry’de yayınlayın; sürpriz değişikliklerden kaçınmak için sürümleri sabitleyin (pin).
Durum (State): Uzak durum (remote state) için bucket seviyesinde IAM, nesne sürümleme (object versioning) ve CMEK ile GCS backend’ini kullanın. Durum dosyasını (state) manuel düzenlemelerden koruyun ve durum şifrelemesini sağlayın. Uygulama (apply) zamanında Secret Manager’dan okuma yaparak ve data source’ları idareli kullanarak durum dosyasında gizli bilgileri (secret) tutmaktan kaçının.

undefined

Planlar ve uygulamalar: terraform plan komutunu -out ile çalıştırın ve farkları (diff) bir insanın veya otomatik bir kontrol mekanizmasının (gate) incelemesini sağlayın; yalnızca önceden onaylanmış planı uygulayın. Sapma tespiti (drift detection) işlerinde -refresh-only veya -detailed-exitcode kullanın.
Ortam ayrımı: Her ortam için ayrı projeler, state bucket’ları ve hizmet hesapları (service account) kullanın. Karmaşık organizasyonlar için workspace’ler yerine değişken dosyalarıyla birlikte ortam başına dizin (directory-per-environment) yapısını tercih edin. Ortamlar arasında asla durum (state) paylaşmayın.
Hata modları: Eş zamanlı uygulamalar (apply) durumu (state) bozar; CI/CD ve kilitleme (locking) ile serileştirmeyi zorunlu kılın (GCS, nesne ön koşullarını - object preconditions - kullanır). Konsoldan yapılan manuel değişiklikler sapmaya (drift) neden olur; doğrudan mutasyonları kısıtlayın ve periyodik plan işleri çalıştırın.

Kubernetes bildirimsel (declarative) yapılandırması

Manifest’ler: Kubernetes nesnelerini bildirimsel (declarative) tutun; üretim akışlarında kubectl‘in zorunlu (imperative) komutlarından kaçının. Imaj digest’lerini ve kaynak isteklerini/limitlerini (resource requests/limits) sabitleyin.
Kustomize: Chart’ları çatallandırmadan (forking) ortama özgü yamaları (patch) yönetmek için base + overlay’leri kullanın.

undefined

Helm: Her ortam için values dosyaları kullanın; öncelik sırasını belgeleyin (komut satırı değerleri, values dosyalarını geçersiz kılar; values dosyaları da chart varsayılanlarını geçersiz kılar). Dağıtım zamanı yapılandırmalarının değişmez (immutable) olması için CI’da şablon oluşturun ve render edin (skaffold render veya helm template).
GitOps: İstenen durumu (desired state) Git’te saklayın. Cluster’ları Git ile uyumlu hale getirmek (reconcile) için Cloud Deploy veya Config Sync kullanın. PR’lar (Pull Request’ler), denetim izleri (audit trail) ve ilke kontrolleri (policy check) ile değişim kontrol yüzeyi haline gelir. Git’te yakalanmayan kubectl exec değişikliklerinden kaçının.

← Kimlik · Tüm alanlar · Gözlemlenebilirlik →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →