迁移到 Google Cloud：从手动部署迁移到自动容器化部署

Last reviewed 2023-12-08 UTC

本文档可帮助您规划和设计使用云原生工具和 Google Cloud 代管式服务在 Google Cloud 中实现从手动部署到自动容器化部署的迁移路径。

本文档是关于迁移到 Google Cloud 的以下系列文章中的一篇：

如果您正计划对部署流程进行现代化改造、正从旧的手动部署流程迁移到自动容器化部署，或者正在评估迁移的时机并希望了解迁移的可能情况，则本文档非常有用。

在开始迁移之前，您应该评估迁移的范围以及当前部署流程的状态，并设置您的预期和目标。您可以根据您当前部署工作负载的方式来选择起点：

  • 手动部署工作负载。
  • 使用配置管理 (CM) 工具部署工作负载。

从手动部署直接迁移到完全自动的容器化部署非常困难。因此，我们建议您采用以下迁移步骤：

  1. 使用容器编排工具进行部署。
  2. 自动部署。

在每个迁移步骤中，您需要按照迁移到 Google Cloud：使用入门中定义的阶段执行操作：

  1. 评估和发现工作负载。
  2. 规划和构建基础。
  3. 部署工作负载。
  4. 优化您的环境和工作负载。

下图展示了每个步骤的迁移阶段。

迁移路径包含四个阶段。

此迁移路径非常理想，但如果转到下一步的好处超过了您的特定情况的费用，您可以在迁移过程的早期停止。例如，如果您不打算自动部署工作负载，则可以在使用容器编排工具进行部署后停止。 将来在准备好继续操作时，您可以重新查看此文档。

当您从迁移的一个步骤进行到另一个步骤时，存在一个过渡阶段，您可能会在此阶段中同时使用不同部署流程。 实际上，您无需为所有工作负载仅选择一个部署选项。例如，您可以在混合环境中应用 IaC 模式管理基础架构，同时仍使用容器编排工具部署工作负载。

迁移到容器编排工具

从手动部署迁移的其中一个首要步骤是使用容器编排工具部署工作负载。在此步骤中，您将使用 Kubernetes 等容器编排工具设计和实现部署流程，以处理容器化工作负载。

如果您的工作负载尚未容器化，您将需要花费大量精力对其进行容器化。并非所有工作负载都适合进行容器化。如果您要部署的工作负载并非云就绪或未准备好进行容器化，则对工作负载进行容器化可能没有价值。由于技术或许可原因，某些工作负载甚至不支持容器化。

评估和发现工作负载

如需确定迁移的范围，您首先需要一个正在生成和部署的工件及其与其他系统和工件的依赖关系的清单。要构建此清单，您需要利用设计和实施当前工件生产和部署流程的团队的专业知识。迁移到 Google Cloud：评估和发现工作负载文档介绍了如何在迁移过程中评估环境，以及如何构建应用清单。

对于每个工件，您需要评估其当前测试覆盖范围。 当所有工件都具有适当的测试覆盖范围后，您才能进行下一步操作。如果必须手动测试和验证每个工件，则自动化不会带来任何好处。可以采用一种强调测试重要性的方法，例如测试驱动开发。

评估过程时，请考虑生产环境中可能有多少不同版本的工件。例如，如果工件的最新版本比您必须支持的实例要早几个版本，则您必须设计一个同时支持这两个版本的模型。

此外，还要考虑用于管理代码库的分支策略。分支策略只是您需要评估的协作模型的一部分，您需要评估团队内部和外部更广泛的协作流程。例如，如果您采用灵活的分支策略，但未根据通信过程对其进行调整，则这些团队的效率可能会下降。

在此评估阶段，您还需要确定如何使您生产的工件比当前部署流程更高效、更加适合容器化。提高效率的一种方法是评估以下各项：

  • 通用部分：评估您的工件的共同之处。例如，如果您具有公共库和其他运行时依赖项，请考虑将其整合到同一个运行时环境中。
  • 运行时环境要求：评估是否可以简化运行时环境以减少其变化。例如，如果您要使用不同的运行时环境来运行所有工作负载，请考虑从通用基础开始，以减轻维护负担。
  • 不必要的组件：评估您的工件是否包含不必要的部分。例如，您可能有并非确实需要的实用程序工具，例如调试和问题排查工具。
  • 配置和 Secret 注入：根据运行时环境的要求评估如何配置工件。例如，您当前的配置注入系统可能不支持容器化环境。
  • 安全要求：评估容器安全模型是否符合要求。例如，容器化环境的安全模型可能与工作负载的要求（即具有超级用户特权、直接访问系统资源或单独租用）冲突。
  • 部署逻辑要求：评估是否需要实现高级部署流程。例如，如果您需要实现 Canary 部署过程，则可以确定容器编排工具是否支持该过程。

规划和构建基础

接下来，您将预配和配置 Google Cloud 基础架构和服务，以支持 Google Cloud 上的部署流程。迁移到 Google Cloud：构建您的基础文档包含有关如何构建您的基础的指导。

为了实现必要的灵活性以管理 Google Cloud 资源，我们建议您设计 Google Cloud 资源层次结构，以支持将多个环境用于开发、测试和生产等工作负载。

在建立用户和服务身份时，为实现最佳隔离，您需要为每个部署流程步骤提供至少一个服务账号。例如，如果您的进程执行步骤以生产工件并管理该工件在代码库中的存储，则您需要至少两个服务账号。如果要为部署流程预配和配置开发和测试环境，您可能需要创建更多服务账号。如果您在每个环境中具有一组不同的服务账号，则可以使这些环境相互独立。虽然此配置增加了基础架构的复杂性和运营团队的负担，但使您可以灵活地独立测试和验证对部署流程的每项更改。

您还需要预配和配置服务和基础架构，以支持容器化工作负载：

通过使用容器编排工具，您不必担心在部署新的工作负载时预配基础架构。例如，您可以使用 Autopilot 自动管理 GKE 集群配置。

使用容器编排工具部署工件

根据您在此步骤的评估阶段和建立基础阶段收集的要求，您需要执行以下操作：

  • 将工作负载容器化。
  • 实施部署流程以处理容器化工作负载。

将工作负载容器化是一项重要任务。随后是您需要对其进行调整和扩展以将工作负载容器化的一系列通用活动。您的目标是满足您自己的需求，例如网络和流量管理、永久性存储、Secret 和配置注入以及容错要求。本文档包含两项活动：构建一组用作基础的容器映像，以及构建一组用于工作负载的容器映像。

首先，您将自动生成工件，因此无需为每个新部署手动生成新映像。每次修改源代码时，系统都应自动触发工件构建流程，以便您即时获得有关每次更改的反馈。

您需要执行以下步骤以生成每个映像：

  1. 构建映像。
  2. 运行测试套件。
  3. 将映像存储在注册表中。

例如，您可以使用 Cloud Build 构建工件并对其运行测试套件，如果测试成功，将结果存储在 Container Registry 中。

您还需要制定用于识别工件的规则和惯例。生成映像时，请为每个映像添加标签，以使流程的每次执行都可重复。例如，一个常见惯例是使用语义版本控制（在生成版本时标记容器映像）来标识版本。当生成在发布之前仍需要处理的映像时，您可以使用将这些映像与代码库中您的进程生成它们的点相关联的标识符。例如，如果您使用的是 Git 代码库，则可以使用提交哈希作为标识符，用于您在将提交推送到代码库的主实例分支时所生成的相应容器映像。

在此步骤的评估阶段，您收集了关于工件、其通用部分及运行时要求的信息。利用这些信息，您可以设计和构建一组基础容器映像以及另一组用于工作负载的映像。您可以使用基础映像作为构建工作负载映像的起点。应严格控制和支持这组基础映像，以避免不受支持的运行时环境激增。

从基础映像生成容器映像时，请务必扩展测试套件以覆盖这些映像，而不是仅仅覆盖每个映像中的工作负载。您可以使用 InSpec、ServerSpec 和 RSpec 等工具针对您的运行时环境运行合规性测试套件。

完成将工作负载容器化并实现自动生成此类容器映像的过程后，您将实现部署流程以使用容器编排工具。在评估阶段，您将使用所收集的有关部署逻辑要求的信息来设计丰富的部署流程。通过使用容器编排工具，您可以专注于使用提供的机制来编排部署逻辑，而无需手动实现它们。

在设计和实施部署流程时，请考虑如何在工作负载中注入配置文件和密文，以及如何管理有状态工作负载的数据。配置文件和 Secret 注入有助于生成不可变的工件。通过部署不可变的工件，您可以实现以下几点：

  • 例如，您可以在开发环境中部署工件。 然后，在对工件进行测试和验证后，将其移至质量保证环境。最后，将它们移至生产环境。
  • 您可以降低生产环境中出现问题的几率，因为同一工件经过了多项测试和验证活动。

如果您的工作负载是有状态工作负载，我们建议您为数据预配和配置必要的永久性存储空间。在 Google Cloud 上，您可以从以下选项中进行选择：

当您能够自动生成要部署的工件时，可以为用于部署工作负载的工具设置运行时环境。 要控制部署工具的运行时环境，您可以在 Cloud Build 中将环境设置为构建，并将该构建用作在环境中部署工件的唯一方式。通过使用 Cloud Build，无需要求每个操作员在其机器上设置运行时环境。您可以通过检查构建配置的源代码，立即审核创建运行时环境及其内容的过程。

优化环境

实现部署流程后，您可以使用容器编排工具开始优化部署流程。如需了解详情，请参阅迁移到 Google Cloud：优化您的环境。

此优化迭代的要求如下：

  • 根据需要扩展监控系统。
  • 扩展测试覆盖范围。
  • 增加环境安全性。

您可以扩展监控系统以覆盖新工件生产、部署流程以及所有新运行时环境。

如果您希望尽可能有效地监控、自动化和标准化您的流程，我们建议您扩大测试的覆盖范围。在评估阶段，您已确保您至少拥有最小的端到端测试覆盖范围。在优化阶段，您可以扩展测试套件以覆盖更多使用场景。

最后，如果要增加环境的安全性，您可以配置 Binary Authorization 以仅允许在集群中部署一组签名映像。您还可以启用 Artifact Analysis 来扫描 Artifact Registry 中存储的容器映像以查找漏洞。

迁移到部署自动化

迁移到容器编排工具后，您可以迁移到完全部署自动化，并且可以扩展工件生产和部署流程以自动部署工作负载。

评估和发现工作负载

基于之前的评估，您现在可以专注于部署流程的要求：

  • 手动批准步骤：评估您是否需要在部署流程中支持任何手动步骤。
  • 每次部署的单元数：评估您需要支持多少每次部署单元数。
  • 导致新部署的因素：评估哪些外部系统与您的部署流程交互。

需要支持手动部署步骤并不意味着您的流程无法自动执行。在这种情况下，您可以自动执行流程的每个步骤，并在适当位置放置手动批准门控。

每天或每小时支持多个部署比每月或每年支持一些部署更复杂。但是，如果您不经常部署，您的敏捷性和对问题的反应能力以及在工作负载中交付新功能的能力可能会降低。因此，在设计和实施完全自动化的部署流程之前，最好先设定好预期和目标。

此外，还要评估哪些因素会在运行时环境中触发新部署。例如，您可能会在开发环境中部署每个新发布，但仅在发布满足特定质量标准时才在质量保证环境中部署该发布。

规划和构建基础

如需扩展您在上一步中构建的基础，您需要预配和配置服务以支持自动部署流程。

对于每个运行时环境，请设置必要的基础架构以支持您的部署流程。例如，如果您在开发、质量保证、预生产和生产环境中预配和配置部署流程，则可以自由灵活地测试对流程所做的更改。但是，如果您使用单个基础架构部署运行时环境，您的环境将会更加易于管理，但在需要更改流程时却不够灵活。

在预配服务账号和角色时，请考虑创建不共担责任的专用服务账号，以将环境和工作负载隔离开来。例如，不要对不同运行时环境重复使用相同服务账号。

通过完全自动化的程序部署工件

在此阶段，您将配置部署流程，以在无需手动干预的情况下（批准步骤除外）部署工件。

您可以使用 Cloud Deploy 等工具，根据您在此迁移步骤的评估阶段中收集的要求实现自动部署流程。

对于任何给定工件，每个部署流程都应执行以下任务：

  1. 在目标运行时环境中部署工件。
  2. 在已部署的工件中注入配置文件和密文。
  3. 针对新部署的工件运行合规性测试套件。
  4. 将工件提升到生产环境。

请确保您的部署流程提供了根据要求触发新部署的接口。

代码审核是实现自动部署流程的必要步骤，因为在设计上，短的反馈环是这些流程的一部分。例如，如果您在没有任何审核的情况下部署对生产环境的更改，则会影响生产环境的稳定性和可靠性。未审核、格式错误或恶意的更改可能会导致服务中断。

优化环境

自动执行部署流程后，您可以执行另一优化迭代。此迭代的要求如下：

  • 扩展监控系统，以覆盖支持自动部署流程的基础架构。
  • 实现更高级的部署模式。
  • 实现紧急访问权限流程。

借助有效的监控系统，您可以计划对环境进行进一步优化。衡量环境的行为时，您可能会发现妨碍性能的瓶颈或其他问题，例如未经授权或意外的访问和漏洞攻击。例如，您可以配置环境，使您可以在某些资源的使用量达到阈值时收到提醒。

当您能够高效编排容器时，您可以根据需要实现高级部署模式。例如，您可以实现蓝绿部署，以提高环境的可靠性并减小任何问题对用户产生的影响。

后续步骤