动手实验室 — AZ-400 Microsoft Azure DevOps Engineer Expert

概述

先决条件

步骤

1. 1.Provider、资源组、命名

   标准的 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 Container Registry

   配置服务：

   • Azure Container Registry

   ACR 是 CI 流水线推送容器镜像、CD 流水线拉取容器镜像的地方。AZ-400 将这种推/拉边界作为一种安全模式进行测试：构建流水线获得 AcrPush 权限，部署目标获得 AcrPull 权限，两者永不交叉。

   我们使用基本层 — 最便宜，单一复制目标。高级层增加了异地复制和内容信任功能（镜像签名）；两者都是 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.使用托管标识 + Log Analytics 部署 AKS

   配置服务：

   • Azure Kubernetes Service

   AKS 是 AZ-400 容器工作负载的首选部署目标。我们使用系统分配的托管标识（现代默认设置；服务主体身份验证正在弃用）、一个小型系统节点池，以及 azure_policy_enabled = true（AZ-400 中通过 Azure Policy 附加组件实现集群级策略强制执行的“实施合规性”答案）。

   Log Analytics 工作区 + OMS 代理集成是 AZ-400 中用于集群级可观测性的“实施检测”答案 — 每个 Pod 日志、每个节点指标、每个 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 按名称引用密钥。

   我们授予 AKS kubelet 标识“Key Vault 密钥用户”角色，以便部署的 Pod 也能通过 Secrets Store CSI Driver（用于 Key Vault 支持的密钥的集群内挂载机制）读取密钥。有了这个角色，每个需要数据库密码的 Pod 都可以通过 CSI Driver 读取，而不是从镜像中硬编码的环境变量中读取。

   复制

   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 处理集群级信号（节点指标、Pod 日志）；App Insights 处理应用级信号（请求跟踪、异常遥测、依赖项跟踪、分布式跟踪）。AZ-400 的“实施检测”测试这两个层级 — 考试期望您将它们配对使用，其中 App Insights 作为基于工作区模式，使用第 3 步中的 Log Analytics 工作区。

   至此，AZ-400 CI/CD 目标形态已完成：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
   }

清理