在 Azure 中部署容器
本章节和第 1 章讨论了容器。 我们发现,容器为云原生应用程序提供了许多好处,包括可移植性。 在 Azure 云中,你可以在过渡环境和生产环境中部署相同的容器化服务。 Azure 提供了多个用于托管容器化工作负载的选项:
- Azure Kubernetes 服务 (AKS)
- Azure 容器实例 (ACI)
- 适用于容器的 Azure Web 应用
Azure 容器注册表
容器化微服务时,首先构建一个容器“映像”。此映像是服务代码、依赖项和运行时的二进制表示形式。 尽管可以使用 DOCKER API 中的 Docker Build
命令手动创建映像,但更好的方法是将其创建为自动生成过程的一部分。
创建后,容器映像存储在容器注册表中。 它们使你能够生成、存储和管理容器映像。 有很多可用的注册表,无论是公共的还是私有的。 Azure 容器注册表 (ACR) 是 Azure 云中完全托管的容器注册表服务。 它将映像保存在 Azure 网络中,缩短将其部署到 Azure 容器主机的时间。 你还可以使用用于其他 Azure 资源的安全和标识过程来保护这些资源。
使用 Azure 门户、Azure CLI 或 PowerShell 工具创建 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 等工具中定义的生成管道。 有关详细信息,请参阅云原生 DevOps 章节。
ACR 任务
ACR 任务是一组 Azure 容器注册表中的功能。 它通过在 Azure 云中构建和管理容器映像来延长内部循环开发周期 。 它们不是在开发计算机上调用 docker build
和 docker 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。