Amazon DOP-C02: Potoki CI/CD i strategie wdrożeń — Przewodnik do nauki

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Część AWS DevOps Engineer Professional DOP-C02 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Strategie wdrożeń i cykl życia CodeDeploy

Wybierz strategię w zależności od ryzyka, pojemności i platformy:

Wdrożenie w miejscu (In-place) (EC2/on-prem): Aktualizuje aplikację na istniejących instancjach. Łączone z konfiguracjami wdrożenia OneAtATime, HalfAtATime lub AllAtOnce. Dołącz ELB, aby opróżniać i ponownie rejestrować instancje.
Wdrożenie kroczące (Rolling) (ECS): Zastępuje zadania partiami w tej samej usłudze. Natywne wdrożenie kroczące ECS lub zarządzane przez CodeDeploy jako blue/green z kontrolowanym przełączaniem.
Niebiesko-zielone (Blue/green):
- EC2/Auto Scaling: Utwórz zieloną grupę ASG, zweryfikuj, a następnie przełącz ruch z niebieskiego na zielony. Opcjonalnie zakończ lub zachowaj niebieskie środowisko.
- ECS: Utwórz zastępczy zestaw zadań za drugą grupą docelową; zweryfikuj, a następnie przełącz listenery.
- Lambda: Przenieś ruch z aliasu na nową wersję funkcji i monitoruj.
Kanarkowe (Canary): Najpierw przenieś niewielki procent ruchu (np. 10%), obserwuj przez pewien czas, a następnie zakończ.
Liniowe (Linear): Zwiększaj ruch w równych krokach (np. 10% co 5 minut).

Plik appspec.yml w CodeDeploy definiuje, co instalować i kiedy uruchamiać skrypty:

Dla EC2/On-Prem (YAML):
- files: gdzie umieścić pliki.
- permissions: aktualizacje właściciela/trybu pliku bez niestandardowych skryptów.
- hooki (powszechne): ApplicationStop, BeforeInstall, Install, AfterInstall, ApplicationStart, ValidateService.
- Hooki kontroli ruchu (przy użyciu load balancera): BeforeBlockTraffic, AfterBlockTraffic, BeforeAllowTraffic, AfterAllowTraffic.
- Użyj predefiniowanych zmiennych środowiskowych (np. DEPLOYMENT_GROUP_NAME, DEPLOYMENT_ID, LIFECYCLE_EVENT), aby dynamicznie modyfikować zachowanie bez oddzielnych rewizji, np. przełączając poziomy logowania Apache dla każdej grupy wdrożenia.
Dla ECS:
- resources: TargetService z TaskDefinition i LoadBalancerInfo.
- hooki: BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic, AfterAllowTraffic.
- Hook AfterAllowTestTraffic jest idealny do testów typu smoke/integracyjnych na zielonym zestawie zadań z listenerem testowym.
Dla Lambda:
- resources definiują funkcję, wersję i alias do przełączenia.
- hooki: BeforeAllowTraffic i AfterAllowTraffic.

Przenoszenie ruchu i rollback:

Skonfiguruj konfiguracje wdrożenia:
- Lambda/ECS: Canary10Percent15Minutes, Canary10Percent5Minutes, Linear10PercentEvery1Minute, AllAtOnce lub niestandardowe.
- EC2 Blue/Green: Przekierowanie ruchu typu all-at-once, canary lub linear za pośrednictwem listenerów/grup docelowych load balancera.
Dodaj alarmy CloudWatch do grupy wdrożenia, aby automatycznie wycofywać zmiany (auto-rollback) w przypadku błędów, kodów 5xx lub niestandardowych metryk. Dla ECS alarmy mogą obserwować kody 5xx grupy docelowej lub metryki usługi; dla Lambda obserwuj metryki Errors/Throttles funkcji z wymiarami aliasu/wersji.
Użyj hooków cyklu życia (np. AfterAllowTestTraffic) do uruchamiania walidacji przez Lambda lub SSM; zakończenie z kodem innym niż zero powoduje rollback.

Wdrożenia Blue/Green i przenoszenie ruchu dla EC2, ECS i Lambda

EC2/Auto Scaling:

Wdrożenie blue/green z CodeDeploy tworzy nową grupę Auto Scaling dla środowiska zielonego, kojarzy ją z oddzielną grupą docelową, a następnie przełącza listenery ALB. Możesz wybrać automatyczne zakończenie środowiska niebieskiego lub zachowanie go w celu szybkiego rollbacku.
W przypadku wdrożeń w miejscu (in-place) na EC2, połącz je z ELB, aby płynnie wyrejestrowywać/rejestrować instancje i chronić dostępność. Konfiguracja wdrożenia określa rozmiary partii i tempo.

ECS:

CodeDeploy integruje się z usługami ECS, używając dwóch grup docelowych za ALB. Tworzony jest zastępczy zestaw zadań (zielony) z nową definicją zadania.
Ruch testowy przepływa do zielonej grupy docelowej przez dedykowany listener testowy; ruch produkcyjny pozostaje na niebieskim środowisku aż do momentu promocji.
Przełączanie typu canary lub linearne stopniowo przenosi ruch na zielone środowisko, monitorując alarmy CloudWatch. Użyj hooka AfterAllowTestTraffic do wykonania walidacji (np. funkcja Lambda wywołująca testy syntetyczne) przed przełączeniem produkcyjnym.

Lambda:

CodeDeploy aktualizuje alias funkcji do nowej wersji z routingiem ważonym. Wzorce canary i linearne stopniowo przenoszą procent ruchu. Alarmy CloudWatch na aliasie sterują automatycznym rollbackiem.
Za pomocą AWS SAM lub CDK, ustaw AutoPublishAlias i DeploymentPreference w szablonach, aby zakodować politykę canary/linearną i alarmy dla każdej funkcji.

Routing ważony poza CodeDeploy:

Dla równoważenia obciążenia między regionami lub stosami, rekordy ważone Route 53 ze sprawdzaniem kondycji (health checks) umożliwiają regionalne dzielenie ruchu (np. 1% do regionu zapasowego) i przełączanie awaryjne (failover). Uzupełnia to, ale nie zastępuje, przenoszenia ruchu na poziomie usługi oferowanego przez CodeDeploy.

Dostarczanie do wielu kont i wielu regionów

Potoki korporacyjne zazwyczaj znajdują się na scentralizowanym koncie „narzędziowym” (tooling account) i wdrażają aplikacje na konta dev/test/prod w wielu regionach:

Między kontami:
- W akcjach CodePipeline, określ RoleArn na koncie docelowym, które ufa jednostce głównej (principal) roli potoku. Używaj uprawnień o najniższych przywilejach dla każdej akcji (CloudFormation, CodeDeploy, ECS, Lambda).
- W przypadku CodeBuild, który musi mieć dostęp do zasobów na koncie docelowym, proces budowania powinien przyjąć rolę (STS) lub użyć roli akcji specyficznej dla konta, a nie szerokich uprawnień AdministratorAccess.
- W przypadku CodeDeploy na EC2, konto docelowe zarządza aplikacją/grupą wdrożeniową i rolą serwisową; potok przyjmuje rolę, aby wywołać CreateDeployment.
Między regionami:
- Dodaj magazyn artefaktów dla każdego regionu w konfiguracji potoku (bucket S3 z regionalnym kluczem KMS). Zaktualizuj polityki bucketów, aby zezwolić roli potoku i rolom poszczególnych akcji na odczyt/zapis.
- W razie potrzeby buduj artefakty specyficzne dla regionu (np. pakując kod Lambda za pomocą aws cloudformation package, wskazując na lokalny dla regionu bucket S3).
- Akcje wdrożenia CloudFormation w zdalnym regionie muszą odwoływać się do magazynu artefaktów tego regionu i mogą określać rolę wykonawczą stosu (stack execution role) na koncie docelowym w celu zapewnienia najniższych przywilejów.

Bezpieczeństwo, artefakty i ład korporacyjny:

Utrzymuj buckety z artefaktami jako prywatne; unikaj publicznych list ACL, takich jak authenticated-read. Opieraj się na politykach bucketów ograniczonych do ról potoku i akcji, z szyfrowaniem KMS.
Standaryzuj pliki buildspec, aby przewidywalnie przesyłać artefakty (np. pakiet aplikacji dla EC2/CodeDeploy, taskdef.json i appspec dla ECS, spakowane szablony dla Lambda).
Promuj niezmienność poprzez wstępne przygotowywanie obrazów AMI (pre-baking) dla EC2, aby agent CodeDeploy i podstawowe środowisko uruchomieniowe były spójne; zmniejsza to dryf konfiguracji i czas wdrożenia.
Używaj reguł EventBridge do przekazywania zdarzeń z potoku do systemów powiadomień, chat ops lub ticketów oraz do orkiestracji bramek manualnej akceptacji.

Praktyczny scenariusz problemu

Spotify potrzebuje bezpieczniejszych wydań dla setek mikrousług działających na mieszanym podłożu obliczeniowym (ECS na Fargate, usługi oparte na EC2 oraz Lambda). Wymagają wdrożeń typu canary i blue/green z automatycznymi testami przed skierowaniem ruchu produkcyjnego, ładu korporacyjnego nad artefaktami oraz promocji do wielu regionów, przy jednoczesnym utrzymaniu środowiska produkcyjnego na osobnym koncie.

Ustanowienie repozytoriów i pakietów

Użyj CodeCommit dla prywatnych repozytoriów i automatyzacji PR/testów sterowanej przez EventBridge. CodeArtifact przechowuje zależności npm, Maven i PyPI wraz z repozytoriami nadrzędnymi (upstreams) i szyfrowaniem KMS w celu standaryzacji kontroli łańcucha dostaw. Dlaczego: Centralna integracja z IAM/KMS i brak potrzeby używania zewnętrznych webhooków dla krytycznych repozytoriów; CodeArtifact dostarcza buforowane, zarządzane pakiety.

Budowanie i testowanie

Utwórz projekty CodeBuild dla każdej usługi z integracją VPC, lokalnym buforowaniem (warstwy Docker i źródła) oraz zmiennymi środowiskowymi pobieranymi z Secrets Manager/Parameter Store. Buduj obrazy i przesyłaj je do ECR; generuj artefakty wtórne (taskdef.json/appspec.yaml lub spakowane szablony CloudFormation). Dlaczego: Efemeryczne, izolowane buildy, solidne zarządzanie sekretami, szybsze cykle dzięki buforowaniu oraz obsługa wielu formatów wyjściowych wspierająca zarówno kontenery, jak i pakiety serverless.

Orkiestracja potoków

Utwórz scentralizowany CodePipeline na koncie narzędziowym z etapami: Source, Build, Unit Tests, Deploy-to-Staging, Automated Tests, Manual Approval, Deploy-to-Prod. Wyzwalacze pochodzą z EventBridge w odpowiedzi na aktualizacje w CodeCommit; zaplanowana na co noc reguła EventBridge uruchamia testy integracyjne. Dlaczego: Ustrukturyzowany, audytowalny przepływ z bramkami akceptacji oraz wykonaniami sterowanymi zarówno zdarzeniami, jak i harmonogramem.

Wdrożenia blue/green i canary

Usługi ECS używają wdrożeń blue/green w CodeDeploy z dwiema grupami docelowymi (target groups) i przesuwaniem ruchu typu canary; walidacja odbywa się w kroku AfterAllowTestTraffic za pomocą funkcji Lambda, która wykonuje testy kontraktowe i syntetyczne. Usługi EC2 używają wdrożeń in-place w CodeDeploy ze strategią OneAtATime lub wymianą grup ASG (blue/green), jeśli pozwala na to pojemność. Funkcje Lambda są wdrażane za pomocą CodeDeploy z użyciem strategii Canary10Percent15Minutes i alarmów CloudWatch dla metryk Errors i 5xx z API Gateway. Dlaczego: Pierwszorzędne mechanizmy kontroli ruchu dla każdego środowiska uruchomieniowego i automatyczny rollback w przypadku naruszenia alarmów minimalizują wpływ na klienta.

Promocja między kontami i regionami

Potok przyjmuje role specyficzne dla środowiska na kontach dev/test/prod. Dla regionów us-east-1 i eu-west-1 skonfiguruj regionalne magazyny artefaktów i regionalne klucze KMS; CodeBuild tworzy spakowane szablony specyficzne dla regionu i przesyła artefakty do lokalnych bucketów. Akcje CloudFormation na każdym koncie/w każdym regionie używają ról wykonawczych stosu; akcje CodeDeploy celują w aplikacje/grupy wdrożeniowe specyficzne dla danego środowiska. Dlaczego: Silna izolacja środowiska produkcyjnego, zasada najniższych uprawnień poprzez przyjmowanie ról oraz zgodne z wymogami szyfrowanie przy niskim narzucie operacyjnym.

Ład korporacyjny nad artefaktami i bezpieczeństwo

Wymuszaj użycie prywatnych bucketów S3 na artefakty z restrykcyjnymi politykami i usuń wszelkie publiczne listy ACL. Podpisuj obrazy kontenerów i szablony; przechowuj pliki SBOM jako artefakty kompilacji. Użyj kluczy warunkowych IAM (condition keys), aby ograniczyć akcje produkcyjne tylko do potoków na koncie narzędziowym. Dlaczego: Zapobiega wyciekom danych, poprawia identyfikowalność pochodzenia (provenance) i jest zgodne z najlepszymi praktykami w zakresie łańcucha dostaw.

Obserwowalność i powiadomienia

Dołącz alarmy CloudWatch do wszystkich grup wdrożeniowych; reguły EventBridge przekazują zdarzenia wykonania i zatwierdzenia z CodePipeline do tematu SNS oraz do funkcji Lambda, która publikuje powiadomienia na Slacku. Dlaczego: Szybsza informacja zwrotna, zautomatyzowane rollbacki i zatwierdzenia wymagające interwencji człowieka tam, gdzie jest to potrzebne.

Taki projekt unifikuje heterogeniczne środowiska uruchomieniowe w ramach jednego, zarządzanego zestawu narzędzi, zapewnia bezpieczne strategie wdrażania z automatyczną weryfikacją, zmniejsza koszty utrzymania poprzez eliminację infrastruktury CI/CD hostowanej we własnym zakresie i skaluje się globalnie z wyraźnym podziałem obowiązków.

Wszystkie domeny · Infrastruktura jako kod i zarządzanie konfiguracją →

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