Amazon DOP-C02: Kontenery i operacje serverless — 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.

Przegląd

Kontenery i technologie bezserwerowe zmieniają sposób, w jaki operujesz, skalujesz i wdrażasz aplikacje w AWS. Ta sekcja łączy prymitywy operacyjne w usługach Amazon ECS, AWS Fargate, Amazon EKS, Amazon ECR, AWS Lambda i Amazon API Gateway, abyś mógł projektować bezpieczne wdrożenia, egzekwować zasady zarządzania obrazami, dostosowywać współbieżność i podejmować spójne decyzje dotyczące zasobów opartych na EC2 i Fargate. Skupia się na modelach harmonogramowania zadań i podów, kontrolach stanu i mechanizmach wdrożeniowych, przenoszeniu ruchu, dystrybucji obrazów między kontami oraz funkcjach wydajnościowych, takich jak buforowanie API i provisioned concurrency w Lambda.

Amazon ECS i AWS Fargate

Definicje zadań ECS (task definitions) deklarują jeden lub więcej kontenerów oraz całą konfigurację środowiska uruchomieniowego wymaganą przez scheduler. Kluczowe elementy obejmują rezerwacje i limity CPU/pamięci, portMappings, zmienne środowiskowe i sekrety (z AWS Secrets Manager lub Systems Manager Parameter Store), parametry Linux i ulimits, logConfiguration (awslogs, firelens, itp.), rozmiar ephemeralStorage (dla Fargate, 20–200 GB) oraz woluminy (volumes, w tym EFS). Użyj roli wykonawczej zadania (task execution role) do pobierania obrazów i dla sterowników logów; użyj roli zadania (task role) do dostępu aplikacji do API AWS. healthCheck kontenera definiuje polecenie, interwał, limit czasu, liczbę prób i startPeriod. W połączeniu z dependsOn (condition=HEALTHY), kontrole stanu wymuszają kolejność uruchamiania dla kontenerów sidecar.

Usługi ECS (services) utrzymują pożądaną liczbę zadań (desired task count) i opcjonalnie rejestrują zadania w ALB/NLB. deploymentConfiguration usługi kontroluje aktualizacje stopniowe (rolling updates) za pomocą minimumHealthyPercent i maximumPercent. Mechanizm “circuit breaker” dla wdrożeń (włączony/wycofaj) może automatycznie wycofać nieudane wdrożenia, gdy zadania nie przejdą kontroli stanu. Autoskalowanie usług (service autoscaling) integruje się z Application Auto Scaling w celu śledzenia celu (target tracking) opartego na CPU/pamięci lub ALB RequestCountPerTarget. Odnajdywanie usług (service discovery) (AWS Cloud Map) i ECS Service Connect upraszczają ruch między usługami.

Typy klastrów i zasoby:

Typ uruchomienia EC2 (EC2 launch type) uruchamia zadania na samodzielnie zarządzanych instancjach EC2. Używaj grup Auto Scaling, ograniczeń/strategii umieszczania (placement constraints/strategies) oraz dowolnego networkMode (bridge/host/awsvpc). Obsługiwane są zadania typu daemon oraz specjalizowane obrazy AMI (np. Bottlerocket).
Typ uruchomienia Fargate (Fargate launch type) to bezserwerowa moc obliczeniowa dla kontenerów. Używa wyłącznie sieci awsvpc, przydzielając każdemu zadaniu własny ENI i grupę bezpieczeństwa. Brak zadań typu daemon; polegasz na kontenerach sidecar lub natywnych integracjach usług (np. FireLens). Wersje platformy warunkują dostępność funkcji (sprawdź informacje o wydaniu pod kątem wsparcia dla EFS, ephemeral storage i exec). Fargate Spot obniża koszty dla zadań, które mogą być przerywane. Wybieraj CPU/pamięć w obsługiwanych parach (np. od 0,25 vCPU/0,5–2 GB do 16 vCPU/120 GB). Uruchamiając w prywatnych podsieciach, dodaj interfejsowe punkty końcowe VPC (VPC interface endpoints) dla ECR (api i dkr), CloudWatch Logs oraz bramowy punkt końcowy S3 (S3 gateway endpoint), aby pobierać obrazy i wysyłać logi bez użycia NAT.

Fargate i EFS: zdefiniuj wolumin EFS w definicji zadania i zamontuj go z użyciem TLS; preferuj punkty dostępu EFS (EFS access points) dla zasady najmniejszych uprawnień i wymuszania tożsamości. Obsługuje to potrzeby związane z utrzymaniem stanu, takie jak współdzielone konfiguracje, wagi modeli (ML) czy pliki pośrednie, bez konieczności wbudowywania ich w obrazy.

Kontrole stanu kontenerów, aktualizacje stopniowe i wdrożenia blue/green:

Kontrole stanu odbywają się na wielu warstwach: kontenera (oparte na CMD), zadania ECS (zagregowane statusy kontenerów) oraz celu load balancera (HTTP/TCP). Dopasuj interwały i progi, aby ECS mógł płynnie zastępować niestabilne zadania, zanim ALB wyrejestruje cele.
Aktualizacje stopniowe (rolling updates) są domyślnym mechanizmem w ECS. Dostosuj minHealthy/maxPercent, aby kontrolować nagły wzrost obciążenia i bezpieczeństwo pojemności.
Wdrożenia blue/green wykorzystują CodeDeploy z ECS (deploymentController typu CODE_DEPLOY). CodeDeploy zarządza dwiema grupami docelowymi za ALB, przenosi ruch testowy do zestawu “green” (AfterAllowTestTraffic), uruchamia zautomatyzowane kontrole (np. za pomocą Lambda), a następnie przenosi ruch produkcyjny. Powiąż alarmy CloudWatch, aby wycofać wdrożenie w przypadku skoków błędów 5XX, opóźnień lub niestandardowych metryk. Ten wzorzec izoluje awarie i zapewnia szybkie wycofania z niemal zerowym czasem przestoju.

Zarządzanie obrazami za pomocą ECR:

Skanowanie: włącz scan-on-push i zastosuj rozszerzone skanowanie Amazon Inspector, aby uzyskać ciągłe pokrycie pod kątem CVE i generować SBOM. Warunkuj wdrożenia na podstawie poziomu krytyczności podatności, używając kontroli w potoku (pipeline checks).
Polityki cyklu życia (Lifecycle policies) wygaszają stare tagi obrazów według liczby/wieku i prefiksu tagu. Połącz je z niezmiennością tagów (tag immutability), aby zablokować przypadkowe nadpisania.
Szyfrowanie: użyj szyfrowania zarządzanego przez ECR lub klucza KMS zarządzanego przez klienta z odpowiednią polityką klucza.
Dostęp między kontami: dołącz polityki zasobów repozytorium (repository resource policies), aby przyznać uprawnienia do pobierania/wypychania z innych kont lub ról CI. Użyj reguł replikacji ECR (ECR replication rules), aby kopiować obrazy między regionami/kontami w celu zapewnienia lokalności i redukcji promienia rażenia (blast-radius). PrivateLink (punkty końcowe VPC) pozwala na pobieranie obrazów bez dostępu do internetu.

Modele obliczeniowe Amazon EKS

EKS oddziela zarządzaną płaszczyznę sterowania (control plane) od Twoich wyborów dotyczących płaszczyzny danych (data plane):

Zarządzane grupy węzłów (Managed node groups, MNGs) provisionują i zarządzają cyklem życia węzłów roboczych EC2. Integrują się z szablonami uruchamiania (launch templates) w celu wyboru AMI (Amazon Linux 2, Bottlerocket), typów instancji i parametrów bootstrap. MNGs obsługują aktualizacje kroczące (rolling updates) z dodatkową pojemnością (surge capacity) oraz automatycznym cordon/drain w celu minimalizacji zakłóceń. Użyj node taints/tolerations, aby kierować określone obciążenia (workloads). Połącz z Cluster Autoscaler (lub Karpenter), aby dopasować pojemność węzłów (rightsizing) w oparciu o oczekujące pody (pending pods).

Samodzielnie zarządzane węzły dają pełną kontrolę nad bootstrapem i systemem operacyjnym, ale zwiększają narzut operacyjny; są zazwyczaj zarezerwowane dla specjalnych kerneli lub niszowego sprzętu.

EKS on Fargate uruchamia pody bez konieczności zarządzania węzłami. Profile Fargate (Fargate profiles) mapują przestrzenie nazw (namespaces) i etykiety (labels) na Fargate. Każdy pod otrzymuje własny interfejs sieciowy ENI (tryb awsvpc), co upraszcza izolację sieciową. Ograniczenia obejmują brak wsparcia dla DaemonSets, brak sieci/wolumenów na poziomie hosta (host networking/volumes) oraz ograniczenia dla uprzywilejowanych obciążeń (privileged workloads). Agenci do obserwacji (np. Fluent Bit) muszą działać jako kontenery sidecar lub korzystać z zarządzanego zbierania logów. Ten model jest idealny dla obciążeń o nieregularnym, skokowym charakterze (spiky), małym zapotrzebowaniu na zasoby (small-footprint) lub wielodostępnych (multi-tenant), które korzystają z izolacji na poziomie poda i modelu płatności za pod.

Dodatki operacyjne:

VPC CNI, CoreDNS i kube-proxy to zarządzane dodatki; przypinaj wersje kompatybilne z wersją klastra i aktualizuj je w sposób przemyślany.
IAM Roles for Service Accounts (IRSA) wymusza dostęp do AWS z najniższymi uprawnieniami (least-privilege) na poziomie pojedynczego poda i zastępuje współdzielenie poświadczeń na poziomie roli węzła.
Równoważenie obciążenia (load balancing) za pomocą AWS Load Balancer Controller obsługuje ALB/NLB dla zasobów Service i Ingress; zapewnij odpowiednie reguły IAM i grup bezpieczeństwa, zwłaszcza przy jednoczesnym użyciu MNG i Fargate.
Trwała pamięć masowa (persistent storage) za pomocą sterowników CSI (EBS dla pamięci blokowej per-pod, EFS dla współdzielonego systemu plików POSIX). W przypadku Fargate, EFS jest typową opcją dla współdzielonego stanu.

Operacje i współbieżność w AWS Lambda

Pakowanie i konfiguracja:

Paczki wdrożeniowe (deployment packages) mogą być archiwami ZIP (ze środowiskiem uruchomieniowym języka) lub obrazami kontenerów do 10 GB. Archiwum ZIP jest lżejsze dla małego kodu; obrazy unifikują narzędzia z procesami budowania opartymi na kontenerach.
Warstwy (Layers) hermetyzują współdzielone biblioteki między funkcjami; utrzymuj je w minimalnej formie i wersjonuj. Funkcja może zawierać do pięciu warstw.
Wersje (Versions) to niezmienne migawki (snapshots); aliasy (aliases) to stabilne wskaźniki do wersji, które mogą mieć przypisane wagi do przesuwania ruchu (traffic shifting).
Domyślna pamięć efemeryczna (ephemeral storage) to 512 MB i można ją zwiększyć do 10 240 MB na potrzeby kompilacji, plików tymczasowych lub pamięci podręcznej dla wnioskowania ML. Wybierz architekturę x86_64 lub arm64, biorąc pod uwagę kompromis między kosztem a wydajnością. Używaj zmiennych środowiskowych do konfiguracji i integruj z Secrets Manager lub Parameter Store.

Przesuwanie ruchu i bezpieczeństwo:

Użyj CodeDeploy do wdrożeń typu canary lub liniowych (linear) z automatycznym wycofywaniem (rollback) na podstawie alarmów CloudWatch (np. błędy 5XX, opóźnienia lub niestandardowe metryki aplikacji). Alternatywnie, ustaw wagi aliasów bezpośrednio, aby uzyskać prosty routing A/B.
Stosuj logowanie strukturalne do CloudWatch Logs i twórz filtry metryk (metric filters), aby uzyskiwać metryki z wymiarami operacji/wersji/kodu bez zmiany instrumentacji metryk. Włącz X-Ray, aby uzyskać śledzenie opóźnień end-to-end.

Kontrola współbieżności:

Niezarezerwowana współbieżność (unreserved concurrency) czerpie z regionalnej puli konta. Skokowy ruch może zagłodzić (starve) inne funkcje.
Zarezerwowana współbieżność (reserved concurrency) ogranicza maksymalną współbieżność funkcji i gwarantuje dla niej pojemność, wydzielając ją z puli regionalnej; zapewnia to izolację od „hałaśliwych sąsiadów” (noisy neighbors).
Współbieżność provisionowana (provisioned concurrency) utrzymuje środowiska wykonawcze w stanie zainicjowanym dla danej wersji/aliasu, praktycznie eliminując zimne starty (cold starts) i stabilizując opóźnienia. Skaluj współbieżność provisionowaną za pomocą Application Auto Scaling w oparciu o porę dnia lub metryki.
Dławienie (throttling) występuje, gdy funkcja osiąga swój limit współbieżności; wywołania synchroniczne otrzymują błędy 429, podczas gdy wywołania asynchroniczne są ponawiane z wykładniczym czasem oczekiwania (exponential backoff) i mogą trafić do kolejki martwych listów (dead-letter queue) po skonfigurowanej liczbie prób. Dla źródeł opartych na odpytywaniu (poll-based), takich jak SQS, Lambda zwiększa współbieżność wraz z głębokością kolejki; upewnij się, że zarezerwowana/provisionowana współbieżność i przepustowość systemów docelowych (downstream) odpowiadają maksymalnej liczbie przetwarzanych wiadomości (inflight messages), aby uniknąć wzrostu zaległości (backlog).

← Bezpieczeństwo · Wszystkie domeny · Wysoka dostępność →

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