在 Azure 中部署容器

提示

此内容摘自电子书《为 Azure 构建云原生 .NET 应用程序》,可在 .NET 文档上获取,也可作为免费可下载的 PDF 脱机阅读。

Cloud Native .NET apps for Azure eBook cover thumbnail.

本章节和第 1 章讨论了容器。 我们发现,容器为云原生应用程序提供了许多好处,包括可移植性。 在 Azure 云中,你可以在过渡环境和生产环境中部署相同的容器化服务。 Azure 提供了多个用于托管容器化工作负载的选项:

  • Azure Kubernetes 服务 (AKS)
  • Azure 容器实例 (ACI)
  • 适用于容器的 Azure Web 应用

Azure 容器注册表

容器化微服务时,首先构建一个容器“映像”。此映像是服务代码、依赖项和运行时的二进制表示形式。 尽管可以使用 DOCKER API 中的 Docker Build 命令手动创建映像,但更好的方法是将其创建为自动生成过程的一部分。

创建后,容器映像存储在容器注册表中。 它们使你能够生成、存储和管理容器映像。 有很多可用的注册表,无论是公共的还是私有的。 Azure 容器注册表 (ACR) 是 Azure 云中完全托管的容器注册表服务。 它将映像保存在 Azure 网络中,缩短将其部署到 Azure 容器主机的时间。 你还可以使用用于其他 Azure 资源的安全和标识过程来保护这些资源。

使用 Azure 门户Azure CLIPowerShell 工具创建 Azure 容器注册表。 在 Azure 中创建注册表非常简单。 需要 Azure 订阅、资源组和唯一名称。 图 3-10 显示了用于创建注册表的基本选项,这些选项托管在 registryname.azurecr.io 上。

Create container registry

图 3-10. 创建容器注册表

创建注册表后,需要先对其进行身份验证,然后才能使用。 通常,你将使用 Azure CLI 命令登录到注册表:

az acr login --name *registryname*

经过身份验证后,可以使用 docker 命令将容器映像推送到其中。 但是,在执行此操作之前,必须用 ACR 登录服务器的完全限定名 (URL) 来标记映像。 它的格式为 registryname.azurecr.io。

docker tag mycontainer myregistry.azurecr.io/mycontainer:v1

标记该映像后,使用 docker push 命令将该映像推送到 ACR 实例。

docker push myregistry.azurecr.io/mycontainer:v1

将映像推送到注册表后,最好使用以下命令从本地 Docker 环境中删除映像:

docker rmi myregistry.azurecr.io/mycontainer:v1

作为最佳做法,不应手动将映像推送到容器注册表。 请改用在 GitHub 或 Azure DevOps 等工具中定义的生成管道。 有关详细信息,请参阅云原生 DevOps 章节

ACR 任务

ACR 任务是一组 Azure 容器注册表中的功能。 它通过在 Azure 云中构建和管理容器映像来延长内部循环开发周期 。 它们不是在开发计算机上调用 docker builddocker push,而是由云中的 ACR 任务自动处理。

以下 AZ CLI 命令都生成一个容器映像并将其推送到 ACR:

# create a container registry
az acr create --resource-group myResourceGroup --name myContainerRegistry008 --sku Basic

# build container image in ACR and push it into your container registry
az acr build --image sample/hello-world:v1  --registry myContainerRegistry008 --file Dockerfile .

如前面的命令块中所示,无需在开发计算机上安装 Docker Desktop。 此外,还可以配置 ACR 任务触发器,以便在源代码和基本映像更新时重新生成容器映像。

Azure Kubernetes 服务

本章中详细讨论了 Azure Kubernetes 服务 (AKS)。 我们已了解到,事实上是容器业务流程协调程序在管理容器化的云原生应用程序。

将映像部署到注册表(如 ACR)后,可将 AKS 配置为自动拉取和部署映像。 CI/CD 管道布置妥当后,你可以配置一种金丝雀发布策略,以最大程度地减少快速部署更新时所涉及的风险。 新版本的应用最初在生产环境中进行了配置,但未将流量路由到该应用。 然后,系统会将少量用户路由到新部署的版本。 随着团队在新版本中增强信心,可以推出更多实例并停用旧版本。 AKS 轻松支持这种模式的部署。

与 Azure 中的大多数资源一样,可以使用门户、命令行或自动化工具(例如 Helm 或 Terraform)创建 Azure Kubernetes 服务群集。 若要开始使用新群集,需要提供以下信息:

  • Azure 订阅
  • 资源组
  • Kubernetes 群集名称
  • 区域
  • Kubernetes 版本
  • DNS 名称前缀
  • 节点大小
  • 节点计数

此信息足以开始使用。 Azure 门户中的创建过程还包括为以下群集功能配置选项:

  • 缩放
  • 身份验证
  • 网络
  • 监视
  • 标记

快速入门演示如何使用 Azure 门户部署 AKS 群集

Azure Bridge to Kubernetes

云原生应用程序可能会变得很大很复杂,需要大量的计算资源才能运行。 在这些情况下,开发计算机(尤其是便携式计算机)就无法承载整个应用程序了。 Azure Bridge to Kubernetes 解决了该缺点。 它使开发人员能够使用其服务的本地版本,同时在 AKS 开发群集中承载整个应用程序。

准备就绪后,开发人员可以在本地测试更改,同时针对 AKS 群集中的整个应用程序运行,而不会复制依赖项。 在这种情况下,Bridge 将本地计算机中的代码与 AKS 中的服务合并。 开发人员可以使用 Visual Studio 或 Visual Studio Code 直接在 Kubernetes 中快速迭代和调试代码。

Microsoft 的前产品管理部副总裁 Gabe Monroy 形象地描述了这种情况:

假设你是一名新员工,尝试修复复杂微服务应用程序中的 bug,该应用程序包含数十个组件,每个组件都有自己的配置和支持服务。 为了开始工作,必须配置本地开发环境,使其可以模拟生产环境,包括设置 IDE 以及构建工具链、容器化服务依赖项、本地 Kubernetes 环境和支持服务模拟,等等。 由于所有时间涉及设置开发环境,修复第一个 bug 可能需要数天时间! 或者,你可以只使用 Bridge to Kubernetes 和 AKS。