Microsoft AZ-104: Azure App Service i usługi obliczeniowe PaaS — Przewodnik do nauki

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

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

Przegląd

Portfolio usług obliczeniowych PaaS na platformie Azure łączy w pełni zarządzany hosting aplikacji internetowych i mobilnych, funkcje bezserwerowe, automatyzację przepływów pracy, kontenery na żądanie oraz orkiestrowane kontenery. Jako administrator, sukces zależy od zrozumienia granic każdej z usług, sposobu ich komunikacji sieciowej i uwierzytelniania oraz metod niezawodnego wdrażania i skalowania. Ta sekcja omawia App Service (plany, miejsca wdrożenia, sieć i wbudowane uwierzytelnianie), Azure Functions i Logic Apps (plany, wyzwalacze, konektory), Azure Container Instances i AKS (planowanie, skalowanie, narzędzia operacyjne) oraz izolowane środowisko App Service Environment.

Podstawy obliczeniowe App Service i Functions

Plany App Service Plan określają pulę zasobów obliczeniowych dla Web Apps, API Apps i Function Apps działających w planie dedykowanym. Warstwy (tiers) mają odrębne możliwości i modele skalowania:

Free (F1) i Shared (D1) działają na współdzielonej infrastrukturze z limitami (quotas) i bez umowy SLA. Nadają się tylko do eksperymentów. Funkcje takie jak miejsca wdrożenia, integracja z VNet i automatyczne skalowanie nie są dostępne.
Basic (B) przydziela dedykowane maszyny wirtualne na małą skalę z ręcznym skalowaniem w poziomie (scale-out). Brakuje w nim automatycznego skalowania i miejsc wdrożenia.
Standard (S) wprowadza automatyczne skalowanie, wiele instancji, codzienne kopie zapasowe i miejsca wdrożenia. Jest to punkt wyjścia dla obciążeń produkcyjnych wymagających środowiska przejściowego (staging).
Premium (Pv2/Pv3) zwiększa wydajność procesora/pamięci, operacji I/O oraz limity funkcji (więcej instancji, więcej miejsc wdrożenia), a także dodaje zaawansowane funkcje sieciowe, takie jak integracja z Private Endpoint i redundancja strefowa.
Isolated/Isolated v2 działają wewnątrz App Service Environment z dedykowanymi zasobami obliczeniowymi dla jednego dzierżawcy (single-tenant) w Twojej sieci wirtualnej, zapewniając ścisłą izolację i zgodność z przepisami.

Skalowanie dzieli się na skalowanie w górę (scale-up; zmiana warstwy cenowej/rozmiaru maszyny wirtualnej) i skalowanie w poziomie (scale-out; zmiana liczby instancji). Automatyczne skalowanie wymaga warstwy Standard lub wyższej i jest sterowane przez reguły Azure Monitor (CPU, pamięć za pośrednictwem metryk App Service lub metryki niestandardowe). Operacje skalowania odbywają się na poziomie planu App Service Plan i wpływają na wszystkie aplikacje w ramach tego planu.

Miejsca wdrożenia (deployment slots) zapewniają działające instancje aplikacji w tym samym planie w celu przygotowania zmian (staging). Miejsca wdrożenia są dostępne w warstwie Standard i wyższych, przy czym Standard obsługuje ich mniej, a Premium/Isolated więcej. Operacja zamiany (swap) orkiestruje promocję do środowiska produkcyjnego bez przestojów poprzez wymianę zawartości i konfiguracji miejsc, z uwzględnieniem ustawień przypisanych do miejsca (sticky app settings i parametry połączenia, które pozostają z danym miejscem). Zamiana z podglądem (Swap with preview) rozgrzewa docelowe miejsce i ocenia jego kondycję przed zakończeniem operacji. Testowanie w środowisku produkcyjnym (Testing in production) kieruje procent ruchu produkcyjnego do jednego lub więcej miejsc; routing jest przypisany na stałe do klienta (sticky), aby utrzymać powinowactwo sesji (session affinity) podczas testu.

Sieć w App Service oferuje kontrolowaną łączność wychodzącą i przychodzącą:

Regionalna integracja z VNet (Regional VNet Integration) kieruje ruch wychodzący do delegowanej podsieci w sieci wirtualnej w tym samym regionie. Umożliwia to ruch wychodzący do prywatnych punktów końcowych (private endpoints), do zasobów lokalnych przez VPN/ExpressRoute oraz do punktów końcowych usług (service endpoints). Nie zmienia to zachowania publicznego ruchu przychodzącego.
Private Endpoint publikuje aplikację prywatnie wewnątrz Twojej sieci VNet, mapując frontend aplikacji na prywatny adres IP; w połączeniu z ograniczeniami dostępu (access restrictions) wymusza wyłącznie prywatny ruch przychodzący poza środowiskiem ASE.
Połączenia hybrydowe (Hybrid Connections) zapewniają wychodzącą łączność TCP z aplikacji do określonych punktów końcowych host:port w środowisku lokalnym lub w innych sieciach za pośrednictwem Azure Relay, bez konieczności wprowadzania zmian w regułach zapory sieciowej dla ruchu przychodzącego. Nie jest to tunel VNet ogólnego przeznaczenia i nie obsługuje protokołu UDP.
Ograniczenia dostępu (Access Restrictions) oceniają uporządkowane reguły zezwalania/odmawiania dla adresów IP klientów, tagów usług (service tags) i ruchu z sieci wirtualnej (za pośrednictwem Private Endpoints lub reguł VNet dla wielu dzierżawców). Zablokuj dostęp do określonych zakresów, sieci VNet lub frontendów, aby spełnić wymagania zgodności.

Wbudowane uwierzytelnianie/autoryzacja („Easy Auth”) umieszcza przed Twoją aplikacją hostowany moduł obsługi uwierzytelniania, odciążając ją z walidacji tokenów bez konieczności zmian w kodzie. Obsługiwani dostawcy to m.in. Microsoft Entra ID (Azure AD), Microsoft Account, Google, Facebook, Twitter oraz ogólny OpenID Connect. Można wymusić logowanie dla wszystkich żądań lub przekazać je do aplikacji, ustawić dozwolone grupy odbiorców (audiences) i ograniczyć dostęp do określonych dzierżawców (tenants). Opcjonalny magazyn tokenów (token store) przechowuje tokeny dostawcy i udostępnia oświadczenia (claims) za pośrednictwem punktu końcowego /.auth/me oraz nagłówków żądania. Połącz z tożsamością zarządzaną przypisaną przez system, aby bezpiecznie wywoływać podrzędne usługi Azure.

Azure Functions oferuje przetwarzanie sterowane zdarzeniami w trzech modelach hostingu:

Plan Consumption jest bezserwerowy, z rozliczeniem za wykonanie i za GB-sekundę, z automatycznym skalowaniem w poziomie i skalowaniem do zera. Występują w nim zimne starty (cold starts), a historycznie brakowało integracji z VNet dla niektórych wyzwalaczy; nowsze możliwości są szersze, ale w przypadku obciążeń wrażliwych na sieć należy zweryfikować wsparcie.
Plan Premium eliminuje zimne starty dzięki wstępnie rozgrzanym instancjom, obsługuje integrację z VNet i Private Endpoints oraz skaluje się w oparciu o zdarzenia z kontrolą minimalnej/maksymalnej liczby instancji.
Plan Dedicated (App Service Plan) uruchamia funkcje na zasobach Twojego planu App Service Plan; koszt dotyczy zarezerwowanych instancji niezależnie od ich użycia, z opcjonalnym automatycznym skalowaniem na poziomie planu. Wyzwalacze (triggers) funkcji obejmują HTTP, Timer, Storage (Queue/Blob/Table), Service Bus, Event Hubs, Event Grid, Cosmos DB i inne, z powiązaniami wejściowymi/wyjściowymi (input/output bindings) do deklaratywnego łączenia usług. Durable Functions dodają stanową orkiestrację w modelu code-first przy użyciu funkcji orkiestratora i aktywności, umożliwiając wzorce takie jak fan-out/fan-in, asynchroniczne HTTP, interakcja z człowiekiem i sagi. Stan jest utrwalany u dostawcy magazynu (powszechnie używany jest Azure Storage), zapewniając odporne i powtarzalne przepływy pracy.

Koszt i zachowanie skalowania różnią się istotnie między modelami App Service Plan i Consumption. App Service Plan nalicza opłaty za rozmiar i liczbę zawsze włączonych instancji i skaluje się zgodnie z regułami planu. Model Functions Consumption nalicza opłaty tylko za czas wykonania i zużytą pamięć, z automatycznym skalowaniem opartym na współbieżności i skalowaniem do zera. Plan Premium plasuje się pomiędzy nimi, łącząc zarezerwowaną, rozgrzaną pojemność ze skalowaniem w trybie burst.

Kontenery i Kubernetes

Usługa Azure Container Instances (ACI) dostarcza kontenery na żądanie, rozliczane co do sekundy, bez konieczności zarządzania maszynami wirtualnymi czy orkiestratorami. Jednostką wdrożenia jest grupa kontenerów: jeden lub więcej kontenerów uruchamianych na tym samym hoście, współdzielących adres IP, porty, woluminy i cykl życia. Można zdefiniować CPU/pamięć dla każdego kontenera, udostępniać porty i montować woluminy, takie jak Azure Files, sekrety i emptyDir. Zmienne środowiskowe mogą być jawne lub bezpieczne (wykluczone z logów/powierzchni metadanych). Zasady ponownego uruchamiania kontrolują cykl życia: Always (domyślna dla długo działających usług), OnFailure (dla zadań, które powinny ponowić próbę przy zakończeniu z kodem innym niż zero) i Never (dla zadań jednorazowych, w których chcesz sprawdzić stan zakończenia bez restartów). Sieć obsługuje publiczne adresy IP, prywatne adresy IP z integracją z VNet (VNet injection) w delegowanej podsieci oraz etykiety nazw DNS dla publicznych punktów końcowych.

Azure Kubernetes Service (AKS) to zarządzana płaszczyzna sterowania Kubernetes z pulami węzłów (node pools) aprowizowanymi jako Virtual Machine Scale Sets. Pule węzłów rozróżniają obciążenia systemowe (komponenty kube-system) od obciążeń użytkownika, obsługują wiele rozmiarów maszyn wirtualnych i mogą uruchamiać systemy Linux i Windows (Windows wymaga co najmniej jednej puli systemowej z Linuksem). Pule mogą mieć ustawione „taints” (skażenia), aby kontrolować harmonogramowanie (scheduling). Aktualizacje są orkiestrowane dla każdej puli, a parametry maxPods, strefy dostępności i efemeryczne dyski systemu operacyjnego są konfigurowane podczas tworzenia puli. Cluster autoscaler integruje się z harmonogramowaniem Kubernetes, aby modyfikować liczbę węzłów w granicach min/max, gdy oczekujące pody nie mogą zostać uruchomione lub węzły są niedostatecznie wykorzystane; respektuje on Pod Disruption Budgets i skaluje w dół tylko wtedy, gdy jest to bezpieczne. Horizontal Pod Autoscaler uzupełnia to działanie, skalując liczbę replik w ramach wdrożenia (Deployment) na podstawie metryk.

Podstawy kubectl do administracji klastrem:

Połącz się za pomocą az aks get-credentials, aby scalić konfigurację kubeconfig i wybrać kontekst.
Sprawdzaj zasoby: kubectl get nodes/pods/deployments -o wide; kubectl describe dla szczegółów i zdarzeń.
Diagnozuj i wchodź w interakcje: kubectl logs dla stdout/stderr, kubectl exec -it dla interaktywnego rozwiązywania problemów.
Zastosuj pożądany stan: kubectl apply -f manifests.yml; używaj przestrzeni nazw (namespaces) do ograniczania zakresu zasobów; kubectl config set-context do przełączania przestrzeni nazw.

Wtyczki sieciowe (Azure CNI lub kubenet), tożsamość (tożsamość zarządzana vs. jednostka usługi) oraz integracja z RBAC/Entra ID determinują alokację adresów IP dla podów, uwierzytelnianie klastra i autoryzację. Upewnij się, że tożsamość klastra ma uprawnienia do modułów równoważenia obciążenia (load balancers), dysków zarządzanych i grup zasobów węzłów.

Integracja, sieć i bezpieczeństwo

Logic Apps dostarczają zarządzany silnik przepływów pracy (workflow) z konektorami do setek usług SaaS i Azure. Przepływ pracy składa się z wyzwalacza (trigger), który rozpoczyna wykonanie, oraz akcji, które wykonują poszczególne kroki. Wyzwalacze obejmują żądania HTTP, cykliczność (Recurrence), komunikaty Service Bus, zdarzenia Event Grid, zdarzenia Storage i wiele zdarzeń SaaS (np. utworzenie rekordu w Dynamics 365). Akcje obejmują konstrukcje sterujące (warunki, pętle, przełączniki), operacje na danych (compose, parse JSON, zmienne) oraz operacje konektorów (wyślij e-mail, dodaj komunikat do kolejki, wywołaj API). Integracja z usługami Azure jest głęboka:

Service Bus i Event Grid zapewniają niezawodną obsługę komunikatów i zdarzeń dla architektur rozproszonych (decoupled).
Funkcje (Functions) mogą być wywoływane w celu wykonania niestandardowych kroków kodu (synchronicznie przez HTTP lub asynchronicznie przez kolejki).
Tożsamość zarządzana (Managed identity) zabezpiecza dostęp do Key Vault, Storage, SQL i innych zasobów Azure bez użycia sekretów. Logic Apps Consumption (wielodostępny) rozlicza za wykonanie każdej akcji i użycie konektora; Logic Apps Standard (jednodostępny) działa w środowisku uruchomieniowym Functions w planie App Service lub Premium, wspiera lokalny rozwój, integrację z VNet, prywatne punkty końcowe i wyższą przepustowość. Integration Service Environment (ISE) w modelu Consumption zapewnia izolację VNet dla zarządzanych konektorów, gdy jest to wymagane.

App Service Environment (ASE) implementuje warstwę Izolowaną (Isolated) dla App Service. Wdrożone w Twojej sieci wirtualnej, ASE zapewnia jednodostępne, dedykowane zasoby obliczeniowe i magazynowe (stamps) z pełną kontrolą sieciową. Zewnętrzne ASE udostępnia publiczne punkty końcowe dla ruchu przychodzącego; wewnętrzne ASE (ILB ASE) publikuje tylko prywatny adres VIP dla ściśle prywatnego dostępu. Aplikacje w ASE korzystają z warstw cenowych Isolated/Isolated v2. Płacisz zarówno opłatę za środowisko (stamp fee), jak i za koszty poszczególnych instancji roboczych (worker). ASE jest wybierane, gdy wymagania dotyczące zgodności, izolacji sieciowej lub skali przekraczają możliwości wielodostępnego App Service. W wersji ASE v3 wdrożenie i sieć są uproszczone, ale podstawowa propozycja pozostaje niezmienna: dedykowana, prywatnie adresowalna usługa App Service z Twoją siecią VNet jako granicą bezpieczeństwa.

Zarządzanie dostępem w tych usługach opiera się na Azure RBAC dla akcji na zasobach, tożsamościach zarządzanych dla uwierzytelniania między usługami oraz dostępie warunkowym (Conditional Access) na płaszczyźnie tożsamości. Dla kontroli ruchu przychodzącego do App Service, w razie potrzeby połącz Private Endpoints lub ILB ASE z ograniczeniami dostępu i frontonami z włączonym WAF (np. Application Gateway lub Azure Front Door). Dla kontroli ruchu wychodzącego, użyj integracji z VNet z sieciowymi grupami zabezpieczeń (NSG), tabelami routingu i prywatnymi punktami końcowymi dla usług danych.

Operacje wdrażania i skalowania

Niezawodne wydania w App Service wykorzystują gniazda wdrożenia do walidacji kondycji i rozgrzewania pamięci podręcznej przed operacją zamiany. Oznacz konfigurację, która różni się w zależności od środowiska, jako „ustawienia gniazda”, aby nie była przenoszona podczas zamiany (np. parametry połączenia, flagi funkcji). Użyj zamiany z podglądem, aby uruchomić sondy kondycji lub specyficzne dla aplikacji punkty końcowe rozgrzewające; jeśli kondycja jest nieprawidłowa, przerwij zamianę. Podczas wdrożenia kanarkowego włącz kierowanie ruchem, aby skierować niewielki, lepki (sticky) procent ruchu do gniazda przejściowego (staging) i stopniowo go zwiększać. Ustawienia aplikacji specyficzne dla gniazda pozwalają bezpiecznie przełączać funkcje w wersji beta.

Autoskalowanie dla planów App Service jest konfigurowane na zasobie planu przy użyciu profili (oparte na czasie wartości min/max/domyślne) i reguł (progi metryk z krokiem skalowania i okresem schładzania). Połącz metryki CPU z metrykami niestandardowymi (np. długość kolejki), aby uzyskać dokładniejsze skalowanie. W przypadku Functions, plan Consumption skaluje się automatycznie; monitoruj współbieżność i konfiguruj plik host.json dla zachowań specyficznych dla wyzwalacza (np. rozmiary partii i pobieranie z wyprzedzeniem dla Service Bus). Plan Premium skaluje wstępnie rozgrzane instancje oraz instancje z możliwością burst; dostosuj minimalną liczbę instancji do celów związanych z opóźnieniami.

W kontenerach, zasady ponownego uruchamiania ACI powinny odzwierciedlać intencje: zadania wsadowe otrzymują Never lub OnFailure, aby uniknąć nieskończonych pętli; usługi używają Always. Używaj zmiennych środowiskowych do konfiguracji i Azure Key Vault do wpisów tajnych, wstrzykując je za pomocą tożsamości zarządzanej i kodu startowego lub montując wpisy tajne jako woluminy, gdy jest to właściwe. W AKS włącz autoskalera klastra z rozsądnymi granicami min/max dla każdej puli węzłów i skonfiguruj HPA dla krytycznych wdrożeń (Deployments). Zaplanuj budżet na dodatkową rezerwę mocy (headroom) i ustaw Pod Disruption Budgets, aby chronić dostępność podczas aktualizacji i skalowania w dół. Weryfikuj aktualizacje w kanarkowej puli węzłów przed szerokim wdrożeniem aktualizacji klastra lub puli.

Praktyczny scenariusz problemowy

Firma Fabrikam, Inc. prowadzi portal klienta i usługi przetwarzania w tle. Muszą zmodernizować swoje rozwiązania do modelu PaaS, wymusić dostęp do magazynów danych przez sieć prywatną, wspierać wdrożenia typu blue-green i uruchamiać nocny, skonteneryzowany proces ETL bez zarządzania maszynami wirtualnymi.

Hostuj portal w App Service Premium z gniazdami wdrożenia

Utwórz plan App Service w warstwie Premium v3 dla wyższej wydajności i większej liczby gniazd, a następnie wdróż aplikację Web App z gniazdem przejściowym (staging).
Skonfiguruj ustawienia gniazda dla wartości specyficznych dla środowiska i włącz zamianę z podglądem oraz sprawdzanie kondycji.
Uzasadnienie: Plan Premium oferuje autoskalowanie, więcej gniazd, wsparcie dla Private Endpoint i umowę SLA odpowiednią dla ruchu produkcyjnego. Gniazda zapewniają bezpieczne wydania blue-green i kierowanie ruchem w modelu kanarkowym.

Wymuś prywatny ruch przychodzący i kontrolowany ruch wychodzący

Włącz prywatny punkt końcowy (Private Endpoint) dla aplikacji Web App i ustaw ograniczenia dostępu, aby zablokować sieć publiczną.
Skonfiguruj regionalną integrację z siecią VNet (Regional VNet Integration) do delegowanej podsieci, aby zapewnić dostęp wychodzący do prywatnych magazynów danych i zasobów lokalnych przez ExpressRoute.
Uzasadnienie: Private Endpoint w połączeniu z ograniczeniami gwarantuje dostęp wyłącznie prywatny; integracja z VNet kieruje ruch wychodzący przez obwód sieci VNet, zapewniając spójne zasady zapory sieciowej.

Zaimplementuj przetwarzanie w tle za pomocą Azure Functions Premium

Wdróż aplikację Function App w planie Premium z tożsamością zarządzaną przypisaną przez system, używając wyzwalaczy Service Bus i Storage dla obciążeń opartych na kolejkach.
Ustaw minimalną liczbę wstępnie rozgrzanych instancji, aby wyeliminować zimne starty, i zintegruj z tą samą siecią VNet.
Uzasadnienie: Plan Premium dla Functions spełnia wymagania dotyczące niskich opóźnień i integracji z VNet, zachowując jednocześnie skalowanie bezserwerowe dla nieregularnych obciążeń.

Orkiestruj przepływy pracy obejmujące wiele usług za pomocą Logic Apps Standard

Zbuduj przepływy pracy koordynujące wdrażanie klientów: wyzwalaj na podstawie wiadomości Service Bus, wywołuj aplikację Function App, zapisuj w Storage i powiadamiaj za pomocą konektora Microsoft 365.
Użyj tożsamości zarządzanej do dostępu do Key Vault i Storage oraz wdróż w tym samym planie App Service, aby wykorzystać integrację z VNet i prywatne punkty końcowe.
Uzasadnienie: Logic Apps zapewnia odporną, wizualną orkiestrację i natywne konektory; plan Standard oferuje integrację z VNet i wydajność dedykowaną dla jednego dzierżawcy.

Uruchamiaj nocny proces ETL w Azure Container Instances

Zdefiniuj grupę kontenerów z kontenerem ETL, zamontuj udział Azure Files dla danych pośrednich, ustaw bezpieczne zmienne środowiskowe i użyj restartPolicy: Never.
Podłącz grupę do delegowanej podsieci VNet, aby uzyskać prywatny dostęp do baz danych.
Uzasadnienie: ACI dostarcza moc obliczeniową z rozliczeniem sekundowym, zorientowaną na zadania, bez narzutu klastra i integruje się z VNet w celu zapewnienia lokalizacji danych i bezpieczeństwa.

Przygotuj się na skonteneryzowane mikrousługi z AKS

Utwórz klaster AKS z małą pulą węzłów systemowych Linux i pulą węzłów użytkownika o rozmiarze dostosowanym do oczekiwanego obciążenia, włącz autoskalera klastra (granice min/max) i zintegruj z Entra ID oraz Azure CNI w celu uzyskania adresów IP na poziomie poda.
Użyj kubectl, aby wdrożyć kanarkową mikrousługę i ustawić HPA w oparciu o metryki CPU i niestandardowe.
Uzasadnienie: AKS zapewnia orkiestrację klasy korporacyjnej, gdy liczba usług rośnie; autoskaler i HPA dostosowują pojemność do zapotrzebowania, a kubectl oferuje standardową kontrolę operacyjną.

← Magazyn Azure · Wszystkie domeny · Bazy danych Azure i usługi danych →

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