Лабораторная работа — AZ-400 Microsoft Azure DevOps Engineer Expert

Обзор

Предварительные требования

Шаги

1. 1.Провайдер, группа ресурсов, именование

   Стандартное начало для Azure.

   Копировать

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       azurerm = { source = "hashicorp/azurerm", version = "~> 4.0" }
       random  = { source = "hashicorp/random",  version = "~> 3.6" }
     }
   }
   
   provider "azurerm" {
     features {
       key_vault {
         purge_soft_delete_on_destroy = true
       }
     }
   }
   
   resource "random_id" "suffix" {
     byte_length = 3
   }
   
   data "azurerm_client_config" "current" {}
   
   locals {
     tags = {
       Project   = "certlabpro-az-400"
       ManagedBy = "terraform"
     }
   }
   
   resource "azurerm_resource_group" "main" {
     name     = "certlabpro-az-400-rg"
     location = "eastus"
     tags     = local.tags
   }

2. 2.Подготовка реестра контейнеров Azure для артефактов сборки

   Создаваемые ресурсы:

   • Azure Container Registry

   ACR — это место, куда конвейер CI отправляет образы контейнеров, которые затем извлекает конвейер CD. AZ-400 проверяет эту границу push/pull как шаблон безопасности: конвейер сборки получает AcrPush, цель развертывания получает AcrPull, и эти два процесса никогда не пересекаются.

   Мы используем базовый уровень (Basic) — самый дешевый, с одной целью репликации. Уровень Premium добавляет георепликацию и функцию Content Trust (подпись образов); обе являются темами экзамена AZ-400, но слишком дороги для лабораторной работы.

   Копировать

   resource "azurerm_container_registry" "main" {
     name                = "acrcertlabpro${random_id.suffix.hex}"
     resource_group_name = azurerm_resource_group.main.name
     location            = azurerm_resource_group.main.location
     sku                 = "Basic"
     admin_enabled       = false # admin user disabled — Entra-only access
   
     tags = local.tags
   }

3. 3.Развертывание AKS с управляемым удостоверением + Log Analytics

   Создаваемые ресурсы:

   • Azure Kubernetes Service

   AKS — это предпочтительная цель развертывания AZ-400 для контейнерных рабочих нагрузок. Мы используем системно-назначенное управляемое удостоверение (современный вариант по умолчанию; аутентификация через субъект-службу устаревает), один небольшой системный пул узлов и azure_policy_enabled = true (ответ AZ-400 на тему Внедрение соответствия требованиям для применения политик на уровне кластера через надстройку Azure Policy).

   Интеграция рабочей области Log Analytics + агента OMS — это ответ AZ-400 на тему Внедрение инструментов для наблюдаемости на уровне кластера — каждый лог пода, каждая метрика узла, каждое событие аудита Kubernetes попадает в Log Analytics для запросов KQL.

   Копировать

   resource "azurerm_log_analytics_workspace" "main" {
     name                = "log-az400"
     resource_group_name = azurerm_resource_group.main.name
     location            = azurerm_resource_group.main.location
     sku                 = "PerGB2018"
     retention_in_days   = 30
   
     tags = local.tags
   }
   
   resource "azurerm_kubernetes_cluster" "main" {
     name                = "aks-az400"
     resource_group_name = azurerm_resource_group.main.name
     location            = azurerm_resource_group.main.location
     dns_prefix          = "azaks${random_id.suffix.hex}"
   
     default_node_pool {
       name       = "system"
       node_count = 1
       vm_size    = "Standard_D2s_v3"
     }
   
     identity {
       type = "SystemAssigned"
     }
   
     oms_agent {
       log_analytics_workspace_id = azurerm_log_analytics_workspace.main.id
     }
   
     azure_policy_enabled = true
   
     tags = local.tags
   }
   
   # Grant the AKS kubelet identity AcrPull on the registry from Step 2.
   # This is the AZ-400 password-less image-pull pattern.
   resource "azurerm_role_assignment" "aks_acr_pull" {
     scope                = azurerm_container_registry.main.id
     role_definition_name = "AcrPull"
     principal_id         = azurerm_kubernetes_cluster.main.kubelet_identity[0].object_id
   }

4. 4.Подключение Key Vault для секретов конвейера

   Создаваемые ресурсы:

   • Azure Key Vault

   Секреты конвейера — ключи API, учетные данные развертывания, токены сторонних сервисов — никогда не должны храниться в YAML-файлах конвейера. Домен AZ-400 Внедрение безопасности и проверка кодовых баз на соответствие тестирует этот шаблон ссылки на Key Vault в задаче конвейера: конвейеры ссылаются на секреты по имени из Key Vault во время выполнения.

   Мы предоставляем удостоверению kubelet AKS роль «Пользователь секретов Key Vault» (Key Vault Secrets User), чтобы развернутые поды также могли читать секреты через драйвер Secrets Store CSI (механизм монтирования секретов, поддерживаемых Key Vault, внутри кластера). С этой ролью каждый под, которому нужен пароль к базе данных, читает его через драйвер CSI, а не из переменной среды, встроенной в образ.

   Копировать

   resource "azurerm_key_vault" "main" {
     name                       = "kv-az400-${random_id.suffix.hex}"
     resource_group_name        = azurerm_resource_group.main.name
     location                   = azurerm_resource_group.main.location
     tenant_id                  = data.azurerm_client_config.current.tenant_id
     sku_name                   = "standard"
     enable_rbac_authorization  = true
     soft_delete_retention_days = 7
   
     tags = local.tags
   }
   
   resource "azurerm_role_assignment" "kv_admin_self" {
     scope                = azurerm_key_vault.main.id
     role_definition_name = "Key Vault Administrator"
     principal_id         = data.azurerm_client_config.current.object_id
   }
   
   resource "azurerm_role_assignment" "aks_kv_reader" {
     scope                = azurerm_key_vault.main.id
     role_definition_name = "Key Vault Secrets User"
     principal_id         = azurerm_kubernetes_cluster.main.kubelet_identity[0].object_id
   }

5. 5.Добавление Application Insights для наблюдаемости на уровне приложений

   Создаваемые ресурсы:

   • Azure Application Insights

   Log Analytics обрабатывает сигналы на уровне кластера (метрики узлов, логи подов); App Insights обрабатывает сигналы на уровне приложений (трассировка запросов, телеметрия исключений, отслеживание зависимостей, распределенные трассировки). AZ-400 Внедрение инструментов проверяет оба слоя — экзамен ожидает, что вы подключите их в паре, используя App Insights в режиме на основе рабочей области с использованием рабочей области Log Analytics из Шага 3.

   С этим последним компонентом завершена целевая конфигурация CI/CD для AZ-400: ACR получает образы сборки, AKS развертывает их, Key Vault предоставляет секреты, Log Analytics + App Insights отслеживают результат. YAML-файл конвейера (Azure DevOps или GitHub Actions) управляет всем этим — он находится в исходном репозитории, а не в Terraform.

   Копировать

   resource "azurerm_application_insights" "main" {
     name                = "appi-az400"
     resource_group_name = azurerm_resource_group.main.name
     location            = azurerm_resource_group.main.location
     workspace_id        = azurerm_log_analytics_workspace.main.id
     application_type    = "web"
   
     tags = local.tags
   }

Очистка ресурсов