Microsoft AZ-204: Azure App Service и веб-приложения — Руководство по подготовке

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

Часть Microsoft Azure Developer Associate AZ-204 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Azure App Service — это полностью управляемая платформа для хостинга веб-приложений, REST API и серверных служб на основе HTTP, поддерживающая как код, так и контейнерные рабочие нагрузки в Windows и Linux. Она предоставляет первоклассные функции для масштабирования, рабочих процессов развертывания, аутентификации, сетевой изоляции, фоновой обработки и безопасной конфигурации. Для глубокого понимания необходимо разбираться в планах App Service и масштабировании, слотах развертывания и управлении трафиком, путях интеграции CI/CD, Easy Auth, пользовательских доменах и TLS, WebJobs, App Service Environment (ASE) и шаблонах безопасной конфигурации с использованием Key Vault.

Планы, масштабирование и слоты развертывания

План App Service определяет вычислительные ресурсы, на которых размещаются ваши приложения. Все приложения в одном плане используют общий пул виртуальных машин и конфигурацию масштабирования.

• Ценовые категории:

  • Free (F1)/Shared (D1): Только для разработки и тестирования. Без SLA. Без пользовательских TLS. Без слотов развертывания.
  • Basic (B1–B3): Выделенные ВМ, ручное горизонтальное масштабирование. Без автомасштабирования. Ограниченные функции.
  • Standard (S1–S3): Добавляются автомасштабирование и слоты развертывания. Базовый уровень для производственной среды.
  • Premium v2/v3 (P1v2/P1v3+): Более новые вычислительные ресурсы, более быстрое хранилище, расширенные сетевые функции, избыточность между зонами (на поддерживаемых SKU) и более высокий уровень масштабирования. Лучше всего подходит для корпоративных производственных сред и высокой пропускной способности.
  • Isolated (I1v2+) в ASE: Выделено для виртуальной сети клиента с сетевой изоляцией и возможностью массивного масштабирования.

• Вертикальное и горизонтальное масштабирование:

  • Вертикальное масштабирование (Scale up) переводит план на более высокий SKU для получения большего количества ЦП, памяти, более быстрых дисков или расширенных возможностей (например, Premium v3 для лучшей производительности и функций).
  • Горизонтальное масштабирование (Scale out) увеличивает количество экземпляров для горизонтального распределения нагрузки. Standard и выше поддерживают автомасштабирование с правилами на основе метрик, таких как ЦП, память (Linux), длина очереди HTTP, количество запросов, пользовательские метрики или расписания. Basic поддерживает только ручное горизонтальное масштабирование. Масштабирование применяется ко всем приложениям в рамках одного плана.

• Слоты развертывания и их переключение:

  • Категории Standard и выше поддерживают несколько слотов (например, staging и production). Слоты работают в одном плане, каждый со своим именем хоста и конфигурацией.
  • Переключение (swap) перемещает содержимое и состояние среды выполнения из исходного слота в целевой почти без простоя за счет “прогрева” целевого слота перед перенаправлением трафика. Используйте applicationInitialization (Windows) или проверки работоспособности, чтобы убедиться в готовности перед переключением. Переключение с предварительным просмотром (swap with preview) позволяет провести проверку перед завершением операции.
  • Помечайте параметры конфигурации как “привязанные к слоту” (slot settings), чтобы они сохранялись за слотом во время переключений (например, строки подключения к базам данных, секреты и конечные точки диагностики). Непомеченные параметры перемещаются вместе с кодом во время переключения.

• Маршрутизация трафика с помощью слотов:

  • Направляйте процент реального трафика на непроизводственный слот для канареечного тестирования (тестирования в рабочей среде). Файлы cookie привязывают пользователей к слоту после назначения для сохранения согласованности сеанса.

Развертывание и CI/CD: GitHub, Azure DevOps и реестры контейнеров

Центр развертывания (Deployment Center) интегрирует распространенные потоки CI/CD:

• GitHub Actions:
  • App Service может создать шаблон рабочего процесса с использованием сборки Oryx или развертывания контейнера. При отправке изменений в ветку Actions выполняет сборку и развертывание в выбранный слот. Поддерживаются матричные сборки, среды и секреты. Для контейнеров Linux рабочий процесс может собрать и отправить образ в ACR или Docker Hub, а затем запустить развертывание веб-приложения.
• Azure DevOps:
  • Конвейеры (YAML или классические) обеспечивают этапы сборки и выпуска, утверждения, проверки среды и многоэтапные шлюзы. Используйте задачи: Azure Web App, Azure Web App for Container или AzureCLI для развертываний с помощью ARM/Bicep. Группы переменных и секреты, поддерживаемые Key Vault, централизуют конфигурацию.
• Реестры контейнеров:
  • App Service for Containers извлекает образы из ACR, Docker Hub или частных реестров. Настройте непрерывное развертывание через веб-хуки ACR в приложении; отправка нового образа инициирует его извлечение и перезапуск. Закрепляйте по тегу или дайджесту. Для безопасности в производственной среде используйте дайджесты образов и канареечные слоты перед переводом в основной слот.
• Дополнительные механизмы развертывания:
  • Kudu поддерживает развертывание на основе Git-push, Zip Deploy и Run From Package для воспроизводимых сборок. Файл .deployment и пользовательские скрипты могут координировать шаги сборки до того, как сайт начнет обслуживать трафик. Для обеспечения гигиены релизов корпоративного уровня комбинируйте слоты с CI/CD для проверки работоспособности и “прогрева” перед переключением.

Безопасность, идентификация, домены и TLS

Аутентификация/авторизация App Service (Easy Auth) переносит задачи идентификации на платформу, не требуя промежуточного ПО в вашем коде.

• Поставщики:
  • Microsoft Entra ID (платформа удостоверений Майкрософт), Google, Facebook, GitHub и Twitter, а также любой поставщик, совместимый с OpenID Connect, включая Entra ID B2C. Настройте идентификаторы/секреты клиентов, издателя и разрешенные аудитории/области токенов. Выберите действие при входе (разрешить анонимный доступ или требовать аутентификацию).
• Хранилище токенов и заголовки:
  • Включите хранилище токенов для кэширования токенов доступа/обновления, полученных в процессе входа. Их можно получить через /.auth/me и обновить через /.auth/refresh. App Service вставляет утверждения пользователя в заголовки запроса (например, X-MS-CLIENT-PRINCIPAL в Base64), чтобы приложение могло определить личность без зависимостей от SDK. Используйте конечную точку выхода платформы для очистки сеансов.
• Пользовательские домены:
  • Сопоставьте записи CNAME (рекомендуется) или A/ALIAS с именем хоста приложения по умолчанию. При необходимости подтвердите владение доменом с помощью записей TXT. Привяжите пользовательское имя хоста в App Service.
• SSL/TLS сертификаты:
  • Принудительно используйте только HTTPS и установите минимальную версию TLS. Привязывайте сертификаты через SNI (несколько сертификатов на один IP) или на основе IP (выделенный IP). Загружайте частные сертификаты (PFX) для контроля сертификатов на уровне производственной среды. App Service Managed Certificate предоставляет бесплатный, автоматически обновляемый сертификат с проверкой домена для имен хостов без подстановочных знаков; его нельзя экспортировать, и он требует поддерживаемой ценовой категории. Используйте интеграцию с Key Vault для управления и автоматической ротации частных сертификатов в большом масштабе.
• Клиентские сертификаты (mTLS):
  • При необходимости можно требовать входящие клиентские сертификаты и передавать их приложению для проверки. Комбинируйте с Web Application Firewall и обратными прокси-серверами (например, Application Gateway) для сквозного шифрования TLS.

Фоновая обработка и изолированные среды

WebJobs и ASE решают задачи фоновой обработки и сетевой изоляции.

• WebJobs:
  • Непрерывные (Continuous) WebJobs постоянно работают на каждом экземпляре веб-приложения и подходят для обработки очередей или циклов событий. Для их постоянной работы требуется настройка Always On (тарифный план Standard и выше). Масштабирование соответствует количеству экземпляров в плане приложений; если требуется только один активный рабочий процесс, реализуйте в коде шаблон singleton.
  • Активируемые (Triggered) WebJobs запускаются по требованию или по расписанию (CRON через settings.job). Идеально подходят для пакетных заданий, ETL-процессов или периодического обслуживания.
  • WebJobs SDK предоставляет триггеры и привязки для Azure Storage Queues, очередей/разделов Service Bus, больших двоичных объектов (Blobs) и таймеров, используя декларативные методы функций и автоматическое создание контрольных точек. WebJob, активируемый очередью, немедленно реагирует на новые сообщения, масштабируется вместе с экземплярами приложения и использует обработку сообщений из очереди недоставленных сообщений (poison queue) для изоляции сбоев. Журналы и панели мониторинга доступны в Kudu.
• App Service Environment (ASE):
  • ASEv3 размещает планы App Service внутри вашей виртуальной сети (VNet) с использованием SKU Isolated v2, предоставляя выделенные вычислительные ресурсы, изоляцию на уровне данных и частные IP-адреса. Выберите External ASE для публичного входящего трафика или Internal Load Balancer (ILB) ASE, чтобы весь входящий трафик оставался частным в пределах VNet. При необходимости интегрируйте с частными DNS, брандмауэрами и сетевыми виртуальными устройствами (NVA)/WAF.
  • ASE обеспечивает гранулярный контроль исходящего трафика, инспекцию сети и соответствие нормативным требованиям. Он поддерживает крупномасштабный хостинг с предсказуемыми сетевыми границами и тарифицируется отдельно от экземпляров плана.

Конфигурация, строки подключения и ссылки на Key Vault

Конфигурация приложения внедряется во время выполнения и может быть привязана к конкретному слоту развертывания.

• Настройки приложения (App settings):
  • Пары «ключ-значение», доступные приложению как переменные среды. Пометьте их как настройки слота (slot settings), чтобы сохранить разные значения для каждого слота. Используйте путь проверки работоспособности (Health check path), чтобы удалять неработоспособные экземпляры из ротации во время развертывания. Изменения вызывают перезапуск приложения, если в вашем фреймворке не настроены шаблоны динамической перезагрузки.
• Строки подключения (Connection strings):
  • Управляются отдельно и предоставляются как переменные среды; приложения .NET также получают конфигурацию для конкретного поставщика. Типы включают SQLAzure, SQLServer, MySQL, PostgreSQL и Custom. При необходимости помечайте их как настройки слота, чтобы избежать обмена секретами при переключении слотов.
• Ссылки на Key Vault (Key Vault references):
  • Ссылайтесь на секреты напрямую в App Settings и Connection Strings, используя специальный синтаксис

undefined

или URI без указания версии для автоматического подхвата их ротации. Назначьте приложению управляемое удостоверение, назначенное системой или пользователем, а затем предоставьте ему разрешения на получение секрета (Get secret) в хранилище (через RBAC или политику доступа). Платформа разрешает и обновляет значения, не раскрывая секреты в конфигурации App Service. Чтобы использовать TLS-сертификаты из Key Vault, импортируйте их как сертификаты или используйте ссылки на сертификаты, поддерживаемые платформой.

Все домены · Azure Functions и бессерверные вычисления →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Microsoft →