Microsoft AZ-104: Azure App Service и вычислительные ресурсы PaaS — Руководство по подготовке

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

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

Обзор

Портфель вычислительных PaaS-решений Azure сочетает в себе полностью управляемый хостинг веб-сайтов/приложений, бессерверные функции, автоматизацию рабочих процессов, контейнеры по требованию и оркестрируемые контейнеры. Для администратора успех зависит от понимания границ каждой службы, как они взаимодействуют по сети и аутентифицируются, а также как выполнять надежное развертывание и масштабирование. В этом разделе рассматриваются App Service (планы, слоты развертывания, сетевые возможности и встроенная аутентификация), Azure Functions и Logic Apps (планы, триггеры, коннекторы), Azure Container Instances и AKS (планирование, масштабирование, операционные инструменты) и изолированная среда App Service Environment.

Основы вычислений в App Service и Functions

Планы App Service определяют пул вычислительных ресурсов для Web Apps, API Apps и Function Apps, работающих на выделенном плане. Уровни имеют различные возможности и модели масштабирования:

• Free (F1) и Shared (D1) работают на общей инфраструктуре с квотами и без SLA. Они подходят только для экспериментов. Такие функции, как слоты развертывания, интеграция с VNet и автомасштабирование, недоступны.
• Basic (B) выделяет отдельные виртуальные машины в небольшом масштабе с ручным горизонтальным масштабированием. В нем отсутствуют автомасштабирование и слоты развертывания.
• Standard (S) добавляет автомасштабирование, несколько экземпляров, ежедневное резервное копирование и слоты развертывания. Это начальный уровень для производственных нагрузок, требующих промежуточной среды (staging).
• Premium (Pv2/Pv3) увеличивает производительность ЦП/памяти, ввода-вывода и лимиты функций (больше экземпляров, больше слотов), а также добавляет расширенные сетевые возможности, такие как интеграция с Private Endpoint и избыточность между зонами.
• Isolated/Isolated v2 работают внутри App Service Environment с выделенными вычислительными ресурсами для одного клиента в вашей виртуальной сети, обеспечивая строгую изоляцию и соответствие требованиям.

Масштабирование делится на вертикальное (изменение ценового уровня/размера ВМ) и горизонтальное (изменение количества экземпляров). Автомасштабирование требует уровня Standard и выше и управляется правилами Azure Monitor (на основе ЦП, памяти через метрики App Service или пользовательских метрик). Операции масштабирования выполняются для каждого плана App Service и влияют на все приложения в рамках этого плана.

Слоты развертывания предоставляют рабочие экземпляры приложения в том же плане для промежуточного развертывания изменений. Слоты доступны на уровне Standard и выше, при этом Standard поддерживает меньшее их количество, а Premium/Isolated — большее. Операция обмена (swap) организует переключение без простоя путем обмена содержимым и конфигурацией слотов, сохраняя при этом настройки слота (привязанные параметры приложения и строки подключения, которые остаются со слотом). Обмен с предварительным просмотром «прогревает» целевой слот и оценивает его работоспособность перед завершением операции. Тестирование в рабочей среде направляет процент производственного трафика на один или несколько слотов; маршрутизация является «липкой» для каждого клиента, чтобы поддерживать привязку к сеансу во время тестового периода.

Сетевые возможности App Service предлагают контролируемое исходящее и входящее подключение:

• Региональная интеграция с VNet направляет исходящий трафик в делегированную подсеть виртуальной сети в том же регионе. Это позволяет осуществлять исходящие подключения к частным конечным точкам, локальным ресурсам через VPN/ExpressRoute и конечным точкам служб. Это не изменяет поведение для входящего публичного трафика.
• Private Endpoint публикует приложение в частном порядке внутри вашей VNet, сопоставляя его внешний интерфейс с частным IP-адресом; в сочетании с ограничениями доступа это позволяет обеспечить только частный входящий трафик за пределами ASE.
• Гибридные подключения обеспечивают исходящее TCP-соединение от приложения к конкретным конечным точкам вида хост:порт в локальной среде или в других сетях через Azure Relay, не требуя изменений в правилах входящего трафика брандмауэра. Это не является универсальным туннелем VNet и не поддерживает UDP.
• Ограничения доступа оценивают упорядоченные правила разрешения/запрета для IP-адресов клиентов, тегов служб и трафика виртуальной сети (через Private Endpoints или правила VNet для нескольких клиентов). Ограничьте доступ до конкретных диапазонов, VNet или внешних интерфейсов для соответствия требованиям.

Встроенная аутентификация/авторизация («Easy Auth») размещает перед вашим приложением размещенный обработчик аутентификации, снимая с приложения задачу проверки токенов без изменения кода. Поддерживаемые поставщики включают Microsoft Entra ID (Azure AD), Microsoft Account, Google, Facebook, Twitter и универсальный OpenID Connect. Вы можете требовать входа в систему для всех запросов или передавать их приложению, устанавливать разрешенные аудитории и ограничивать доступ для конкретных клиентов (tenants). Дополнительное хранилище токенов кэширует токены поставщиков и предоставляет утверждения (claims) через конечную точку /.auth/me и заголовки запросов. Используйте в сочетании с управляемым удостоверением, назначаемым системой, для безопасного вызова других служб Azure.

Azure Functions предлагает управляемые событиями вычисления в трех моделях хостинга:

• План потребления (Consumption) является бессерверным, с оплатой за каждое выполнение и за гигабайт-секунду, с автоматическим горизонтальным масштабированием и масштабированием до нуля. Для него характерны холодные запуски, и исторически для некоторых триггеров отсутствовала интеграция с VNet; новые возможности шире, но для нагрузок, чувствительных к сети, следует проверять поддержку.
• План Premium устраняет холодные запуски за счет предварительно «прогретых» экземпляров, поддерживает интеграцию с VNet и Private Endpoints, а также масштабируется на основе событий с контролем минимального/максимального количества экземпляров.
• Выделенный план (App Service Plan) запускает функции на мощностях вашего плана App Service; стоимость определяется зарезервированными экземплярами независимо от их использования, с возможностью автомасштабирования на уровне плана. Триггеры функций включают HTTP, таймер, хранилище (очередь/BLOB/таблица), Service Bus, Event Hubs, Event Grid, Cosmos DB и другие, с входными/выходными привязками для декларативного подключения служб. Durable Functions добавляют оркестрацию с отслеживанием состояния в модели code-first с использованием функций-оркестраторов и функций-действий, что позволяет реализовывать такие шаблоны, как веерное распределение/сбор (fan-out/fan-in), асинхронные HTTP-запросы, взаимодействие с человеком и саги. Состояние сохраняется в поставщике хранилища (часто используется Azure Storage), обеспечивая отказоустойчивые, воспроизводимые рабочие процессы.

Стоимость и поведение масштабирования существенно различаются между моделями App Service Plan и Consumption. В App Service Plan плата взимается за размер и количество постоянно работающих экземпляров, а масштабирование происходит по правилам плана. Модель потребления (Consumption) для Functions взимает плату только за время выполнения и память, с автоматическим масштабированием на основе параллелизма и масштабированием до нуля. План Premium находится между ними, сочетая зарезервированные «теплые» мощности с возможностью пикового масштабирования.

Контейнеры и Kubernetes

Azure Container Instances (ACI) предоставляет контейнеры по требованию с посекундной тарификацией без необходимости управлять виртуальными машинами или оркестраторами. Единицей развертывания является группа контейнеров: один или несколько контейнеров, запланированных на одном хосте, которые совместно используют IP-адрес, порты, тома и жизненный цикл. Определите CPU/память для каждого контейнера, откройте порты и подключите тома, такие как Azure Files, секреты и emptyDir. Переменные окружения могут быть обычными или защищенными (исключаются из журналов и метаданных). Политики перезапуска управляют жизненным циклом: Always (по умолчанию для долго работающих служб), OnFailure (для заданий, которые должны повторяться при ненулевом коде завершения) и Never (для задач, выполняемых до завершения, когда требуется проверить состояние выхода без перезапусков). Сетевые возможности поддерживают публичные IP-адреса, частные IP-адреса с внедрением в VNet в делегированную подсеть и метки DNS-имен для публичных конечных точек.

Azure Kubernetes Service (AKS) — это управляемый уровень управления Kubernetes с пулами узлов, развернутыми как Virtual Machine Scale Sets. Пулы узлов разделяют системные рабочие нагрузки (компоненты kube-system) и пользовательские рабочие нагрузки, поддерживают несколько размеров ВМ и могут запускать Linux и Windows (для Windows требуется как минимум один системный пул Linux). Пулы могут иметь taints для управления планированием подов. Обновления организуются для каждого пула отдельно, а maxPods, зоны доступности и эфемерные диски ОС настраиваются при создании пула. Cluster autoscaler интегрируется с планировщиком Kubernetes для изменения количества узлов в пределах min/max, когда ожидающие поды не могут быть запланированы или узлы недостаточно загружены; он учитывает Pod Disruption Budgets и уменьшает масштаб только тогда, когда это безопасно. Horizontal Pod Autoscaler дополняет это, масштабируя реплики внутри Deployment на основе метрик.

Основы kubectl для администрирования кластера:

• Подключитесь с помощью

undefined

для слияния kubeconfig и выбора контекста.

• Проверьте ресурсы:

undefined

;

undefined

для получения подробной информации и событий.

• Диагностируйте и взаимодействуйте:

undefined

для stdout/stderr,

undefined

для интерактивного устранения неполадок.

• Примените желаемое состояние:

undefined

; используйте пространства имен для разграничения ресурсов;

undefined

для переключения пространств имен.

Сетевые плагины (Azure CNI или kubenet), идентификация (управляемое удостоверение или service principal) и интеграция с RBAC/Entra ID определяют распределение IP-адресов для подов, аутентификацию и авторизацию в кластере. Убедитесь, что удостоверение кластера имеет разрешения для балансировщиков нагрузки, управляемых дисков и групп ресурсов узлов.

Интеграция, сети и безопасность

Logic Apps предоставляет управляемый механизм рабочих процессов с коннекторами к сотням SaaS и сервисов Azure. Рабочий процесс состоит из триггера, который запускает выполнение, и действий, которые выполняют шаги. Триггеры включают HTTP-запросы, Recurrence (повторение), сообщения Service Bus, события Event Grid, события Storage и многие события SaaS (например, при создании записи в Dynamics 365). Действия включают управляющие конструкции (условия, циклы, switch), операции с данными (compose, parse JSON, переменные) и операции коннекторов (отправить email, поставить сообщение в очередь, вызвать API). Интеграция с сервисами Azure глубока:

• Service Bus и Event Grid обеспечивают надежную передачу сообщений и событий для слабосвязанных архитектур.
• Functions могут вызываться для выполнения шагов с пользовательским кодом (синхронно по HTTP или асинхронно через очереди).
• Управляемое удостоверение обеспечивает безопасный доступ к Key Vault, Storage, SQL и другим ресурсам Azure без использования секретов. Logic Apps Consumption (многопользовательский) тарифицируется за выполнение каждого действия и использование коннектора; Logic Apps Standard (однопользовательский) работает на среде выполнения Functions в плане App Service или Premium, поддерживает локальную разработку, интеграцию с VNet, частные конечные точки и более высокую пропускную способность. Integration Service Environment (ISE) в плане Consumption обеспечивает изоляцию в VNet для управляемых коннекторов, когда это необходимо.

App Service Environment (ASE) реализует уровень Isolated для App Service. Развернутый в вашей виртуальной сети, ASE предоставляет однопользовательские, выделенные вычислительные ресурсы и хранилища с полным контролем над сетью. Внешний ASE (external ASE) предоставляет публичные конечные точки для входящего трафика; внутренний балансировщик нагрузки (ILB) ASE публикует только частный VIP для строго приватного доступа. Приложения в ASE используют ценовые категории Isolated/Isolated v2. Вы платите как за саму среду (stamp fee), так и за каждый экземпляр рабочего узла. ASE выбирают, когда требования к соответствию, сетевой изоляции или масштабированию превышают возможности многопользовательского App Service. С ASE v3 развертывание и настройка сети упрощены, но основное предложение остается прежним: выделенный, приватно адресуемый App Service с вашей VNet в качестве периметра.

Управление доступом в этих службах основывается на Azure RBAC для действий с ресурсами, управляемых удостоверениях для аутентификации между службами и Conditional Access на уровне идентификации. Для контроля входящего трафика в App Service комбинируйте Private Endpoints или ILB ASE с ограничениями доступа и фронтендами с поддержкой WAF (например, Application Gateway или Azure Front Door) по мере необходимости. Для контроля исходящего трафика используйте интеграцию с VNet с NSG, таблицами маршрутизации и частными конечными точками для служб данных.

Операции по развертыванию и масштабированию

Для надежных релизов в App Service используются слоты развертывания, чтобы проверять работоспособность и прогревать кэши перед обменом (swap). Конфигурацию, которая отличается для каждой среды (например, строки подключения, флаги функций), следует помечать как «настройки слота», чтобы она не переносилась во время обмена. Используйте обмен с предварительным просмотром (swap with preview) для выполнения проверок работоспособности или обращения к специальным конечным точкам прогрева приложения; если проверка не пройдена, обмен прерывается. Во время канареечного развертывания включите маршрутизацию трафика, чтобы направить небольшой, «липкий» (sticky) процент пользователей на промежуточный слот (staging) и постепенно его увеличивать. Настройки приложения, специфичные для слота, позволяют безопасно включать и выключать бета-функции.

Автомасштабирование для App Service Plans настраивается на ресурсе плана с помощью профилей (минимальное/максимальное/стандартное количество экземпляров в зависимости от времени) и правил (пороговые значения метрик с шагом масштабирования и периодом охлаждения). Для более точного масштабирования комбинируйте метрики CPU с пользовательскими метриками (например, длина очереди). Для Functions в плане Consumption масштабирование происходит автоматически; отслеживайте параллелизм (concurrency) и настраивайте host.json для управления поведением каждого триггера (например, размеры пакетов и предварительная выборка для Service Bus). План Premium масштабирует предварительно прогретые экземпляры и экземпляры для всплесков нагрузки; согласуйте минимальное количество экземпляров с целевыми показателями задержки.

В контейнерах политики перезапуска ACI должны отражать назначение: для пакетных заданий используйте Never или OnFailure, чтобы избежать бесконечных циклов; для сервисов — Always. Используйте переменные среды для конфигурации и Azure Key Vault для секретов, внедряя их через Managed Identity и стартовый код или монтируя секреты как тома, где это уместно. В AKS включите автомасштабирование кластера (cluster autoscaler) с разумными минимальными/максимальными границами для каждого пула узлов и настройте HPA для критически важных Deployments. Заложите в бюджет запас производительности (headroom) и установите Pod Disruption Budgets для защиты доступности во время обновлений и уменьшения масштаба (scale-in). Проверяйте обновления в канареечном пуле узлов перед широким развертыванием обновлений кластера или пула.

Практический сценарий

Компания Fabrikam, Inc. использует клиентский портал и сервисы фоновой обработки. Им необходимо модернизировать инфраструктуру до PaaS, обеспечить доступ к хранилищам данных только из частной сети, поддерживать сине-зеленые развертывания и выполнять ночное контейнеризированное ETL-задание без управления виртуальными машинами.

1. Разместить портал на App Service Premium со слотами развертывания

• Создать App Service Plan уровня Premium v3 для более высокой производительности и большего количества слотов, а также развернуть Web App с промежуточным слотом (staging).
• Настроить параметры слота для значений, специфичных для среды, и включить обмен с предварительным просмотром (swap with preview) и проверками работоспособности.
• Обоснование: План Premium предлагает автомасштабирование, больше слотов, поддержку Private Endpoint и SLA, подходящий для производственного трафика. Слоты обеспечивают безопасные сине-зеленые релизы и канареечную маршрутизацию.

2. Обеспечить частный входящий и контролируемый исходящий трафик

• Включить Private Endpoint для Web App и установить ограничения доступа, чтобы запретить доступ из публичной сети.
• Настроить региональную интеграцию с VNet (Regional VNet Integration) в делегированную подсеть для исходящего доступа к частным хранилищам данных и локальной сети через ExpressRoute.
• Обоснование: Private Endpoint вместе с ограничениями гарантирует доступ только из частной сети; VNet Integration направляет исходящий трафик через периметр VNet для применения единой политики брандмауэра.

3. Реализовать фоновую обработку с помощью Azure Functions Premium

• Развернуть Function App на плане Premium с управляемым удостоверением, назначаемым системой (system-assigned managed identity), используя триггеры Service Bus и Storage для нагрузок, управляемых очередями.
• Установить минимальное количество предварительно прогретых экземпляров для устранения холодных стартов и интегрировать с той же VNet.
• Обоснование: План Premium для Functions отвечает требованиям к низкой задержке и интеграции с VNet, сохраняя при этом бессерверное масштабирование для пиковых нагрузок.

4. Оркестрировать межсервисные рабочие процессы с помощью Logic Apps Standard

• Создать рабочие процессы для координации регистрации клиентов: запуск по сообщению в Service Bus, вызов Function App, запись в Storage и уведомление через коннектор Microsoft 365.
• Использовать управляемое удостоверение для доступа к Key Vault и Storage и развернуть в том же App Service Plan, чтобы использовать интеграцию с VNet и частные конечные точки.
• Обоснование: Logic Apps обеспечивает отказоустойчивую визуальную оркестрацию и нативные коннекторы; план Standard предлагает интеграцию с VNet и производительность в однотенантной среде.

5. Выполнять ночное ETL-задание в Azure Container Instances

• Определить группу контейнеров с ETL-контейнером, смонтировать общую папку Azure Files для промежуточных данных, установить безопасные переменные среды и использовать restartPolicy: Never.
• Подключить группу к делегированной подсети VNet для частного доступа к базам данных.
• Обоснование: ACI предоставляет вычислительные ресурсы с посекундной тарификацией, ориентированные на выполнение заданий, без накладных расходов на управление кластером и интегрируется с VNet для обеспечения локальности и безопасности данных.

6. Подготовиться к использованию контейнеризированных микросервисов с помощью AKS

• Создать кластер AKS с небольшим системным пулом узлов Linux и пользовательским пулом узлов, рассчитанным на ожидаемую нагрузку, включить автомасштабирование кластера (cluster autoscaler) с границами min/max и интегрировать с Entra ID и Azure CNI для получения IP-адресов на уровне подов.
• Использовать kubectl для развертывания канареечного микросервиса и настроить HPA на основе метрик CPU и пользовательских метрик.
• Обоснование: AKS обеспечивает оркестрацию корпоративного уровня при увеличении количества сервисов; автомасштабирование и HPA приводят емкость в соответствие со спросом, а kubectl предлагает стандартные средства операционного контроля.

← Хранилище Azure · Все домены · Базы данных Azure и службы данных →

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

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