Microsoft AZ-204: Rozwiązania kontenerowe Azure — Przewodnik do nauki

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Część Microsoft Azure Developer Associate AZ-204 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Azure dostarcza spektrum opcji kontenerowych, które obejmują uruchamianie pojedynczych kontenerów, orkiestrowane klastry oraz bezpieczny łańcuch dostaw obrazów klasy korporacyjnej. Azure Container Instances (ACI) to najszybsza ścieżka do uruchamiania kontenerów Linux lub Windows bez zarządzania serwerami. Azure Kubernetes Service (AKS) to zarządzana płaszczyzna sterowania Kubernetes, która skaluje mikrousługi z zaawansowanym harmonogramowaniem, sieciami, bezpieczeństwem i integracjami DevOps. Azure Container Registry (ACR) to prywatny, georeplikowany rejestr, który stanowi podstawę dla przepływów budowania, tagowania, wypychania/pobierania (push/pull) i dystrybucji Helm. Opanowanie budowy obrazów Docker i zarządzania ich cyklem życia jest fundamentalne dla niezawodnych wdrożeń na każdej z tych platform. Ta sekcja przedstawia praktyczne, zorientowane na dewelopera spojrzenie na to, jak te elementy do siebie pasują, włączając w to wdrożenia oparte na YAML, pakowanie Helm, udostępnianie usług oraz wzorce tożsamości i bezpieczeństwa.

Docker i Azure Container Registry (ACR)

Niezawodne dostarczanie kontenerów zaczyna się od solidnych podstaw Dockera. Każdy obraz składa się z warstw tworzonych przez instrukcje Dockerfile; ponowne wykorzystanie warstw i trafienia w pamięci podręcznej są kluczowe dla szybkich kompilacji.

• Typowe instrukcje Dockerfile i wskazówki:
  • FROM definiuje obraz bazowy. Preferuj minimalne obrazy (np. distroless, alpine, gdy jest to właściwe), aby zmniejszyć powierzchnię ataku i rozmiar.
  • RUN wykonuje polecenia w celu instalacji zależności. Łącz powiązane polecenia, aby zmniejszyć liczbę warstw, ale unikaj monolitycznych linii RUN, które utrudniają identyfikację błędów.
  • COPY i ADD umieszczają artefakty aplikacji. Użyj .dockerignore, aby uniknąć rozdymania kontekstu; przypinaj COPY do jawnie określonych ścieżek.
  • WORKDIR ustawia katalog roboczy; używaj go zamiast łączenia cd w instrukcjach RUN.
  • EXPOSE dokumentuje docelowe porty nasłuchujące (to nie jest zapora sieciowa).
  • ENV i ARG konfigurują zmienne środowiskowe i zmienne czasu budowy; promuj determinizm czasu budowy, ustalając domyślne wartości ARG lub przekazując jawne wartości.
  • ENTRYPOINT definiuje główny plik wykonywalny; użyj CMD dla domyślnych argumentów. Preferuj formę exec (tablica JSON), aby zachować obsługę sygnałów dla płynnego zamykania.
  • HEALTHCHECK umożliwia ocenę żywotności (liveness), aby orkiestratorzy mogli reagować.
• Wielostopniowe budowanie (multi-stage builds) oddziela etapy budowania i uruchamiania, kopiując tylko niezbędne artefakty do czystego obrazu wykonawczego, drastycznie redukując rozmiar i ślad podatności CVE. Na przykład, zbuduj za pomocą SDK, opublikuj pliki binarne, a następnie skopiuj je do bazowego obrazu wykonawczego.
• Warstwy obrazu są niezmienne (immutable) i adresowane zawartością. Zmiana kolejności instrukcji wpływa na buforowanie. Umieszczaj często zmieniające się instrukcje (np. COPY kodu źródłowego) na końcu pliku Dockerfile, aby zmaksymalizować liczbę trafień w pamięci podręcznej.

Z ACR przechowuj i dystrybuuj obrazy oraz paczki Helm prywatnie:

• Repozytoria i tagowanie: Wypychaj obrazy jako <registry>.azurecr.io/<repo>:<tag>. Preferuj tagi semantyczne lub oparte na Git (np. 1.4.0, SHA commita) i używaj niezmiennych skrótów (digest) we wdrożeniach produkcyjnych dla zapewnienia powtarzalności.
• Wypychanie i pobieranie (Pushing and pulling):
  • Uwierzytelnij się w ACR za pomocą az acr login -n <acr-name> lub docker login z tokenem Azure AD. Unikaj włączania użytkownika administracyjnego ACR w środowisku produkcyjnym.
  • Tagowanie i wypychanie: docker tag app:1.0 <acr>.azurecr.io/apps/app:1.0; docker push <acr>.azurecr.io/apps/app:1.0. Pobieraj za pomocą docker pull lub poprzez odwołania do obrazów w Kubernetes.
  • Importuj obrazy z zewnętrznych źródeł (upstream) do ACR, aby kontrolować łańcuch dostaw: az acr import -n <acr> --source docker.io/library/nginx:1.25 --image base/nginx:1.25.
• ACR Tasks: Buduj, testuj i łataj obrazy natywnie w Azure. Użyj az acr build -r <acr> -t apps/app:1.0 . do budowania na żądanie; automatyzuj aktualizacje za pomocą az acr task create, aby wyzwalać je na podstawie commitów Git lub aktualizacji obrazu bazowego, co umożliwia naprawę podatności CVE bez zmiany kodu aplikacji.
• Georeplikacja (warstwa Premium) zapewnia lokalność pobierania i odporność w wielu regionach. Konfiguruj repliki w regionach bliskich klastrom AKS, aby zmniejszyć opóźnienia pobierania i ruch wychodzący między regionami.
• Kontrola dostępu:
  • Zintegruj z Azure AD i przypisz wbudowane role, takie jak AcrPull do tożsamości kubelet w AKS, a AcrPush do potoków CI. Uprawnienia ograniczone do repozytorium są dostępne za pomocą tokenów i map zakresu (scope maps) dla szczegółowej kontroli.
  • Ogranicz dostęp sieciowy za pomocą prywatnych punktów końcowych (private endpoints), punktów końcowych usługi (service endpoints) i reguł zapory sieciowej. W środowisku produkcyjnym preferuj prywatne punkty końcowe.
  • Dołącz ACR do AKS za pomocą az aks update --attach-acr <acr>, aby uprościć przypisywanie roli AcrPull.

Azure Container Instances (ACI)

ACI uruchamia kontenery na żądanie bez zarządzania klastrem. Podstawową jednostką jest grupa kontenerów (container group), czyli współplanowany zestaw kontenerów dzielący ten sam kernel systemu operacyjnego hosta, cykl życia, adres IP i woluminy. Używaj grup kontenerów do implementacji wzorca sidecar (np. do wysyłania logów, jako proxy) lub do połączenia głównego procesu z pomocniczym.

• Grupy wielokontenerowe dzielą przestrzeń nazw sieci, umożliwiając komunikację między kontenerami przez localhost. Dzielą również zamontowane woluminy (Azure Files, emptyDir) i cykl życia, co czyni je odpowiednimi dla spójnych, jednorazowych zadań wymagających ścisłego powiązania.
• Polityki ponownego uruchamiania (restart policies) kontrolują semantykę wykonania:
  • Always: Ponownie uruchamia kontenery, gdy zakończą działanie. Najlepsza dla długo działających usług.
  • OnFailure: Ponownie uruchamia tylko w przypadku zakończenia z kodem wyjścia innym niż zero. Odpowiednia dla zadań wsadowych, które powinny ponowić próbę w przypadku niepowodzenia.
  • Never: Uruchamia kontenery jednokrotnie i nigdy ich nie restartuje, idealna dla zadań idempotentnych.
• Integracje sieciowe obejmują publiczny adres IP z etykietą DNS, prywatne adresy IP w delegowanej podsieci Azure VNet oraz bezpieczny ruch wychodzący przez NAT lub zaporę sieciową. ACI z integracją VNet (VNet-injected) umożliwia prywatny dostęp do usług (baz danych, pamięci masowej) bez publicznego wystawiania.
• Kwestie operacyjne:
  • Wstrzykuj sekrety za pomocą bezpiecznych zmiennych środowiskowych lub montuj Azure Files; dla silniejszej postawy bezpieczeństwa, pobieraj sekrety w czasie działania za pomocą tożsamości zarządzanej z Key Vault.
  • Obserwuj za pomocą az container logs i az container attach; uruchamiaj polecenia interaktywne za pomocą az container exec.
  • Rozliczenia są naliczane co sekundę za vCPU i GiB pamięci. Kontenery uruchamiają się szybko i pasują do obciążeń o charakterze impulsowym (bursty workloads), zadań pomocniczych CI, testów integracyjnych i zadań wyzwalanych przez kolejkę, gdzie narzut Kubernetes jest niepotrzebny.

Azure Kubernetes Service (AKS)

AKS zapewnia zarządzaną płaszczyznę sterowania (control plane) z pulami węzłów (node pools), automatycznym skalowaniem i zaawansowanymi opcjami sieciowymi oraz tożsamości.

Pule węzłów strukturyzują pojemność i rozmieszczenie obciążeń. Systemowe pule węzłów (system node pools) uruchamiają podstawowe usługi; użytkownika pule węzłów (user node pools) uruchamiają pody aplikacji. Używaj wielu pul do segregacji obciążeń według potrzeb CPU/Pamięci/GPU, systemu operacyjnego (Linux/Windows), rozmiaru maszyny wirtualnej i strefy dostępności. Stosuj taints/tolerations, aby chronić pule systemowe, etykiety (labels) do selekcji oraz cluster autoscaler do dodawania/usuwania węzłów na podstawie oczekujących podów. Przy wymiarowaniu uwzględnij maxPods na węzeł i gęstość podów.

Planowanie podów (pod scheduling) jest sterowane przez żądania/limity zasobów (resource requests/limits), klasy QoS (Guaranteed/Burstable/BestEffort) i ograniczenia. Używaj nodeSelector/affinity i anti-affinity, aby kierować pody do odpowiednich pul i rozkładać repliki między strefy i domeny awarii. Ograniczenia rozproszenia topologii (topology spread constraints) poprawiają równomierną dystrybucję. Dla krytycznych usług zdefiniuj PodDisruptionBudgets i PriorityClasses, aby kształtować dobrowolne zakłócenia i zachowanie preempcji. DaemonSets umieszczają agentów na każdym węźle (logowanie, monitorowanie), a CronJobs planują uruchamianie kontenerów dla zadań okresowych.

Wdrożenia w AKS są deklaratywne. Manifesty YAML definiują apiVersion, kind, metadata i spec dla zasobów takich jak Deployments, StatefulSets, Jobs, Services i Ingress. Przechowuj manifesty w kontroli wersji, parametryzuj je za pomocą nakładek Kustomize dla różnic między środowiskami i aplikuj za pomocą kubectl apply -f. Server-side apply oraz odpowiednie etykiety/adnotacje (labels/annotations) pomagają w zarządzaniu własnością i wykrywaniu dryfu konfiguracji. Do pakowania aplikacji wielokrotnego użytku, Helm 3 grupuje szablony i wartości. Hostuj paczki Helm (charts) jako artefakty OCI w ACR i instaluj za pomocą helm upgrade –install <release> oci://<acr>.azurecr.io/helm/<chart> -f values.yaml. Używaj plików values dla każdego środowiska, śledź wersje paczek i wycofuj zmiany za pomocą helm rollback w celu szybkiego odzyskiwania.

Polecenia kubectl, których będziesz używać na co dzień:

• Dostęp do kontekstu klastra: az aks get-credentials -g <rg> -n <cluster> scala plik kubeconfig; używanie maszyny przyłączonej do Azure AD z kubectl jest wystarczające — Docker nie jest wymagany do wdrażania manifestów.
• Inspekcja i operacje: kubectl get nodes,pods,deploy,svc -A; kubectl describe pod <name>; kubectl logs -f <pod>; kubectl exec -it <pod> – sh; kubectl rollout status deploy/<name>; kubectl set image deploy/<name> container=<image>:<tag>; kubectl top pods; kubectl cordon/drain nodes w celu konserwacji; kubectl auth can-i do weryfikacji RBAC.
• Aplikowanie/patchowanie: kubectl apply -f k8s/; kubectl patch deploy <name> –type merge -p ‘{…}’.

Sieć w AKS eksponuje pody i usługi z jasno określonymi obowiązkami:

• ClusterIP zapewnia wewnętrzne, ograniczone do klastra wirtualne adresy IP i DNS do odnajdywania usług. Jest to domyślne rozwiązanie dla ruchu wschód-zachód (east-west) między mikrousługami.
• NodePort otwiera ten sam port na każdym węźle; najlepiej używać go za Ingress lub zewnętrznym LB, a nie bezpośrednio.
• LoadBalancer provisionuje frontend Azure Load Balancer, który kieruje ruch do NodePorts. Oznacz usługi jako wewnętrzne, dodając adnotację service.beta.kubernetes.io/azure-load-balancer-internal: “true”, lub przypisz statyczny publiczny adres IP dla stabilnego DNS.
• Kontrolery Ingress zapewniają routing L7, terminację TLS oraz reguły oparte na ścieżce/hoście. NGINX Ingress Controller to wszechstronne, domyślne rozwiązanie z bogatym zestawem adnotacji. Application Gateway Ingress Controller (AGIC) integruje się z Azure Application Gateway, zapewniając WAF, automatyczne skalowanie i zaawansowane funkcje L7, zachowując jednocześnie natywne manifesty Kubernetes. Użyj cert-manager do automatyzacji TLS z ACME lub synchronizuj certyfikaty z Key Vault do sekretów Kubernetes za pomocą CSI Secret Store.

Tożsamość i autoryzacja integrują Azure AD bez przechowywania poświadczeń w klastrze:

• Tożsamości zarządzane dla AKS składają się z tożsamości klastra/płaszczyzny sterowania oraz tożsamości kubelet. Nadaj kubelet uprawnienie AcrPull do ACR (az aks update –attach-acr <acr>), aby węzły mogły bezpiecznie pobierać obrazy.
• Workload identity umożliwia podom dostęp do zasobów Azure przy użyciu sfederowanych poświadczeń Azure AD mapowanych na konta usług Kubernetes — bez poświadczeń na poziomie węzła czy kontenerów sidecar. Włącz OIDC issuer na klastrze, utwórz tożsamość zarządzaną przypisaną przez użytkownika, skonfiguruj FederatedIdentityCredential dla konta usługi/przestrzeni nazw i użyj Azure Identity SDK w aplikacji. Zastępuje to starszy model AAD Pod Identity i jest zgodne z otwartymi standardami.
• RBAC zarządza uprawnieniami do API Kubernetes. Powiąż Kubernetes Roles/ClusterRoles z użytkownikami lub grupami Azure AD za pomocą RoleBindings/ClusterRoleBindings, gdy AKS jest zintegrowany z Azure AD. Alternatywnie, włącz Azure RBAC for Kubernetes Authorization, aby zarządzać dostępem za pomocą ról Azure RBAC, takich jak Azure Kubernetes Service RBAC Reader, Writer i Admin. Stosuj zasadę najmniejszych uprawnień, oddzielaj przestrzenie nazw według zespołów lub obciążeń i ograniczaj dostęp do produkcji poprzez powiązania oparte na grupach.

Pełny przepływ obrazu do AKS jest prosty i bezpieczny. Buduj obrazy wieloetapowe (multi-stage), taguj je niezmiennymi wersjami, wypychaj do ACR i wdrażaj w AKS za pomocą manifestów lub Helm. AKS pobiera obrazy z ACR, używając tożsamości zarządzanej kubelet, a pody korzystają z zasobów Azure za pośrednictwem workload identity. Usługi są eksponowane przez ClusterIP/LoadBalancer i dopracowywane za pomocą kontrolera ingress, który centralizuje TLS i routing.

Praktyczny scenariusz problemowy

Zespół Creative Cloud w Adobe dekomponuje monolityczną usługę przetwarzania mediów na mikrousługi, dążąc do niskich opóźnień w globalnym dostarczaniu i wzmocnionego łańcucha dostaw.

1. Budowanie i przechowywanie obrazów przy użyciu wieloetapowych plików Dockerfile w CI

• Użyj wieloetapowego budowania Docker (multi-stage), aby skompilować kodeki multimedialne i skopiować tylko binarne pliki wykonawcze do minimalistycznego obrazu bazowego, minimalizując rozmiar i liczbę CVE. Wypychaj obrazy jako <acr>.azurecr.io/processing/encoder:<git-sha> do ACR. Zapewnia to powtarzalne, bezpieczne artefakty z niezmiennymi skrótami (digests) do przypinania wdrożeń.

2. Wzmocnienie bezpieczeństwa rejestru i automatyzacja łatania

• Utwórz rejestr ACR Premium z prywatnymi punktami końcowymi (private endpoints) w każdej sieci wirtualnej, w której znajduje się AKS. Włącz replikację geograficzną (geo-replication) do regionów North Europe i East US, aby pobieranie obrazów odbywało się lokalnie. Skonfiguruj ACR Tasks, aby uruchamiały ponowne budowanie obrazów po aktualizacji nadrzędnych obrazów bazowych, automatycznie propagując załatane warstwy. Równoważy to wydajność z bezpieczeństwem i redukuje ruch wychodzący (egress).

3. Uruchomienie AKS z oddzielnymi pulami węzłów i tożsamością

• Wdróż AKS z Azure CNI oraz systemowymi/użytkownika pulami węzłów: mała pula systemowa dla dodatków płaszczyzny sterowania, pule użytkownika z obsługą GPU do transkodowania oraz pule ogólnego przeznaczenia dla API. Włącz integrację z Azure AD, OIDC issuer i workload identity. Przypisz uprawnienie AcrPull do tożsamości kubelet za pomocą az aks update –attach-acr. Izoluje to obciążenia, umożliwia efektywne skalowanie i eliminuje pobieranie obrazów oparte na sekretach.

4. Zdefiniowanie deklaratywnych wdrożeń i pakowania

• Stwórz pliki Kubernetes YAML dla Deployments, StatefulSets (tam, gdzie wymagana jest persystencja), Services, HorizontalPodAutoscaler i PodDisruptionBudgets. Spakuj usługę enkodera i bramę API jako paczki Helm, opublikuj je jako artefakty OCI w ACR i wdrażaj za pomocą helm upgrade –install, używając wartości specyficznych dla danego środowiska. Zapewnia to spójne, wersjonowane wydania i proste wycofywanie zmian.

5. Eksponowanie usług i egzekwowanie bezpieczeństwa na poziomie L7

• Użyj ClusterIP dla wewnętrznych mikrousług i usługi typu LoadBalancer z Application Gateway Ingress Controller dla publicznych API. Terminuj TLS na Application Gateway z polityką WAF, zarządzaj certyfikatami za pomocą cert-manager zintegrowanego z Azure DNS dla wyzwań ACME i kieruj ruch do backendów według hosta/ścieżki. Daje to bezpieczeństwo L7 klasy korporacyjnej z konfiguracją natywną dla Kubernetes.

6. Implementacja bezpiecznego dostępu obciążeń do zasobów Azure

• Dla usługi tworzącej miniatury, która zapisuje dane w Blob Storage i odczytuje sekrety, utwórz tożsamość zarządzaną przypisaną przez użytkownika, sfederuj ją z kontem usługi poprzez workload identity i nadaj role Storage Blob Data Contributor oraz Key Vault Secrets User. Pod uwierzytelnia się w Azure AD, eliminując montowanie sekretów i umożliwiając szczegółowy, audytowalny dostęp.

7. Obsługa nadmiarowych zadań wsadowych za pomocą ACI

• W przypadku sporadycznych, wysoko priorytetowych nadmiarowych zadań wsadowych, uruchamiaj grupy wielokontenerowe ACI (enkoder + kolektor metryk w sidecar) z restartPolicy: Never w podsieci z wstrzykniętą siecią wirtualną (VNet-injected). Absorbuje to skoki obciążenia bez konieczności skalowania AKS do szczytowego zapotrzebowania i zachowuje prywatne ścieżki danych do kont magazynu.

Każdy wybór bezpośrednio wspiera cele Adobe: ACR Premium z replikacją geograficzną i prywatnymi punktami końcowymi zabezpiecza i przyspiesza pobieranie obrazów; AKS ze specjalizowanymi pulami węzłów i workload identity wymusza izolację i dostęp na zasadzie najmniejszych uprawnień; Helm i deklaratywny YAML standaryzują wdrożenia i wycofywanie zmian; AGIC z WAF dostarcza odporny i bezpieczny ingress L7; a ACI obsługuje nagłe wzrosty przetwarzania wsadowego bez stałych kosztów klastra.

← Azure Cosmos DB · Wszystkie domeny · Uwierzytelnianie →

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

Przeglądaj Microsoft →