Google PCD: Ciągłe dostarczanie, konfiguracja oraz automatyzacja infrastruktury — Przewodnik do nauki

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

Część Google Professional Cloud Developer — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Google, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Ciągłe dostarczanie (continuous delivery) w Google Cloud integruje automatyzację budowania, zarządzanie artefaktami, orkiestrację wdrożeń, infrastrukturę jako kod oraz solidne zarządzanie (governance), aby wielokrotnie i bezpiecznie dostarczać zmiany. Solidne potoki (pipelines) łączą niezmienne artefakty i konfigurację deklaratywną z politykami i audytowalnością. Ta sekcja wyjaśnia wybory projektowe, praktyki operacyjne i typowe tryby awarii podczas kompleksowej implementacji Cloud Build, Cloud Deploy, Artifact Registry, Terraform, Kubernetes, flag funkcjonalności (feature flags) i kontroli zarządczych.

Orkiestracja budowania i wdrażania

Cloud Build

Wyzwalacze (Triggers): Łączą buildy ze zdarzeniami w kodzie źródłowym (pushe do gałęzi, tagi, PR-y) lub harmonogramami. Preferuj wyrażenia regularne dla gałęzi lub tagów, aby zapewnić, że uruchamiane są tylko zamierzone referencje (refs). Wyzwalacze mogą działać jako określone konto serwisowe w celu egzekwowania zasady najmniejszych uprawnień; nie polegaj na domyślnym, jeśli buildy wymagają szerokiego dostępu do API.
Kroki budowania (Build steps): Każdy krok jest uruchamiany w kontenerze. Używaj dedykowanych builderów (docker, gcloud) lub niestandardowych, gdy domyślny zestaw narzędzi jest niewystarczający. Oddzielaj kroki kompilacji, testów jednostkowych, testów integracyjnych, lintingu, skanowania bezpieczeństwa i pakowania artefaktów, dzięki czemu awarie są łatwe do zidentyfikowania, a kroki efektywnie buforowane.
Podstawienia (Substitutions): Używaj wbudowanych zmiennych (PROJECT_ID, SHORT_SHA) i niestandardowych podstawień (z prefiksem $_) do parametryzacji buildów. Trzymaj wartości specyficzne dla środowiska poza logiką budowania; przekazuj je jako podstawienia lub rozwiązuj później podczas wdrożenia.
Konta serwisowe (Service accounts): Konto serwisowe Cloud Build (PROJECT_NUMBER@cloudbuild.gserviceaccount.com) wymaga jawnie nadanych ról (na przykład, zapis do Artifact Registry, administrator wydań Cloud Deploy). Przypisuj minimalne role i ograniczaj ich zakres do projektu. Dla zasobów prywatnych używaj Private Pools z łącznością VPC.
Artefakty (Artifacts): Publikuj niezmienne obrazy w Artifact Registry i opcjonalnie przesyłaj artefakty niebędące kontenerami do Cloud Storage za pomocą sekcji artifacts. Oznaczaj obrazy zarówno wersją semantyczną, jak i skrótem (digest) commita; używaj skrótów obrazów (image digests) we wdrożeniach, aby uniknąć zjawiska tag drift (rozjeżdżania się tagów).

Przykładowa konfiguracja Cloud Build:

cloudbuild.yaml: steps:
- name: gcr.io/cloud-builders/docker args: [“build”,"-t","$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}","."]
- name: gcr.io/cloud-builders/docker args: [“push”,"$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}"]
- name: gcr.io/cloud-builders/gcloud args: [“deploy”,“releases”,“create”,“app-${SHORT_SHA}”,"–delivery-pipeline=app-pipeline","–images=app=$REGION-docker.pkg.dev/$PROJECT_ID/app/app@sha256:${COMMIT_SHA}"] substitutions: _REGION: us-central1 serviceAccount: projects/$PROJECT_ID/serviceAccounts/cb-deployer@$PROJECT_ID.iam.gserviceaccount.com
Przykład wyzwalacza: gcloud builds triggers create cloud-source-repositories –repo=my-repo –branch-pattern=^main$ –build-config=cloudbuild.yaml –service-account=cb-deployer@$PROJECT_ID.iam.gserviceaccount.com

Cloud Deploy

Potoki dostarczania (Delivery pipelines) definiują uporządkowane etapy (stages) i cele (targets). Cele odnoszą się do klastrów GKE, usług Cloud Run lub innych wspieranych środowisk uruchomieniowych. Oznacz etapy produkcyjne za pomocą requireApproval, aby bramkować promocję.
Wdrożenia (Rollouts) mapują wydanie (release) na cel (target); promocja przesuwa wydanie przez kolejne cele. Używaj progresywnego dostarczania (canary, blue/green) i haków (hooks) do sprawdzania przed i po wdrożeniu.
Tryby awarii: Używanie zmiennych tagów powoduje niezamierzone aktualizacje; zawsze przypinaj skróty (digests). Brak uprawnień IAM dla konta wdrażającego blokuje wdrożenia (rollouts). Niemożliwe do wyrenderowania manifesty lub dryf konfiguracji specyficznej dla środowiska prowadzą do niepowodzeń promocji; waliduj manifesty podczas budowania.

Przykładowe definicje Cloud Deploy:

delivery-pipeline.yaml: apiVersion: deploy.cloud.google.com/v1 kind: DeliveryPipeline metadata: name: app-pipeline serialPipeline: stages:
- targetId: dev
- targetId: prod strategy: standard: verify: true requireApproval: true
targets.yaml: apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: dev gke: cluster: projects/PROJECT/locations/REGION/clusters/DEV_CLUSTER
Definicja celu produkcyjnego
apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: prod gke: cluster: projects/PROJECT/locations/REGION/clusters/PROD_CLUSTER
Wydanie i promocja: gcloud deploy releases create app-20260903-1 –delivery-pipeline=app-pipeline –region=us-central1 –images=app=us-central1-docker.pkg.dev/PROJECT/app/app@sha256:IMAGE_DIGEST gcloud deploy releases promote –delivery-pipeline=app-pipeline –release=app-20260903-1 –region=us-central1

Artefakty i integralność łańcucha dostaw

Artifact Registry

Repozytoria: Twórz osobne repozytoria dla każdego zespołu lub środowiska, aby ograniczyć zakres IAM i ułatwić czyszczenie. Używaj repozytoriów regionalnych w pobliżu builderów i środowisk uruchomieniowych, aby zmniejszyć ruch wychodzący (egress) i opóźnienia. Formaty pakietów obejmują obrazy Docker i pakiety językowe (Maven, npm, PyPI).
Retencja: Zdefiniuj polityki czyszczenia, aby usuwać nieużywane lub stare tagi, zachowując okno bezpieczeństwa na potrzeby wycofywania zmian (rollback). Unikaj agresywnej retencji, która usuwa ostatnią znaną dobrą wersję.
Proweniencja i SBOM: Włącz proweniencję (provenance) buildów, aby obrazy zawierały atestacje zgodne z SLSA. Generuj SBOM podczas budowania i przechowuj jako atestacje, usprawniając analizę podatności.
Skanowanie podatności: Włącz analizę kontenerów i przerywaj build lub blokuj promocję, gdy wykryte zostaną CVE o wysokiej krytyczności bez dostępnych poprawek lub wyjątków w polityce.
Kompromisy: Centralizacja wszystkich artefaktów w jednym projekcie upraszcza zarządzanie, ale może stworzyć duży promień rażenia (blast radius); repozytoria per środowisko lub per aplikacja zmniejszają ryzyko, ale zwiększają narzut administracyjny.

Egzekwowanie zasad łańcucha dostaw

Binary Authorization na GKE może wymagać atestacji (na przykład „zbudowane przez Cloud Build w projekcie X”, „brak krytycznych CVE”). Zintegruj z bramkami Cloud Deploy, aby zatrzymywać wydania niezgodne z polityką.
Tryby awarii: Poleganie na zmiennych tagach, wyłączonym skanowaniu lub nieuwierzytelnionym pobieraniu może prowadzić do trafienia niezweryfikowanego oprogramowania na produkcję. Przypinaj skróty (digests) i wymagaj atestacji.

Infrastruktura jako kod i GitOps

Terraform

Konfiguracja i moduły: Wydzielaj moduły wielokrotnego użytku z jasno zdefiniowanymi wejściami/wyjściami i semantycznym wersjonowaniem. Publikuj moduły we współdzielonym repozytorium lub rejestrze; przypinaj wersje, aby uniknąć niespodziewanych zmian.
Stan (state): Używaj backendu GCS do zdalnego przechowywania stanu z uprawnieniami IAM na poziomie bucketa, wersjonowaniem obiektów i CMEK. Chroń stan przed ręcznymi modyfikacjami i zapewnij jego szyfrowanie. Unikaj przechowywania sekretów w stanie, odczytując je z Secret Manager w momencie wykonywania apply i oszczędnie korzystając z data sources.

undefined

Plany i ich wdrażanie (plan/apply): Uruchamiaj terraform plan z flagą -out i wprowadzaj weryfikację różnic (diff) przez człowieka lub automatyczną bramkę; wdrażaj (apply) tylko wcześniej zatwierdzony plan. Używaj -refresh-only lub -detailed-exitcode w zadaniach wykrywających dryf konfiguracji (drift detection).
Separacja środowisk: Używaj osobnych projektów, bucketów na stan i kont serwisowych dla każdego środowiska. W złożonych organizacjach preferuj strukturę katalogów per środowisko z plikami zmiennych zamiast workspaces. Nigdy nie współdziel stanu między środowiskami.
Scenariusze awarii: Równoczesne operacje apply uszkadzają stan; wymuszaj serializację za pomocą CI/CD i blokad (GCS używa do tego warunków wstępnych obiektu - object preconditions). Ręczne zmiany w konsoli powodują dryf konfiguracji; ograniczaj bezpośrednie modyfikacje i uruchamiaj okresowo zadania generujące plan (plan).

Deklaratywna konfiguracja Kubernetes

Manifesty: Utrzymuj obiekty Kubernetes w formie deklaratywnej; unikaj poleceń imperatywnych kubectl w procesach produkcyjnych. Przypinaj skróty (digest) obrazów oraz żądania/limity zasobów (requests/limits).
Kustomize: Używaj struktury base + overlays (nakładki) do obsługi poprawek specyficznych dla danego środowiska bez potrzeby forkowania chartów. kustomization.yaml (nakładka - overlay):

undefined

Helm: Używaj plików values dla każdego środowiska; dokumentuj kolejność pierwszeństwa (wartości z wiersza poleceń nadpisują pliki values, które z kolei nadpisują domyślne wartości chartu). Generuj szablony i renderuj konfigurację w CI (skaffold render lub helm template), aby konfiguracje wdrożeniowe były niemutowalne.
GitOps: Przechowuj pożądany stan w Git. Używaj Cloud Deploy lub Config Sync do uzgadniania stanu klastrów z Gitem. Pull Requesty (PR) stają się płaszczyzną kontroli zmian, zapewniając ścieżki audytowe i weryfikację polityk. Unikaj modyfikacji za pomocą kubectl exec, które nie są zapisane w Git.

Bezpieczeństwo wydań, konfiguracja i ład (Governance)

Flagi funkcyjne i konfiguracja w czasie rzeczywistym

Flagi funkcyjne oddzielają wdrożenie (deploy) od wydania (release); dostarczaj nieaktywny kod i włączaj go dla danej kohorty, procentu użytkowników lub regionu. Przechowuj definicje flag w systemie o niskim opóźnieniu i wysokiej dostępności (HA), np. Firestore lub Memorystore, i buforuj je z krótkim czasem życia (TTL). Loguj ewaluacje flag w celu zapewnienia śledzalności.
Stopniowe wdrażanie (gradual rollout): Połącz dzielenie ruchu (Cloud Run) lub podzbiory kanarkowe (GKE) z flagami, aby zminimalizować zasięg awarii (blast radius). Używaj metryk kondycji i automatycznych wyzwalaczy wycofania (rollback) opartych na SLO.
Bezpieczne wycofywanie zmian (rollback): Preferuj szybkie wyłączanie funkcji za pomocą flag. W przypadku wycofywania binarnego, promuj ostatnie znane dobre wydanie lub ponownie zastosuj poprzedni skrót (digest) manifestu.

Zmienne środowiskowe, pierwszeństwo, sekrety

Kolejność pierwszeństwa jest zazwyczaj następująca: flagi w czasie rzeczywistym > zmienne środowiskowe > pliki konfiguracyjne > wartości domyślne w kodzie. Udokumentuj i ustandaryzuj ten porządek we wszystkich usługach.
Wstrzykuj konfigurację za pomocą ConfigMaps i zmiennych środowiskowych; używaj Secret Manager lub Kubernetes Secrets dla wartości wrażliwych. Regularnie rotuj sekrety i unikaj ich „wypalania” w obrazach.
Przykłady wstrzykiwania sekretów:
- Zmienna środowiskowa w Cloud Run: gcloud run services update api –update-secrets=DB_PASSWORD=projects/PROJECT/secrets/db_password:latest
- Secret Manager CSI w GKE: apiVersion: v1 kind: Pod metadata: name: app spec: volumes:
  - name: sm csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: gsm-secrets containers:
  - name: app volumeMounts:
    - name: sm mountPath: /secrets

Bramki jakości w CI/CD

Testy jednostkowe uruchamiane są przy każdym commicie; kluczowe jest uzyskanie szybkiej informacji zwrotnej.
Testy integracyjne uruchamiane są na środowiskach efemerycznych lub w piaskownicach (sandboxach) z wstępnie załadowanymi danymi.
Kontrole bezpieczeństwa: SAST, skanowanie zależności, skanowanie podatności kontenerów, sprawdzanie polityk IaC (Conftest, Policy Controller). Blokuj merge lub promocje w przypadku krytycznych znalezisk.
Kontrole wdrożeniowe: Akcje predeploy i postdeploy w Cloud Deploy weryfikują gotowość, bezpieczeństwo migracji bazy danych i testy typu smoke test.

Branching, przegląd kodu, wersjonowanie, śledzalność

Preferuj rozwój oparty na gałęzi głównej (trunk-based development) z krótkotrwałymi gałęziami funkcyjnymi (feature branches) i obowiązkowymi przeglądami PR (Pull Request). Wymuszaj wymagane testy i liniową historię w celu zapewnienia audytowalności.
Wersjonowanie: Używaj tagów wersji semantycznej (semantic version) dla wydań; skrótów (digest) obrazów i sum kontrolnych (SHA) commitów dla zapewnienia niezmienności. Unikaj ruchomych tagów, takich jak latest, we wdrożeniach produkcyjnych.
Śledzalność: Adnotuj buildy i wydania identyfikatorami commitu, PR i zgłoszenia (ticketu). Emituj zdarzenia wdrożeniowe do Logging; dołączaj etykiety do zasobów w celu śledzenia kosztów i własności.

Dryf infrastruktury, polityki, audyt, kontrola zmian

Wykrywanie dryfu: Zaplanowane zadanie terraform plan -detailed-exitcode; generuj alerty dla kodów wyjścia różnych od zera. W przypadku klastrów, Config Sync zapewnia ostateczną zbieżność ze stanem w Git.
Egzekwowanie polityk: Używaj Organization Policy do tworzenia barier ochronnych (np. ograniczanie zewnętrznych adresów IP), Policy Controller dla ograniczeń KRM oraz Binary Authorization dla polityki obrazów.
Logi audytowe: Włącz logi Admin Activity i Data Access; kieruj je do scentralizowanych projektów z odbiornikami (sinks) i retencją zgodną z wymogami compliance. Cloud Asset Inventory dostarcza historię zmian i analizę dostępu.
Kontrola zmian: Ręczne zatwierdzenia przy promocji na produkcję, z uzasadnieniami zapisanymi jako adnotacje. Okna zamrożenia (freeze windows) można zakodować jako kontrole polityk w CI/CD. Upewnij się, że ścieżki awaryjnego wycofywania zmian są udokumentowane i przećwiczone.

Praktyczny scenariusz problemowy

Firma Acme Retail musi wdrożyć nową usługę order-service na GKE w środowiskach dev i prod, stosując bezpieczne wdrożenia kanarkowe (canary rollouts), ścisłe egzekwowanie polityk i pełną śledzalność wydań. Zespół musi ustandaryzować infrastrukturę zarządzaną przez Terraform, deklaratywną konfigurację Kubernetes z Kustomize oraz audytowalne CI/CD przy użyciu Cloud Build i Cloud Deploy.

Podejście:

Ustanowienie repozytoriów artefaktów i tożsamości

Utwórz regionalne repozytoria Artifact Registry: order-docker-dev i order-docker-prod. Nadaj kontu serwisowemu Cloud Build w projekcie aplikacji rolę roles/artifactregistry.writer, a węzłom GKE rolę roles/artifactregistry.reader dla odpowiedniego repozytorium.
Uzasadnienie: Oddzielne repozytoria zmniejszają zasięg awarii i upraszczają polityki cyklu życia. Jawne przypisanie ról IAM pozwala uniknąć nadmiernie uprzywilejowanych ustawień domyślnych.

Zdefiniowanie infrastruktury w Terraform z separacją środowisk

Utwórz katalogi terraform/envs/dev i terraform/envs/prod. Każda konfiguracja zawiera backend GCS z oddzielnymi bucketami na stan, moduł klastra GKE oraz powiązania IAM dla konta serwisowego Cloud Deploy. Uruchom terraform init, plan -out=plan.bin i apply plan.bin w zadaniu CI z bramką zatwierdzania dla każdego środowiska.
Uzasadnienie: Stan i projekty per środowisko zapobiegają przypadkowemu wpływowi międzyśrodowiskowemu; pliki planu wspierają przegląd i audytowalną kontrolę zmian.

Stworzenie deklaratywnej bazy Kubernetes i nakładek Kustomize

Umieść manifesty Kubernetes w k8s/base dla Deployment, Service i HPA z obrazami przypiętymi za pomocą skrótu (digest). Utwórz k8s/overlays/dev i k8s/overlays/prod z łatami (patches) dla liczby replik, żądań zasobów i konfiguracji. Użyj klasy Secret Manager CSI dla poświadczeń bazy danych.
Uzasadnienie: Pojedyncze źródło prawdy (single source of truth) z nakładkami eliminuje dryf i utrzymuje konfiguracje zgodnie z zasadą DRY (Don’t Repeat Yourself), jednocześnie umożliwiając bezpieczne różnice specyficzne dla środowiska.

Implementacja Cloud Build z oddzielnymi krokami testowania i pakowania

Plik cloudbuild.yaml zawiera kroki: lintowanie i testy jednostkowe, testy integracyjne na jednorazowej przestrzeni nazw (namespace) dev, budowanie i wypychanie kontenera do repozytorium środowiska, skanowanie SBOM i podatności oraz generowanie pochodzenia (provenance). Trigger uruchamia się na PR do gałęzi main dla testów i na merge’ach dla pakowania. Buildy są uruchamiane na koncie serwisowym cb-deployer z minimalnymi uprawnieniami.
Uzasadnienie: Wczesne wykrywanie błędów jest tanie; rozdzielenie odpowiedzialności poprawia obserwowalność i umożliwia celowe ponawianie prób. Zasada najmniejszych uprawnień (least-privilege) zmniejsza ryzyko w łańcuchu dostaw.

Konfiguracja potoku dostarczania (delivery pipeline) Cloud Deploy z ręcznym zatwierdzeniem dla produkcji i strategią kanarkową

Zdefiniuj DeliveryPipeline z celami dev i prod. Etap prod wymaga zatwierdzenia i używa strategii kanarkowej (np. 10%, a następnie 100%). Użyj hooków predeploy do sprawdzania kompatybilności schematu i testów typu smoke test; postdeploy weryfikuje SLO.
Uzasadnienie: Progresywne dostarczanie ogranicza zasięg awarii i wprowadza zautomatyzowane bramki jakości, podczas gdy ręczne zatwierdzenie zapewnia udział człowieka (human-in-the-loop) dla środowiska produkcyjnego.

Połączenie GitOps i egzekwowania polityk

Chroń gałąź main poprzez wymagane przeglądy i pomyślnie zakończone testy. Użyj ograniczeń Policy Controller, aby blokować uprzywilejowane pody i zabronić używania zmiennych (mutable) tagów. Włącz Binary Authorization, aby wymagać atestacji pochodzenia z Cloud Build i braku wysokich podatności CVE przed dopuszczeniem do wdrożenia.
Uzasadnienie: Polityka jako kod (Policy-as-code) zapobiega dotarciu ryzykownych konfiguracji do klastra i zapewnia spójne egzekwowanie zasad.

Zarządzanie konfiguracją i flagami funkcyjnymi dla bezpiecznego wydania

Przechowuj konfigurację czasu rzeczywistego (niebędącą sekretami) w ConfigMaps; sekrety są dostarczane przez Secret Manager CSI. Wprowadź flagę funkcyjną order_new_flow odczytywaną z Firestore z początkowym wdrożeniem na 1% w środowisku produkcyjnym; flagi są buforowane z krótkim TTL i logowane.
Uzasadnienie: Flagi oddzielają wydanie od wdrożenia, umożliwiając natychmiastowe wyłączenie funkcji w razie problemów, bez konieczności wycofywania binarnego.

Zapewnienie obserwowalności, wykrywania dryfu i śledzalności

Adnotuj buildy i wydania sumą SHA commita, numerem PR i identyfikatorem zgłoszenia zmiany. Kieruj zdarzenia z Cloud Deploy i logi audytowe GKE do centralnego projektu Logging. Codzienne zadania terraform plan alarmują o dryfie; Config Sync monitoruje rozbieżności KRM, uzgadniając stan z Git.
Uzasadnienie: Pełne pochodzenie i ścieżki audytu przyspieszają reakcję na incydenty; ciągłe wykrywanie dryfu utrzymuje integralność infrastruktury.

Obsługa wycofywania zmian i kontrola zmian

W przypadku incydentów, najpierw wyłącz order_new_flow za pomocą flagi. W razie potrzeby, promuj poprzednie udane wydanie w Cloud Deploy do dev i prod. Wszystkie promocje na produkcję wymagają odniesienia do zgłoszenia w adnotacjach wydania i zatwierdzenia od dyżurnego SRE.
Uzasadnienie: Flagi zapewniają natychmiastową mitygację; niezmienne wydania umożliwiają przewidywalne wycofywanie zmian. Zatwierdzenia i adnotacje spełniają wymogi ładu operacyjnego i zgodności (compliance).

← Tożsamość · Wszystkie domeny · Obserwowalność →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →