Google ACE: Wdrażanie, konfiguracja i automatyzacja — Przewodnik do nauki

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

Przegląd

Wdrażanie, konfiguracja i automatyzacja w Google Cloud koncentrują się na powtarzalnym, audytowalnym i bezpiecznym dostarczaniu zmian. Dobre praktyki opierają się na infrastrukturze jako kod (IaC), szablonach deklaratywnych, niezmiennych artefaktach i standaryzowanych potokach. Doskonałość operacyjna wynika z projektowania pod kątem idempotentności, podglądu zmian, wymuszania polityk oraz planowania kontrolowanych wdrożeń z jasnymi ścieżkami wycofywania zmian. Poniższe sekcje przedstawiają praktyczne wzorce, przykłady poleceń oraz uzasadnienie wyborów projektowych, w tym typowe pułapki i kompromisy.

Podstawy infrastruktury jako kod i konfiguracji

Zasady:

Szablony deklaratywne opisują pożądany stan końcowy; narzędzia uzgadniają stan rzeczywisty, aby go dopasować. Poprawia to idempotentność, powtarzalność i audytowalność.
Niezmienna infrastruktura wdraża nowe instancje lub wersje zamiast modyfikować istniejące, co upraszcza wycofywanie zmian i redukuje dryf.
Separacja odpowiedzialności: parametryzuj wartości specyficzne dla środowiska, jednocześnie ponownie wykorzystując współdzielone moduły lub szablony.

Terraform w Google Cloud:

Konfiguracja: Pliki HCL definiują zasoby, zmienne i dane wyjściowe. Używaj modułów do enkapsulacji VPC, kont serwisowych lub klastrów GKE; publikuj współdzielone moduły wewnętrznie, aby standaryzować wzorce.
Stan: Utrzymuj stan zdalnie i w wersjonowanej formie. Używaj backendu Cloud Storage z włączonym wersjonowaniem obiektów i odpowiednią retencją bucketu.
- Przykładowy blok backendu:

undefined

Scenariusze awarii: lokalny stan lub niewersjonowane buckety niosą ryzyko utraty danych i jednoczesnych zapisów. Wymuszaj dostęp do bucketu stanu z najniższymi uprawnieniami; preferuj krótkotrwałe poświadczenia i impersonację konta serwisowego zamiast kluczy.
Plany i aplikowanie zmian: terraform plan dostarcza podgląd; zabezpieczaj operacje apply w CI/CD, wymagając zatwierdzenia przez człowieka dla środowiska produkcyjnego. Używaj -target oszczędnie; częste targetowanie zwiększa ryzyko dryfu.
Moduły: wersjonuj moduły semantycznie; przypinaj wersje, aby unikać nieplanowanych zmian. Waliduj za pomocą terraform validate i sprawdzaj polityki przed wykonaniem apply.
Import i dryf: terraform import wprowadza istniejące zasoby pod zarządzanie; następnie dokonaj starannego przeglądu stanu. Wykrywaj dryf, regularnie uruchamiając terraform plan.
Zdalne wykonanie: uruchamiaj Terraform w zadaniach Cloud Build lub Cloud Run z Workload Identity Federation, aby unikać kluczy kont serwisowych. Buforuj providerów, aby skrócić czas budowania.

Deployment Manager:

Chociaż wiele zespołów standaryzuje się na Terraform, możesz natknąć się na Deployment Manager. Aby zaktualizować wdrożenie bez przestoju, zaktualizuj konfigurację:

undefined

Standardy konfiguracji:

Nazewnictwo: stosuj spójne, łatwe do przetworzenia nazwy zawierające środowisko, region, przeznaczenie i numer porządkowy, np. vpc-prod-usw1-core.
Etykiety: dołączaj do wszystkich zasobów etykiety takie jak env, cost_center, owner i app; wymuszaj ich stosowanie za pomocą polityk lub walidacji.
Tagi: używaj tagów sieciowych do określania zakresu reguł zapory sieciowej; unikaj przeciążania tagów do celów tożsamości lub własności (etykiety są

Operacje w wierszu poleceń i zarządzanie środowiskiem

Konfiguracje Cloud Shell i gcloud:

Cloud Shell zapewnia zarządzane środowisko administracyjne z wstępnie uwierzytelnionym gcloud i trwałym katalogiem domowym.
Użyj nazwanych konfiguracji, aby szybko przełączać konta, projekty i regiony: gcloud config configurations create prod gcloud config set project my-prod gcloud config set compute/region us-central1 gcloud config set compute/zone us-central1-a gcloud config configurations activate prod
Sprawdź aktywną konfigurację za pomocą gcloud config list. Dla GKE pobierz dane uwierzytelniające: gcloud container clusters get-credentials my-cluster –region us-central1

Wzorce poleceń Compute:

Tworzenie maszyny wirtualnej z zarezerwowanym wewnętrznym adresem IP: gcloud compute addresses create license-ip –region=us-central1 –subnet=default –addresses=10.0.3.21 gcloud compute instances create license-server –zone=us-central1-a –subnet=default –private-network-ip=10.0.3.21 –tags=license
Tworzenie niestandardowej sieci VPC, podsieci i reguły zapory sieciowej: gcloud compute networks create core –subnet-mode=custom gcloud compute networks subnets create core-us –network=core –range=10.0.0.0/20 –region=us-central1 gcloud compute firewall-rules create allow-https –network=core –allow=tcp:443 –target-tags=web

Wzorce IAM:

Nadawanie roli w zakresie projektu: gcloud projects add-iam-policy-binding my-project –member=group:ops@example.com –role=roles/logging.viewer
Kopiowanie ról niestandardowych między projektami: gcloud iam roles copy myCustomRole –source=my-dev –destination=my-prod

Wzorce Storage:

Tworzenie zasobnika (bucket) i przesyłanie obiektów: gcloud storage buckets create gs://backups-prod –location=us-central1 –class=coldline –uniform-bucket-level-access gcloud storage cp ./backup.tar.gz gs://backups-prod/
Konfiguracja cyklu życia za pomocą pliku i zastosowanie za pomocą gcloud storage buckets update –lifecycle-file=policy.json

Włączanie i weryfikacja API:

Włączanie Pub/Sub dla aplikacji: gcloud services enable pubsub.googleapis.com
Wyświetl listę włączonych usług: gcloud services list –enabled

Zarządzanie, dryf i automatyzacja

Dryf konfiguracji i egzekwowanie polityk:

Wykrywaj dryf, uruchamiając terraform plan zgodnie z harmonogramem; przerywaj buildy w przypadku nieoczekiwanych zmian.
Wymuszaj ograniczenia polityk organizacji (np. ograniczanie zewnętrznych adresów IP) i waliduj konfiguracje zasobów za pomocą policy-as-code przed zastosowaniem zmian (apply).
W przypadku Kubernetes użyj Config Sync i Policy Controller do ciągłego uzgadniania stanu i blokowania niezgodnych zmian.
Audytowalność: opieraj się na logach Admin Activity i Data Access; przesyłaj je do BigQuery w celu analizy. Użyj Cloud Asset Inventory do zapytań o stan w danym punkcie w czasie i z przeszłości (time-travel).

Limity i przydziały (quotas):

Sprawdzaj limity (quotas) per region i projekt; planuj zapas na potrzeby autoskalowania i wdrożeń:

undefined

Wnioskuj o zwiększenie limitów z wyprzedzeniem przed planowanym wzrostem lub dużymi wdrożeniami.

Zautomatyzowane zadania operacyjne:

Cloud Scheduler wyzwala punkty końcowe HTTP, tematy Pub/Sub lub Workflows zgodnie z harmonogramem cron. Zapewnij idempotentne handlery; skonfiguruj ponowienia i tematy dead-letter.
Workflows orkiestrują wieloetapową automatyzację w obrębie API Google z ponowieniami, krokami równoległymi i logiką kompensacyjną.
Zadania (jobs) Cloud Run wykonują skonteneryzowane zadania wsadowe lub administracyjne na żądanie lub za pośrednictwem Schedulera. Preferuj zadania (jobs) dla jednorazowych lub iteracyjnych obciążeń; używaj minimalnych uprawnień na koncie serwisowym zadania.

Bezpieczeństwo wdrożeń i obserwowalność:

Wbuduj kontrole stanu (health checks) i gotowości (readiness probes) w usługi. W przypadku MIGs z wolnym startem, zwiększ początkowe opóźnienie (initial delay), aby zapobiec przedwczesnym akcjom skalowania.
Zbieraj metryki wdrożeń i budżety błędów (error budgets); wstrzymuj lub automatycznie przerywaj wdrożenia, gdy SLO ulegają pogorszeniu.

Praktyczny scenariusz problemowy

Firma Altostrat Media musi ustandaryzować wdrożenia wielośrodowiskowe dla usługi opartej na GKE, jednocześnie eliminując dryf konfiguracji i zapewniając szybki rollback. Muszą również zarezerwować stały wewnętrzny adres IP dla serwera licencji starszego typu (legacy) bez rekonfiguracji aplikacji.

Stwórz fundamentalne moduły Terraform i zdalny stan (remote state)

Zaimplementuj moduły dla VPC, podsieci, GKE, kont serwisowych i reguł zapory sieciowej. Skonfiguruj backend Cloud Storage z włączonym wersjonowaniem i polityką retencji dla bucketa stanu.
Uzasadnienie: Modularyzacja promuje ponowne wykorzystanie i spójność; zdalny, wersjonowany stan umożliwia współpracę, odzyskiwanie i blokowanie (locking).

Włącz wymagane usługi i utwórz tożsamości automatyzacji z minimalnymi uprawnieniami (least-privilege)

Włącz compute.googleapis.com, container.googleapis.com, clouddeploy.googleapis.com, artifactregistry.googleapis.com.
Utwórz konta serwisowe per środowisko dla Terraform, Cloud Build i Cloud Deploy; nadaj minimalne role (np. roles/container.admin dla wdrażających, a nie dla budujących).
Uzasadnienie: Wcześniejsze włączenie usług i zawężenie zakresu ról zmniejsza liczbę nieudanych wdrożeń i ogranicza promień rażenia (blast radius).

Zapewnij zasoby sieciowe i zarezerwuj adres IP dla systemu legacy

Za pomocą Terraform utwórz niestandardowe VPC, podsieci regionalne i reguły zapory sieciowej oparte na tagach sieciowych.
Zarezerwuj wewnętrzny adres IP:

undefined

Uzasadnienie: Deklaratywna sieć zapewnia powtarzalność; rezerwacja adresu IP zachowuje założenia aplikacji.

Zbuduj artefakty za pomocą Cloud Build i opublikuj w Artifact Registry

Zdefiniuj plik cloudbuild.yaml do uruchamiania testów, budowania kontenera, skanowania i wysyłania niezmiennego digestu do Artifact Registry.
Uzasadnienie: Niezmienne, przeskanowane artefakty są podstawą bezpiecznych promocji i śledzenia pochodzenia (provenance).

Skonfiguruj pipeline Cloud Deploy z celami (targets) dev → qa → prod

Zdefiniuj pipeline dostarczania i cele (targets); odwołaj się do konfiguracji Skaffold, aby renderować manifesty. Wymagaj ręcznego zatwierdzenia dla środowiska prod i skonfiguruj weryfikacje.
Uzasadnienie: Ustrukturyzowana promocja wymusza mechanizmy kontrolne; polityki per-cel zapobiegają przypadkowemu wdrożeniu na produkcję.

Wdrażaj aktualizacje GKE za pomocą strategii canary i bramek zdrowia (health gates)

Użyj polityki wdrożenia canary, aby przenieść 10%, następnie 50%, a na końcu 100% ruchu, w zależności od wyników kontroli SLO i wskaźnika błędów.
Uzasadnienie: Progresywne dostarczanie (progressive delivery) zmniejsza ryzyko i zapewnia naturalne punkty do wykonania rollbacku.

Wyeliminuj dryf za pomocą zaplanowanych planów i kontroli polityk

Nocne zadanie uruchamia terraform plan i walidator policy-as-code; wysyła alerty w przypadku nieoczekiwanych różnic lub naruszeń.
Uzasadnienie: Wczesne wykrywanie zapobiega kumulacji dryfu i awariom przyszłych zastosowań (apply).

Uruchom operacyjnie maszynę wirtualną serwera licencji z zarezerwowanym adresem IP

Utwórz maszynę wirtualną powiązaną z zarezerwowanym adresem i odpowiednimi tagami:

undefined

Uzasadnienie: Zapewnia osiągalność bez zmiany aplikacji; tagi utrzymują wąski zakres reguł zapory sieciowej.

Zautomatyzuj powtarzające się zadania za pomocą Scheduler, Workflows i zadań (jobs)

Cloud Scheduler wyzwala Workflow do rotacji kluczy kont serwisowych (tam, gdzie jest to nieuniknione) oraz do uruchamiania zadania Cloud Run w celu cotygodniowego czyszczenia bazy danych (vacuum).
Uzasadnienie: Scentralizowane harmonogramowanie w połączeniu z orkiestracją zapewnia niezawodność i obserwowalność z mechanizmami ponowień i kompensacji.

Zaplanuj rollbacki i zweryfikuj progi gotowości (readiness thresholds)

Zdefiniuj procedury (playbooks) rollbacku, aby ponownie promować ostatnie dobre wydanie. Dostosuj sondy gotowości (readiness probes) oraz, dla wszelkich obciążeń opartych na MIG, zwiększ początkowe opóźnienia kontroli stanu, aby dopasować je do czasu rozgrzewania się aplikacji.
Uzasadnienie: Wcześniej zaplanowany rollback i dostrojone kontrole stanu zapobiegają kaskadowym awariom i nadmiernemu provisioningu podczas incydentów.

Takie podejście łączy niezmienne artefakty, deklaratywną infrastrukturę, bramkowane promocje i automatyzację z minimalnymi uprawnieniami, aby zapewnić bezpieczne, audytowalne i powtarzalne operacje w Google Cloud.

← Pamięć masowa · Wszystkie domeny · Monitorowanie →

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