Microsoft AZ-204: Azure App Service i aplikacje internetowe — 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 App Service to w pełni zarządzana platforma hostingowa oparta na protokole HTTP dla aplikacji internetowych, interfejsów API REST i usług backendowych, obsługująca obciążenia oparte na kodzie i kontenerach w systemach Windows i Linux. Zapewnia funkcje najwyższej klasy w zakresie skalowania, przepływów wdrożeniowych, uwierzytelniania, izolacji sieciowej, przetwarzania w tle i bezpiecznej konfiguracji. Opanowanie tematu wymaga zrozumienia planów App Service i skalowania, slotów wdrożeniowych i zarządzania ruchem, ścieżek integracji CI/CD, Easy Auth, domen niestandardowych i TLS, WebJobs, App Service Environment (ASE) oraz wzorców bezpiecznej konfiguracji z użyciem Key Vault.

Plany, skalowanie i sloty wdrożeniowe

Plan App Service definiuje zasoby obliczeniowe hostujące aplikacje. Wszystkie aplikacje w ramach jednego planu współdzielą tę samą pulę maszyn wirtualnych i konfigurację skalowania.

• Poziomy cenowe:

  • Free (F1)/Shared (D1): Tylko do celów deweloperskich i testowych. Brak umowy SLA. Brak niestandardowego TLS. Brak slotów wdrożeniowych.
  • Basic (B1–B3): Dedykowane maszyny wirtualne, ręczne skalowanie w poziomie (scale out). Brak autoskalowania. Ograniczone funkcje.
  • Standard (S1–S3): Dodaje autoskalowanie i sloty wdrożeniowe. Podstawowy poziom dla środowisk produkcyjnych.
  • Premium v2/v3 (P1v2/P1v3+): Nowsze zasoby obliczeniowe, szybsza pamięć masowa, ulepszone funkcje sieciowe, redundancja strefowa (dla obsługiwanych jednostek SKU) i wyższa skala. Najlepszy dla produkcji korporacyjnej i wysokiej przepustowości.
  • Isolated (I1v2+) w ASE: Dedykowany dla sieci wirtualnej klienta z izolacją sieciową i ogromną skalą.

• Skalowanie w górę (scale up) vs skalowanie w poziomie (scale out):

  • Skalowanie w górę przenosi plan na wyższą jednostkę SKU w celu uzyskania większej mocy procesora, pamięci, szybszych dysków lub zaawansowanych możliwości (np. Premium v3 dla lepszej wydajności i funkcji).
  • Skalowanie w poziomie zwiększa liczbę instancji w celu horyzontalnego rozłożenia obciążenia. Poziomy Standard i wyższe obsługują autoskalowanie z regułami opartymi na metrykach, takich jak użycie procesora, pamięci (Linux), długość kolejki HTTP, liczba żądań, metryki niestandardowe lub harmonogramy. Poziom Basic obsługuje tylko ręczne skalowanie w poziomie. Skalowanie dotyczy wszystkich aplikacji w ramach jednego planu.

• Sloty wdrożeniowe i zamiana slotów (slot swaps):

  • Poziomy Standard i wyższe obsługują wiele slotów (np. staging i production). Sloty działają w ramach tego samego planu, a każdy z nich ma własną nazwę hosta i konfigurację.
  • Zamiana (swap) przenosi zawartość i stan środowiska uruchomieniowego ze slotu źródłowego do docelowego z niemal zerowym czasem przestoju, dzięki rozgrzaniu środowiska docelowego przed przełączeniem ruchu. Użyj applicationInitialization (Windows) lub kontroli kondycji (health checks), aby zapewnić gotowość przed zamianą. Zamiana z podglądem (swap with preview) pozwala na walidację przed finalizacją operacji.
  • Oznacz wpisy konfiguracyjne jako ustawienia slotu (slot settings), aby pozostały przypisane do slotu podczas zamian (np. parametry połączenia z bazą danych, sekrety i punkty końcowe diagnostyki). Nieoznaczone ustawienia przenoszą się wraz z kodem podczas zamiany.

• Kierowanie ruchem za pomocą slotów:

  • Przekieruj procent ruchu produkcyjnego do slotu nieprodukcyjnego w celu testowania kanarkowego (canary testing, czyli testowania w środowisku produkcyjnym). Pliki cookie przypinają użytkowników do danego slotu po przypisaniu, aby zachować spójność sesji.

Wdrażanie i CI/CD: GitHub, Azure DevOps i rejestry kontenerów

Deployment Center integruje popularne przepływy CI/CD:

• GitHub Actions:
  • App Service może wygenerować szkielet przepływu pracy (workflow) używając kompilacji Oryx lub wdrożenia kontenera. Po wykonaniu operacji push do gałęzi, Actions kompiluje i wdraża kod do wybranego slotu. Wsparcie dla kompilacji macierzowych (matrix builds), środowisk i sekretów. W przypadku kontenerów Linux, przepływ pracy może zbudować i wypchnąć obraz do ACR lub Docker Hub, a następnie uruchomić wdrożenie aplikacji internetowej.
• Azure DevOps:
  • Pipelines (YAML lub klasyczne) zapewniają etapy kompilacji i wydania, zatwierdzenia, sprawdzanie środowiska i wieloetapowe bramki (gating). Użyj zadań: Azure Web App, Azure Web App for Container lub AzureCLI dla wdrożeń opartych na ARM/Bicep. Grupy zmiennych i sekrety wspierane przez Key Vault centralizują konfigurację.
• Rejestry kontenerów:
  • App Service for Containers pobiera obrazy z ACR, Docker Hub lub prywatnych rejestrów. Skonfiguruj ciągłe wdrażanie (continuous deployment) za pomocą webhooków ACR do aplikacji; wypchnięcie nowego obrazu wyzwala jego pobranie i ponowne uruchomienie aplikacji. Przypinaj obrazy za pomocą tagu lub skrótu (digest). Dla bezpieczeństwa produkcji, używaj skrótów obrazów i slotów kanarkowych przed promowaniem do środowiska produkcyjnego.
• Dodatkowe mechanizmy wdrażania:
  • Kudu obsługuje wdrożenia oparte na Git (push), Zip Deploy oraz Run From Package w celu zapewnienia powtarzalnych kompilacji. Plik .deployment i niestandardowe skrypty mogą koordynować kroki kompilacji, zanim witryna zacznie obsługiwać ruch. Aby zapewnić higienę wydań na poziomie korporacyjnym, połącz sloty z CI/CD w celu walidacji kontroli kondycji i rozgrzewania aplikacji przed zamianą.

Bezpieczeństwo, tożsamość, domeny i TLS

Uwierzytelnianie/autoryzacja w App Service (Easy Auth) przenosi obsługę tożsamości na platformę, nie wymagając oprogramowania pośredniczącego (middleware) w kodzie aplikacji.

• Dostawcy:
  • Microsoft Entra ID (platforma tożsamości Microsoft), Google, Facebook, GitHub i Twitter, a także dowolny dostawca zgodny z OpenID Connect, w tym Entra ID B2C. Skonfiguruj identyfikatory klienta/klucze tajne, wystawcę (issuer) oraz dozwolone grupy odbiorców/zakresy tokenów (audiences/scopes). Wybierz akcję logowania (zezwalaj na anonimowy dostęp vs wymagaj uwierzytelnienia).
• Magazyn tokenów i nagłówki:
  • Włącz magazyn tokenów (token store), aby buforować tokeny dostępu/odświeżania uzyskane podczas procesu logowania, które można pobrać przez /.auth/me i odświeżyć przez /.auth/refresh. App Service wstrzykuje oświadczenia użytkownika (claims) do nagłówków żądania (np. X-MS-CLIENT-PRINCIPAL w formacie Base64), dzięki czemu aplikacja może uzyskać tożsamość bez zależności od zestawów SDK. Użyj punktu końcowego wylogowania platformy, aby wyczyścić sesje.
• Domeny niestandardowe:
  • Zmapuj rekordy CNAME (zalecane) lub A/ALIAS na domyślną nazwę hosta aplikacji. Zweryfikuj własność domeny za pomocą rekordów TXT, jeśli jest to wymagane. Powiąż niestandardową nazwę hosta w App Service.
• Certyfikaty SSL/TLS:
  • Wymuś użycie tylko HTTPS i ustaw minimalną wersję TLS. Powiąż certyfikaty za pomocą SNI (wiele certyfikatów na jednym adresie IP) lub IP-based SSL (dedykowane IP). Prześlij prywatne certyfikaty (PFX) w celu kontroli certyfikatów na poziomie produkcyjnym. App Service Managed Certificate zapewnia bezpłatny, automatycznie odnawiany certyfikat z walidacją domeny dla nazw hostów bez symboli wieloznacznych (non-wildcard); nie można go wyeksportować i wymaga obsługiwanego poziomu cenowego. Użyj integracji z Key Vault do zarządzania i automatycznego odnawiania prywatnych certyfikatów na dużą skalę.
• Certyfikaty klienta (mTLS):
  • Opcjonalnie wymagaj przychodzących certyfikatów klienta i przekazuj je do aplikacji w celu walidacji. Połącz z Web Application Firewall i odwrotnymi serwerami proxy (np. Application Gateway), aby uzyskać kompleksowe szyfrowanie TLS (end-to-end).

Przetwarzanie w tle i izolowane środowiska

WebJobs i ASE odpowiadają na scenariusze przetwarzania w tle i izolacji sieciowej.

• WebJobs:
  • Ciągłe zadania WebJobs (Continuous WebJobs) działają nieprzerwanie na każdej instancji aplikacji internetowej, nadając się do przetwarzania kolejek lub pętli zdarzeń. Wymagają opcji Always On (w planach Standard i wyższych), aby utrzymać ich działanie. Skalowanie podąża za liczbą instancji planu aplikacji; zaimplementuj w kodzie zachowanie singleton, jeśli pożądany jest tylko jeden aktywny proces roboczy.
  • Wyzwalane zadania WebJobs (Triggered WebJobs) uruchamiane są na żądanie lub według harmonogramu (CRON przez settings.job). Idealne do zadań wsadowych, ETL lub okresowej konserwacji.
  • WebJobs SDK dostarcza wyzwalacze i powiązania dla Azure Storage Queues, kolejek/tematów Service Bus, Blobów i Timerów z deklaratywnymi metodami funkcji i automatycznym tworzeniem punktów kontrolnych. Zadanie WebJob wyzwalane przez kolejkę reaguje natychmiast na nowe wiadomości, skaluje się wraz z instancjami aplikacji i wykorzystuje obsługę kolejek z błędnymi wiadomościami (poison queue) do izolacji błędów. Logi i pulpity nawigacyjne są dostępne w Kudu.
• App Service Environment (ASE):
  • ASEv3 hostuje plany App Service wewnątrz Twojej sieci VNet z jednostkami SKU Isolated v2, zapewniając dedykowane zasoby obliczeniowe, izolację płaszczyzny danych i prywatne adresy IP. Wybierz External ASE dla publicznego ruchu przychodzącego lub Internal Load Balancer (ILB) ASE, aby cały ruch przychodzący pozostał prywatny w obrębie VNet. Integruj z prywatnym DNS, zaporami sieciowymi i urządzeniami NVA/WAF w razie potrzeby.
  • ASE pozwala na szczegółową kontrolę ruchu wychodzącego, inspekcję sieci i dostosowanie do wymogów zgodności. Obsługuje hosting na dużą skalę z przewidywalnymi granicami sieciowymi i jest rozliczany oddzielnie od instancji planu.

Konfiguracja, parametry połączenia i odwołania do Key Vault

Konfiguracja aplikacji jest wstrzykiwana w czasie działania i może być specyficzna dla gniazda (slot).

• Ustawienia aplikacji (App settings):
  • Pary klucz-wartość dostępne dla aplikacji jako zmienne środowiskowe. Oznacz jako ustawienia gniazda (slot settings), aby zachować odrębne wartości dla każdego gniazda. Wykorzystaj ścieżkę sprawdzania kondycji (Health check path), aby usuwać niezdrowe instancje z rotacji podczas wdrożeń. Zmiany powodują ponowne uruchomienie aplikacji, chyba że skonfigurowano wzorce dynamicznego przeładowywania w używanym frameworku.
• Parametry połączenia (Connection strings):
  • Zarządzane oddzielnie i udostępniane jako zmienne środowiskowe; aplikacje .NET otrzymują również konfigurację specyficzną dla dostawcy. Typy obejmują SQLAzure, SQLServer, MySQL, PostgreSQL i Custom. Oznacz jako ustawienia gniazda (slot settings) w odpowiednich przypadkach, aby uniknąć zamiany kluczy tajnych.
• Odwołania do Key Vault (Key Vault references):
  • Odwołuj się do kluczy tajnych bezpośrednio w Ustawieniach Aplikacji (App Settings) i Parametrach Połączenia (Connection Strings) używając specjalnej składni @Microsoft.KeyVault(SecretUri=https://<vault>.vault.azure.net/secrets/<name>/<version>) lub identyfikatorów URI bez wersji, aby automatycznie pobierać zmiany po rotacji. Przypisz do aplikacji tożsamość zarządzaną przypisaną przez system lub użytkownika, a następnie nadaj jej uprawnienia do pobierania kluczy tajnych (Get secret) w magazynie (przez RBAC lub zasady dostępu). Platforma rozpoznaje i odświeża wartości bez ujawniania kluczy tajnych w konfiguracji App Service. Aby używać certyfikatów TLS z Key Vault, zaimportuj je jako certyfikaty lub użyj odwołań do certyfikatów obsługiwanych przez platformę.

Wszystkie domeny · Azure Functions i przetwarzanie bezserwerowe →

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

Przeglądaj Microsoft →