在企业级.NET应用程序中利用Azure DevOps与CI/CD管道进行云原生开发

基于云的原生开发模式使企业级的.NET应用程序能够在云端实现扩展并保持良好的弹性。通过使用Azure DevOps的CI/CD管道，您可以自动化应用程序的构建、测试和部署过程，将其打包成Docker容器，并在Azure Kubernetes Service（AKS）等平台上进行部署。

这种开发方式能够确保应用程序在多种环境中都能获得一致且可靠的发布结果，同时还能支持基础设施即代码、安全扫描以及可观测性等最佳实践。它能够帮助您的组织高效、安全地开发出适用于云环境的.NET软件。

在本文中，您将学习如何利用Azure DevOps、Docker和Kubernetes来为企业级的.NET应用程序实现基于云的原生CI/CD管道架构。

目录

• 先决条件

• 概述

• 基于云的原生.NET开发原则

• 了解Azure DevOps的CI/CD管道

• 为.NET应用程序创建Azure DevOps管道

• 将.NET应用程序容器化

• 在Azure DevOps中构建并发布Docker镜像

• 部署到Azure Kubernetes Service（AKS）

• 利用部署阶段管理环境

• 使用Azure DevOps实现基础设施即代码

• 在CI/CD管道中落实安全措施

• 可观测性与监控

• 企业级CI/CD管道的最佳实践

• 总结

先决条件

在开始使用Azure DevOps的CI/CD管道进行基于云的原生开发之前，了解以下概念是非常有帮助的：

• 熟悉使用ASP.NET Core或.NET构建应用程序的相关知识（例如控制器、API以及项目结构等）。

• 了解如何克隆代码库、创建分支以及推送代码变更。

• 能够运行诸如`dotnet build`、`docker build`和`kubectl`之类的命令。

• 理解持续集成与持续部署的含义及其重要性。

• 对容器化技术的工作原理以及Docker如何打包应用程序有所了解。

• 熟悉Microsoft Azure或其他类似的云服务提供商。

要完成这些示例，您还需要具备以下工具：

• .NET SDK（建议使用6版或更高版本）

• 本地安装的Docker

• Azure DevOps账户

• Azure CLI（可选，但非常有用）

• 如VS Code或Visual Studio这样的代码编辑器

概述

现代企业应用程序必须具备可扩展性、适应能力以及快速部署的能力。传统的单体应用开发模式（即手动进行应用构建、测试和部署）已不再适合在快节奏环境中交付软件的团队。如今，各组织都期望能够实现功能的快速交付、自动化测试以及拥有高可靠性的基础设施。

云原生开发通过采用自动化技术、微服务架构、容器化方案以及持续集成/持续交付机制来应对这些挑战。对于那些负责开发企业级应用程序的.NET团队来说，将云原生理念与Azure DevOps的CI/CD流程相结合，是一种能够有效自动化软件部署过程并提升系统可靠性的方法。

Azure DevOps使团队能够创建完全自动化的流程，从而在各种环境中完成应用的构建、测试和部署工作。当这些CI/CD流程与.NET应用程序以及Azure Kubernetes Service（AKS）或Azure App Service等云平台相结合时，它们便成为了云原生开发工作流程的核心支柱。

读完本指南后，您将了解如何使用Azure DevOps为.NET应用程序构建云原生部署流程。

云原生.NET开发的原理

云原生应用程序是专门为在动态的云环境中运行而设计的。与将云仅仅视为另一种托管方式不同，云原生系统充分利用了云环境的弹性、自动化特性以及分布式架构的优势。

其主要原则包括：

微服务架构

现代.NET应用程序通常会被拆分为多个独立的微服务。每个微服务都可以独立地进行部署、扩展或更新，这种设计方式大大降低了系统之间的耦合程度，使团队能够更快地推出新功能。

无状态服务

云原生服务一般不会在本地存储会话数据。相反，这些数据会被保存在分布式数据库、缓存系统中或其他的存储服务中。这样一来，应用程序就可以在多个实例上实现水平扩展。

容器化技术

容器能够将应用程序及其依赖项一起打包起来，从而确保应用程序在各种环境中都能保持一致的执行效果。像Docker这样的技术使得.NET服务能够在开发环境、测试环境和生产环境中以完全相同的方式运行。

基础设施即代码

云基础设施是通过Bicep、ARM或Terraform等模板以声明性方式定义的。这种方式能够确保环境配置的可复现性、版本控制机制的有效性，以及自动化部署流程的顺利执行。

可观测性与弹性

云原生应用必须能够通过日志、指标和跟踪信息来进行监控。同时，这些应用也需要具备重试机制、断路器以及健康检查等功能，以确保其具有弹性。

Azure DevOps管道通过自动化构建、部署及运维流程，帮助实现这些原则。

了解Azure DevOps CI/CD管道

Azure DevOps管道能够自动化应用程序的构建、测试和部署过程。

一个典型的管道包含两个阶段：

• 持续集成（CI）

• 持续部署（CD）

持续集成（CI）

持续集成能够确保每一处代码变更都会被自动构建并进行测试。

当开发人员将代码推送到仓库后，管道会执行以下操作：

• 恢复依赖关系

• 编译应用程序

• 运行自动化测试

• 生成构建成果文件

这一过程有助于团队及时发现问题，并保持代码质量。

持续部署（CD）

持续部署会将生成的构建成果文件部署到不同的环境中，例如：

• 开发环境

• 测试环境

• 生产环境

部署过程可能还包括基础设施配置、容器镜像发布以及应用程序的上线工作。

为.NET应用程序创建Azure DevOps管道

Azure DevOps使用YAML格式的管道定义自动化工作流程。

让我们先从一个简单的示例开始，了解如何为.NET应用程序配置Azure DevOps管道。

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'

steps:
- task: UseDotNet@2
  inputs:
    packageType: 'sdk'
    version: '8.0.x'

- script: dotnet restore
  displayName: 恢复依赖关系

- script: dotnet build --configuration $(buildConfiguration)
  displayName: 构建项目

- script: dotnet test --configuration $(buildConfiguration)
  displayName: 运行单元测试

- script: dotnet publish -c \((buildConfiguration) -o \)(Build.ArtifactStagingDirectory)
  displayName: 发布应用程序

- task: PublishBuildArtifacts@1

 inputs:
    pathToPublish: $(Build.ArtifactStagingDirectory)
    artifactName: drop

这个管道会执行以下操作：

1. 安装.NET SDK

2. 恢复NuGet依赖关系

3. 构建应用程序

4. 运行测试

5. 发布构建成果文件

一旦这些构建成果文件生成完成，它们就可以被自动部署到目标环境中。

将.NET应用程序容器化

原生云系统通常会使用容器来确保不同环境之间的一致性。

Docker允许你将.NET应用程序及其依赖项打包成一个容器镜像。

以下是一个用于ASP.NET Core应用程序的Dockerfile示例：

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src

COPY . .
RUN dotnet restore
RUN dotnet publish -c Release -o /app

FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app .

ENTRYPOINT ["dotnet", "MyApp.dll"]

这个Dockerfile采用了多阶段构建机制，从而使得最终的容器镜像体积更小。

应用程序在构建阶段被编译成可执行文件，随后这些文件会被复制到一个更小的运行时镜像中。

在Azure DevOps中构建和发布Docker镜像

在将应用程序容器化之后，管道会自动构建并推送相应的容器镜像。

- task: Docker@2
  displayName: 构建并推送Docker镜像
  inputs:
    command: buildAndPush
    repository: myregistry.azurecr.io/myapp
    dockerfile: Dockerfile
    containerRegistry: MyAzureContainerRegistry
    tags: |
      $(Build.BuildId)
      latest

这个步骤会执行两项重要的操作：

1. 构建Docker镜像

2. 将其推送至Azure容器注册库

一旦镜像被存储在Azure容器注册库中，就可以将其部署到各种环境中。

部署到Azure Kubernetes Service (AKS)

Kubernetes是一种广泛用于管理原生云应用程序的编排平台。

Azure Kubernetes Service (AKS)简化了Kubernetes的应用程序部署与管理流程。

要部署应用程序，你可以使用Kubernetes的部署配置文件。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dotnet-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: dotnet-app
template:
  metadata:
    labels:
      app: dotnet-app
spec:
  containers:
  - name: dotnet-app
    image: myregistry.azurecr.io/myapp:latest
    ports:
    - containerPort: 80

此配置定义了以下内容：

• 部署3个副本的应用程序

• 要运行的容器镜像

• 暴露的端口信息

现在我们需要添加一个管道步骤来执行部署操作。

- task: KubernetesManifest@0
  inputs:
    action: deploy
    kubernetesServiceConnection: myKubernetesConnection
    namespace: default
    manifests: deployment.yaml

这个步骤会将最新版本的应用程序部署到Kubernetes集群中。

利用部署阶段来管理环境

企业级管道通常包含多个环境。

例如：

• 开发环境

• 质量保障环境

• 生产环境

Azure DevOps允许为管道定义部署阶段。

示例：

stages:
- stage: 构建
 jobs:
  - job: 构建应用
  steps:
      - script: dotnet build

  - stage: 部署开发环境
  dependsOn: Build
  jobs:
  - deployment: 部署开发环境
    environment: dev
    strategy:
     runOnce:
       deploy:
        steps:
          - script: echo 正在部署到开发环境
- stage: 部署生产环境
  dependsOn: DeployDev
  jobs:
  - deployment: 部署生产环境
    environment: production

这些阶段使团队能够：

• 审批部署请求

• 运行针对特定环境的测试

• 控制不同环境之间的数据迁移流程

使用 Azure DevOps 实现基础设施即代码

云原生环境要求基础设施配置过程必须自动化。

Terraform、Bicep 或 ARM 模板等工具可以将基础设施配置定义为代码形式。

示例：Terraform 管道中的相关步骤：

- script: |
    terraform init
    terraform plan
    terraform apply -auto-approve
  displayName: 配置基础设施

这种方式能够确保基础设施环境的一致性及可重复性。

在 CI/CD 管道中落实安全措施

CI/CD 管道中的安全机制应当实现自动化，并在交付流程的每个阶段得到执行。现代管道会将安全检查直接集成到构建和部署工作中。

以下是一些实际的安全实践方案。

1. 使用 Azure Key Vault 保护敏感信息

切勿将 API 密钥、连接字符串等敏感数据硬编码到代码中。

在 Azure DevOps 中，可以通过变量组将 Azure Key Vault 中的密钥引入管道配置中。

管道示例：

variables:
- group: KeyVault-Secrets

在代码中的使用方式

var connectionString = Environment.GetEnvironmentVariable(“DB_CONNECTION”);

这样就能确保：

• 敏感信息得到安全存储

• 源代码中不会包含任何敏感数据

• 密钥更新时无需修改代码

2. 扫描依赖项中的安全漏洞

在构建过程中自动检测依赖项是否存在安全漏洞。

管道步骤示例：

- script: dotnet list package --vulnerable
  displayName: 检查依赖项中的漏洞

示例输出结果

这使团队能够：

• 及早发现安全漏洞

• 阻止存在安全问题的构建过程继续进行

3. 静态代码分析

使用SonarCloud等工具或内置的分析器来发现安全问题。

示例流程步骤：

- task: SonarCloudAnalyze@1

这种分析方法可以检测出以下问题：

• SQL注入风险

• 硬编码的凭证信息

• 不安全的API使用方式

4. 强制执行安全构建规则

你可以实施以下规则：

• 阻止存在漏洞的构建请求

• 要求拉取请求必须获得批准才能继续构建过程

示例——当检测到漏洞时终止构建流程：

- script: |
    dotnet list package --vulnerable | grep "High" && exit 1 || echo "未发现高严重性漏洞"
  displayName: 发现高严重性漏洞时终止构建

5. 容器安全扫描

在部署之前对Docker镜像进行安全扫描。

- task: Docker@2
  displayName: 扫描Docker镜像
  inputs:
    command: build

你可以使用Trivy或Microsoft Defender for Containers等工具来进行扫描。

可观测性与监控

云原生应用程序需要具备强大的可观测性功能。

可观测性能够帮助你了解应用程序在生产环境中的运行状况。在云原生系统中，可观测性对于调试、性能优化以及提升系统的可靠性而言至关重要。

一个完善的可观测性策略应包括以下内容：

• 日志记录

• 指标监控

• 跟踪分析

1. 为.NET应用程序添加Application Insights功能

Azure Application Insights为.NET应用程序提供了内置的遥测功能。

在ASP.NET Core中的配置方法：

builder.Services.AddApplicationInsightsTelemetry();

示例：自定义日志记录功能

private readonly ILogger _logger;

public HomeController(ILogger logger)
{
    _logger = logger;
}

public IActionResult Index()
{
    _logger.LogInformation("有人访问了首页");
    return View();
}

在Azure门户中，这些数据会以以下形式呈现：

• 请求日志

• 响应时间

• 依赖项跟踪信息

2. 自定义指标的跟踪与监控

您可以追踪与业务相关的各项指标。

var telemetryClient = new TelemetryClient();

telemetryClient.TrackMetric("OrdersProcessed", 1);

示例应用场景：

• API调用次数

• 已处理的订单数量

• 失败的交易记录

3. 分布式追踪示例

追踪功能有助于了解请求在各个服务之间的流转过程。

using System.Diagnostics;

var activity = new Activity("ProcessOrder");
activity.Start();

// 在此处编写业务逻辑

activity.Stop();

这样您就可以：

• 追踪微服务之间的请求流程

• 识别系统中的瓶颈环节

4. CI/CD管道中的可观测性

您还可以监控管道的执行过程本身。

示例：在管道中添加日志记录功能

- script: echo "正在部署版本 $(Build.BuildId)"
  displayName: 记录部署版本信息

示例：追踪部署耗时

- script: date
  displayName: 开始时间

- script: echo "正在部署..."

- script: date
  displayName: 结束时间

5. 监控Kubernetes部署任务

如果使用AKS，就需要监控Pod和服务的状态。

kubectl get pods
kubectl logs 

这些操作有助于发现以下问题：

• 系统崩溃的原因

• 导致服务不断重启的因素

• 性能瓶颈所在

• 可观测性在实际应用中的效果

在真实的系统中，可观测性能够帮助您解答诸如以下问题：

• 为什么这个请求会变慢？

• 是哪个服务出现了故障？

• 上次部署时发生了哪些变化？

例如：

延迟时间的突然增加可能源于数据库查询效率低下；错误次数的增多可能与最近的部署操作有关；而高CPU使用率则很可能意味着代码存在优化空间。

企业级CI/CD管道的最佳实践

为企业的.NET应用程序设计CI/CD管道，仅仅依靠自动化是远远不够的——还需要确保流程的一致性、可靠性以及可控制性。以下是一些关键的最佳实践，并附有实际应用案例，帮助您了解这些做法如何在实际中得到落实。

1. 采用声明式设计，基于YAML格式

使用YAML格式定义管道，可以确保其版本可控且可重复执行。

示例：

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- script: dotnet build

这种设计方式可以让您：

• 通过Git跟踪管道代码的变化

• 通过拉取请求来审查管道更新内容

• 在多个项目中复用相同的模板

2. 在多个层级实施自动化测试

一个完善的测试流程应当包括单元测试、集成测试以及端到端测试。

示例：

- script: dotnet test --filter Category=Unit
  displayName: 运行单元测试

- script: dotnet test --filter Category=Integration
  displayName: 运行集成测试

这样能够确保错误尽早被发现，关键业务流程得到有效验证，同时也能使发布的版本更加稳定。

3. 使用不可变的构建产物

只需构建一次，然后将相同的构建产物部署到所有环境中。

示例：

- script: dotnet publish -c Release -o $(Build.ArtifactStagingDirectory)

- task: PublishBuildArtifacts@1
  inputs:
    pathToPublish: $(Build.ArtifactStagingDirectory)
    artifactName: drop

部署时使用相同的构建产物

- task: DownloadBuildArtifacts@0
  inputs:
    artifactName: drop

这样能够避免环境间的不一致性，以及“仅在我的机器上可以正常运行”这类问题的发生。

4. 启用安全的部署策略（蓝绿部署/金丝雀测试)

避免一次性将新版本直接部署给所有用户。

示例：金丝雀测试的原理

- script: echo "正在向10%的用户部署新版本"

spec:
  replicas: 10

pr:
- main
steps:
- script: dotnet build
- script: dotnet test

- stage: DeployProd
  jobs:
- deployment: Deploy
    environment: production

- script: echo "版本号：$(Build.BuildId)"

tags: |
  $(Build.BuildId)
  latest

- script: echo "开始部署..."
- script: dotnet build
- script: echo "构建完成"

- script: |
    terraform init
    terraform apply -auto-approve

- script: echo "构建完成于 $(date)"