在 Azure 中部署容器

小窍门

此内容摘自电子书《为 Azure 架构云原生 .NET 应用程序》,可在 .NET 文档 查阅或下载免费的 PDF 离线阅读。

Azure 平台的云原生 .NET 应用电子书封面缩略图。

本章和第 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

创建容器注册表

图 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 等工具中定义的生成管道。 在 Cloud-Native 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 即可。