Amazon SAA-C03: Kontenery i orkiestracja — Przewodnik do nauki

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Część AWS SAA-C03 — Kompletny przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Wybór między ECS a EKS oraz między EC2 a Fargate

Pierwszą decyzją architektoniczną dla każdego obciążenia kontenerowego na AWS jest wybór orkiestratora i trybu obliczeniowego. Amazon ECS to autorski orkiestrator AWS z ciasną integracją z IAM, ALB/NLB, CloudWatch, Service Discovery i sieciami VPC. Nie ma opłaty za płaszczyznę sterowania i jest najszybszą drogą do produkcji dla zespołów, które nie potrzebują narzędzi specyficznych dla Kubernetes. Taski (zadania) to jednostki składające się z jednego lub więcej kontenerów dzielących cykl życia; serwisy (usługi) to długo działające, zarządzane zestawy tasków, zarządzane przez harmonogram (scheduler). Amazon EKS uruchamia zgodną z upstream wersję Kubernetes za stałą stawkę 0,10 USD/godzinę za klaster i jest właściwym wyborem, gdy obciążenia muszą pozostać przenośne, korzystać z API Kubernetes lub wykorzystywać ekosystem CNCF (Helm, CRD, Operatory). Płaszczyzna sterowania — API server, etcd, controller manager, scheduler — jest łatana, backupowana i utrzymywana w wysokiej dostępności w trzech Strefach Dostępności (AZ) przez AWS.

Oba orkiestratory akceptują dwa tryby obliczeniowe. AWS Fargate uruchamia każdy task lub pod na izolowanych mikromaszynach wirtualnych Firecracker; nie ma obrazów AMI do łatania, dostawców pojemności (capacity providers) opartych o Auto Scaling Group do strojenia, decyzji dotyczących upakowania (bin-packing), ani hostów dostępnych przez SSH. Płaci się za vCPU-sekundę i GB-sekundę zużycia przez task. Typ uruchomienia EC2 / zarządzane grupy węzłów (managed node groups) oznacza, że jesteś właścicielem instancji, z całą elastycznością i obciążeniem operacyjnym, jakie się z tym wiążą.

Fargate jest właściwym domyślnym wyborem, gdy scenariusz kładzie nacisk na „serverless”, „minimalny narzut operacyjny” lub „brak infrastruktury do zarządzania”, pod warunkiem, że obciążenie mieści się w jego ograniczeniach: maksymalnie 16 vCPU / 120 GB pamięci na task, brak GPU, brak uprzywilejowanych kontenerów, brak DaemonSets, brak HostPort/HostNetwork, brak customizacji na poziomie hosta Windows. Wybierz zarządzane grupy węzłów lub typ uruchomienia EC2, gdy potrzebujesz GPU, DaemonSets wymagających dostępu do hosta, niestandardowych obrazów AMI, kontenerów Windows Server z GMSA, subsekundowej wydajności upakowania (bin-packing) lub agresywnej optymalizacji kosztów opartej na instancjach Spot.

Klasyczną pułapką jest wybieranie węzłów EC2, ponieważ „wydają się” tańsze. Dla obciążeń o nieregularnym lub niskim wykorzystaniu Fargate jest często tańszy, gdy weźmie się pod uwagę niewykorzystaną pojemność oraz czas inżynierów poświęcony na łatanie AMI, opróżnianie węzłów (node draining) i konfigurację autoskalera klastra — wszystko to Fargate eliminuje.

Definicje Tasków, Rozmieszczanie i Dostawcy Pojemności (Capacity Providers)

Kanoniczna definicja taska ECS Fargate zawiera kluczowe elementy — rozmiar CPU/pamięci, rolę wykonawczą (execution role) do pobierania obrazów i zapisywania logów, tryb sieciowy awsvpc oraz konfigurację logów CloudWatch:

family: checkout-service
requiresCompatibilities: [FARGATE]
networkMode: awsvpc
cpu: "1024"
memory: "2048"
executionRoleArn: arn:aws:iam::111122223333:role/ecsTaskExecutionRole
containerDefinitions:
  - name: checkout
    image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/checkout:1.4.2
    portMappings: [{ containerPort: 8080 }]
    logConfiguration:
      logDriver: awslogs
      options:
        awslogs-group: /ecs/checkout
        awslogs-region: us-east-1

W ECS z EC2, strategie rozmieszczania tasków (task placement strategies) decydują o tym, jak taski są dystrybuowane pomiędzy instancjami. Są one stosowane w następującej kolejności:

Ograniczenia rozmieszczania (placement constraints), takie jak distinctInstance lub memberOf używające języka zapytań klastra, dodatkowo zawężają kandydatów.

Dostawcy pojemności (Capacity providers) oddzielają serwisy od surowych grup Auto Scaling. FARGATE i FARGATE_SPOT to zarządzani dostawcy; niestandardowi dostawcy opakowują grupę ASG i umożliwiają zarządzane skalowanie (managed scaling), dzięki czemu ECS dostosowuje pożądaną liczbę instancji w ASG na podstawie liczby uruchomionych tasków. Strategia dostawcy pojemności dzieli taski według wagi i wartości bazowej — na przykład, gwarantując dwa taski Fargate on-demand i dzieląc resztę w stosunku 1:4 z Fargate Spot dla obciążeń tolerujących przerwania:

capacityProviderStrategy:
  - capacityProvider: FARGATE
    base: 2
    weight: 1
  - capacityProvider: FARGATE_SPOT
    weight: 4

Autoskalowanie: Pody, Taski i Węzły

Fargate eliminuje zarządzanie węzłami, ale nie skaluje automatycznie liczby tasków ani podów. To rozróżnienie jest najczęściej powtarzanym błędnym przekonaniem na temat Fargate: model serverless dotyczy warstwy hosta, a nigdy pożądanej liczby replik Twojego serwisu. Nadal jesteś odpowiedzialny za autoskalowanie na poziomie serwisu.

Dla ECS użyj Application Auto Scaling. Śledzenie celu (Target tracking) jest idiomatycznym domyślnym wyborem, ponieważ automatycznie tworzy alarmy CloudWatch dla skalowania w górę i w dół oraz respektuje okresy przejściowe (cooldowns). Rozsądnymi metrykami są ECSServiceAverageCPUUtilization, ECSServiceAverageMemoryUtilization oraz ALBRequestCountPerTarget:

aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/prod-cluster/checkout \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 --max-capacity 30

aws application-autoscaling put-scaling-policy \
  --policy-name cpu-target-50 \
  --service-namespace ecs \
  --resource-id service/prod-cluster/checkout \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration \
    '{"TargetValue":50.0,"PredefinedMetricSpecification":{"PredefinedMetricType":"ECSServiceAverageCPUUtilization"}}'

Skalowanie krokowe (Step scaling) i skalowanie harmonogramowe (scheduled scaling) pozostają dostępne dla nieliniowych krzywych odpowiedzi lub znanych okien ruchu.

Dla EKS na węzłach EC2, wymiar podów jest obsługiwany przez Horizontal Pod Autoscaler (HPA), który dostosowuje liczbę replik na podstawie użycia CPU, pamięci lub metryk niestandardowych. Sam HPA nie może dodawać węzłów — z radością podniesie liczbę replik powyżej pojemności klastra, po czym nowe pody wejdą w stan Pending ze zdarzeniami FailedScheduling. Dlatego HPA na EC2 musi być zawsze połączony z Kubernetes Cluster Autoscaler lub Karpenter. Zapomnienie o tym połączeniu jest częstym błędem projektowym: HPA raportuje „przeskalowano do 20 replik”, podczas gdy połowa z nich utknęła w stanie oczekiwania (pending). Minimalna konfiguracja Cluster Autoscaler odkrywa grupy węzłów poprzez tagi ASG:

- --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/prod-eks
- --balance-similar-node-groups
- --skip-nodes-with-system-pods=false

W przypadku profili Fargate ten problem znika — każdy pod staje się własną mikromaszyną wirtualną, więc wymiar skalowania węzłów jest całkowicie wyeliminowany. To jest dokładnie powód, dla którego Fargate jest właściwym wyborem dla nieregularnych obciążeń z nieprzewidywalną liczbą podów.

Profile Fargate i ich ograniczenia funkcjonalne

Profil Fargate w EKS to selektor — przestrzeń nazw plus opcjonalne etykiety podów — który instruuje EKS, aby planował pasujące pody na Fargate zamiast na węźle:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata: { name: microservices, region: us-east-1 }
fargateProfiles:
  - name: fp-app
    selectors:
      - namespace: app
        labels: { compute: fargate }

Kluczowym zastrzeżeniem jest to, że EKS na Fargate nie obsługuje pełnego zakresu funkcji Kubernetes:

• DaemonSets nie działają. Bez węzła, na którym można by je uruchomić, eksportery logów (log shippers) takie jak DaemonSety fluentd muszą być zastąpione przez kontenery sidecar lub wbudowany router logów Fluent Bit.
• Kontenery uprzywilejowane, HostPort i HostNetwork są niedostępne.
• Pamięć trwała jest ograniczona do EFS za pośrednictwem sterownika CSI. EBS nie jest obsługiwany, ponieważ woluminy EBS wymagają podłączenia do konkretnej instancji EC2.
• Obciążenia GPU nie są obsługiwane.
• Usługi typu NodePort oraz service meshe, które opierają się na uprzywilejowanych kontenerach init, nie działają.

Założenie o równoważności funkcji prowadzi do nieudanych migracji StatefulSetów wymagających EBS, kontrolerów ingress używających hostPort lub obciążeń związanych z inferencją na GPU.

Ingress: ALB vs NLB za pośrednictwem AWS Load Balancer Controller

AWS Load Balancer Controller to kontroler Kubernetes, który tłumaczy obiekty Ingress i Service na rzeczywiste load balancery ALB i NLB. W przypadku mikrousług HTTP/HTTPS z routingiem opartym na ścieżce lub hoście, należy utworzyć pojedynczy obiekt Ingress klasy alb. Jeden ALB obsługujący wiele usług (za pomocą alb.ingress.kubernetes.io/group.name) jest znacznie tańszy niż jeden ALB na usługę i stanowi kanoniczny, opłacalny wzorzec:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/group.name: shop
spec:
  rules:
  - http:
      paths:
      - path: /customers
        pathType: Prefix
        backend: { service: { name: customers, port: { number: 80 }}}
      - path: /orders
        pathType: Prefix
        backend: { service: { name: orders, port: { number: 80 }}}

Użyj NLB (usługa typu LoadBalancer z service.beta.kubernetes.io/aws-load-balancer-type: external i typem celu nlb-ip) dla protokołów TCP, UDP, TLS pass-through, wymagań dotyczących statycznego adresu IP lub ekstremalnej przepustowości w warstwie 4. Umieszczenie gRPC-over-HTTP/2 lub zwykłego proxy bazy danych TCP za ALB jest w porządku tylko dla gRPC (ALB obsługuje HTTP/2 i gRPC); ALB nie może terminować dowolnego ruchu TCP ani żadnego UDP. Próba obsługi ruchu z gier UDP przez ALB jest niedopasowaniem protokołów, które musi być wychwycone na etapie projektowania.

IAM na poziomie poda z IRSA

IAM Roles for Service Accounts (IRSA) to właściwy mechanizm nadawania uprawnień API AWS poszczególnym podom. Podłączanie profilu instancji węzła w celu przyznania podom dostępu do S3 jest błędne, ponieważ każdy pod na węźle dziedziczy te uprawnienia, łamiąc zasadę najmniejszych uprawnień (least privilege). IRSA działa poprzez sfederowanie dostawcy OIDC klastra z IAM: należy raz utworzyć dostawcę OIDC, a następnie utworzyć rolę IAM, której polityka zaufania (trust policy) ufa temu dostawcy dla określonego podmiotu namespace:serviceaccount.

eksctl utils associate-iam-oidc-provider --cluster prod --approve

eksctl create iamserviceaccount \
  --cluster prod --namespace payments --name orders-sa \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess \
  --approve

Konto serwisowe (service account) jest adnotowane za pomocą eks.amazonaws.com/role-arn: arn:aws:iam::...:role/orders-role, a pody, które je montują, otrzymują krótkoterminowe poświadczenia STS poprzez projected token. Pominięcie powiązania z dostawcą OIDC lub brak adnotacji po cichu powoduje powrót do roli węzła — jest to subtelna regresja bezpieczeństwa, którą łatwo przeoczyć podczas przeglądu.

Wtyczka VPC CNI uzupełnia to, przypisując każdemu podowi routowalny adres ENI/IP w podsieci VPC. Pody mogą wtedy komunikować się bezpośrednio z RDS, ElastiCache lub punktami końcowymi VPC (VPC endpoints) przy użyciu grup bezpieczeństwa (security groups), a CloudTrail widzi rzeczywisty adres IP poda do celów audytu.

Pamięć trwała i efemeryczna

Wybór pamięci masowej zależy od trybu dostępu, trwałości i typu uruchomienia.

EBS (za pośrednictwem sterownika EBS CSI w EKS lub jako task-attached EBS w ECS) dostarcza woluminy blokowe ReadWriteOnce dla stanowych obciążeń z pojedynczym podem, takich jak główna instancja Postgres. EFS zapewnia pamięć masową NFS typu ReadWriteMany, która jest regionalna, wielostrefowa (multi-AZ) i może być montowana przez wiele podów jednocześnie — jest to właściwy wybór, gdy wymaganie wspomina o “wysokiej dostępności, odporności na awarie, współdzieleniu między wieloma kontenerami” lub o współdzielonych artefaktach ML. FSx for Lustre obsługuje wysokoprzepustowe obliczenia HPC; FSx for NetApp ONTAP i FSx for Windows File Server obsługują korporacyjne protokoły NFS/SMB.

Zadania (tasks) Fargate domyślnie otrzymują 20 GB pamięci efemerycznej, z możliwością konfiguracji do 200 GB za pomocą ephemeralStorage.sizeInGiB na platformie w wersji 1.4.0+. Zakładanie, że Fargate zawsze ma “dużo miejsca roboczego” (scratch space), jest pułapką: kontener dostawcy, który zapisuje 50 GB plików tymczasowych, może zmieścić się w rozszerzonej pamięci efemerycznej, ale jeśli wymaganiem jest 50 GB współdzielonej lub trwałej pamięci masowej pomiędzy restartami zadań lub pomiędzy zadaniami, pamięć efemeryczna jest złym wyborem, ponieważ jest niszczona po zatrzymaniu zadania i nigdy nie jest współdzielona. Fargate nie obsługuje EBS. Jeśli obciążenie na Fargate wymaga pamięci trwałej lub współdzielonej, EFS jest w zasadzie jedyną obsługiwaną opcją.

W przypadku ECS, EFS montuje się bezpośrednio w definicji zadania (task definition); punkty dostępowe (access points) wymuszają UID/GID POSIX i katalog główny dla każdego zadania, zapewniając bezpieczną wielodostępność (multi-tenancy) na jednym systemie plików, a autoryzacja IAM obejmuje zakres elasticfilesystem:ClientMount:

"volumes": [{
  "name": "scratch",
  "efsVolumeConfiguration": {
    "fileSystemId": "fs-0abc123",
    "transitEncryption": "ENABLED",
    "authorizationConfig": {
      "accessPointId": "fsap-0def456",
      "iam": "ENABLED"
    }
  }
}],
"containerDefinitions": [{
  "name": "app",
  "mountPoints": [{
    "sourceVolume": "scratch",
    "containerPath": "/data"
  }]
}]

W przypadku EKS, EFS podłącza się poprzez StorageClass:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata: { name: efs-sc }
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-0123456789abcdef0
  directoryPerms: "700"

Często powtarzająca się pułapka: wybór Fargate dla obciążenia stanowego z pominięciem instalacji sterownika EFS CSI i StorageClass — pody uruchamiają się, ale PersistentVolumeClaims pozostają w stanie Pending na zawsze. I odwrotnie, wybór węzłów EC2 wyłącznie w celu podłączenia EBS, gdy wymaganiem jest współdzielona pamięć masowa z wieloma zapisującymi (multi-writer), jest również błędem; wolumin EBS io2 podłączony do jednego węzła nie może być współdzielony między strefami dostępności (AZ).

Skanowanie obrazów i cykl życia w ECR

Amazon ECR oferuje dwa tryby skanowania. Skanowanie podstawowe (Basic scanning) wykorzystuje otwartą bazę danych Clair i jest uruchamiane przy operacji push (lub na żądanie) bezpłatnie. Skanowanie rozszerzone (Enhanced scanning) integruje się z Amazon Inspector, ciągle monitoruje podatności CVE zarówno w systemie operacyjnym, jak i w pakietach językowych, a wyniki raportuje do Security Hub. Dla wymagania “skanuj w poszukiwaniu CVE, skanuj nowe obrazy przy tworzeniu, jak najmniej zmian w obciążeniach”, prawidłowym działaniem jest włączenie skanowania przy push (scan on push) na poziomie repozytorium — nie jest wymagana żadna zmiana w pipeline, ponieważ zdarzenie push wyzwala skanowanie:

aws ecr put-image-scanning-configuration \
  --repository-name payments-api \
  --image-scanning-configuration scanOnPush=true

Następnie proces CI/CD wywołuje describe-image-scan-findings i przerywa budowanie (fails builds) w przypadku znalezienia podatności o poziomie CRITICAL lub HIGH. Pominięcie skanowania oznacza, że niezałatanie podatności CVE w Log4j, OpenSSL czy glibc będą działać w środowisku produkcyjnym; koszt mitygacji wynikający z braku skanowania znacznie przewyższa niemal zerowy koszt jego włączenia.

Polityki cyklu życia (Lifecycle policies) ograniczają koszty przechowywania i wymuszają higienę tagów:

{
  "rules": [{
    "rulePriority": 1,
    "selection": {
      "tagStatus": "untagged",
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 14
    },
    "action": { "type": "expire" }
  }]
}

Migracja obciążeń Kubernetes + MongoDB

Podczas migracji lift-and-shift samodzielnie hostowanego stosu Kubernetes + MongoDB do AWS, przy ograniczeniach „bez zmiany kodu aplikacji” i „minimalny narzut operacyjny”, dwie decyzje są kluczowe. Po pierwsze, warstwa obliczeniowa przenoszona jest do EKS, ponieważ kompatybilność z API Kubernetes oznacza, że manifesty i charty Helm można przenieść bez zmian; użyj profili Fargate dla usług bezstanowych, aby wyeliminować zarządzanie węzłami.

Po drugie, sama baza MongoDB nie powinna być ponownie hostowana na samodzielnie zarządzanych instancjach EC2 lub w StatefulSets — to ponownie wprowadza obciążenia operacyjne związane z kopiami zapasowymi, shardingiem, przełączaniem awaryjnym i aktualizacjami. Należy użyć Amazon DocumentDB (z kompatybilnością z MongoDB), która obsługuje protokół komunikacyjny (wire protocol) MongoDB w wersjach 3.6/4.0/5.0, dzięki czemu istniejące sterowniki i ciągi połączeń działają przy minimalnych zmianach.

Zastrzeżenie dotyczące kompatybilności ma znaczenie. DocumentDB emuluje powierzchnię API MongoDB, ale nie jest to MongoDB. Niektóre operatory agregacji, specyficzne typy indeksów, semantyka change streams oraz funkcje wprowadzone w nowszych wersjach MongoDB mogą nie działać. Prawidłowym krokiem przedmigracyjnym jest uruchomienie narzędzia do sprawdzania kompatybilności DocumentDB (compat.py) na aplikacji, aby potwierdzić, że każda operacja jest obsługiwana. Wybór DynamoDB zamiast tego wymusiłby przepisanie modelu danych; wybór RDS całkowicie zniszczyłby model dokumentowy. Obie opcje naruszają ograniczenie „bez zmiany kodu”.

Opcje hybrydowe: ECS Anywhere i EKS Anywhere

ECS Anywhere rejestruje serwery on-premises (lub maszyny wirtualne innych chmur) jako instancje zewnętrzne w klastrze ECS. Płaszczyzna sterowania pozostaje w AWS; SSM Agent i ECS Agent na instancji zewnętrznej łączą się wychodząco. Jeden potok wdrożeniowy, jedna definicja zadania i jeden zestaw ról IAM obejmują zarówno obciążenia chmurowe, jak i on-prem.

EKS Anywhere instaluje zgodną dystrybucję Kubernetes na Twoim sprzęcie (zazwyczaj vSphere lub bare metal), opcjonalnie z widocznością w konsoli AWS dzięki EKS Connector. Wybierz ECS Anywhere dla lekkich, hybrydowych rozwiązań opartych na definicjach zadań; wybierz EKS Anywhere, gdy ograniczenia regulacyjne lub opóźnienia wymagają lokalnego Kubernetes z tymi samymi narzędziami co EKS w chmurze. Obie opcje utrzymują spójność orkiestracji — fundamentalną wartością jest to, że zespoły unikają utrzymywania dwóch systemów CI/CD lub dwóch modeli myślowych.

Widoczność w wielu klastrach dzięki EKS Connector

Organizacje często operują na mieszance klastrów EKS, samodzielnie zarządzanego Kubernetes na EC2 oraz klastrów on-premises. Amazon EKS Connector rejestruje dowolny zgodny klaster Kubernetes w konsoli EKS, dając jeden scentralizowany widok (single pane of glass) na węzły, obciążenia i metadane klastra. Jest to w zasadzie lekki agent plus kanał SSM — odpowiedź o niskim narzucie na potrzebę „centralnego widoku wszystkich klastrów”. Zbudowanie równoważnej widoczności za pomocą samodzielnie hostowanego Rancher, Anthos lub niestandardowej federacji Prometheus/Grafana jest wykonalne, ale znacznie droższe operacyjnie i nie integruje się z IAM ani dostępem opartym na konsoli.

EKS Connector jest wyłącznie warstwą widoczności; nie zarządza ani nie aktualizuje zdalnego klastra, co dokładnie odpowiada założeniu „centralny widok przy najmniejszym narzucie”.

Łączenie wzorców w całość

Dla obciążenia e-commerce ze zrównoważonym obciążeniem front-endem, skonteneryzowaną warstwą pośrednią i relacyjną bazą danych, gdzie kryterium jest „jak najmniej ręcznej interwencji”, kanonicznym stosem jest ALB → ECS on Fargate → Aurora Serverless v2. Każda warstwa eliminuje zarządzanie na poziomie instancji: ALB jest w pełni zarządzany, Fargate usuwa hosty, a Aurora Serverless v2 skaluje się w jednostkach ACU bez konieczności dobierania rozmiaru instancji.

Dla platformy mikroserwisów, gdzie zespół „nie może zarządzać dodatkową infrastrukturą”, prawidłową kombinacją jest ECS lub EKS z Fargate oraz w pełni zarządzana usługa danych. Wybór typu uruchamiania EC2 lub samodzielnie zarządzanych grup węzłów jest sprzeczny z ograniczeniem, mimo że obciążenie technicznie by działało.

W przypadku migracji lift-and-shift Kubernetes + MongoDB, odpowiedź sprowadza się do EKS + DocumentDB: API Kubernetes zachowuje metody wdrożenia, DocumentDB zachowuje kompatybilność sterowników, a profile Fargate zapewniają minimalny narzut operacyjny — pod warunkiem, że wykorzystanie funkcji Kubernetes przez obciążenie i używane polecenia MongoDB mieszczą się w obsługiwanych zakresach opisanych powyżej.

← Moc obliczeniowa · Wszystkie domeny · Architektury bezserwerowe i sterowane zdarzeniami →

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

Przeglądaj Amazon →