迁移到 Google Cloud：部署您的工作负载

Last reviewed 2023-12-08 UTC

本文档可帮助您计划和设计向 Google Cloud 迁移的部署阶段。在评估了当前环境、计划了向 Google Cloud 的迁移，并构建好 Google Cloud 基础之后，您就可以部署工作负载了。

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

下图说明了迁移过程的路径。

迁移路径包含四个阶段。

部署阶段是向 Google Cloud 迁移的第三个阶段，在此阶段中，您将为工作负载设计一个部署流程。

如果您计划从本地环境、私有托管环境或其他云服务商迁移到 Google Cloud，或者您要评估迁移机会并希望了解其具体操作，那么本文档非常有用。

在本文档中，您将按照灵活性、自动化和复杂性的顺序，以及有关如何选择适合您的方法的标准，了解不同的部署流程类型：

  1. 手动部署。
  2. 使用配置管理 (CM) 工具进行部署。
  3. 使用容器编排工具进行部署。
  4. 自动部署。

在部署工作负载之前，请先计划和设计部署阶段。首先，您应该评估为工作负载实现的不同部署流程的类型。在评估部署流程类型时，您可以从一个简单的流程开始，然后再过渡到更复杂的流程。 这种方法可以获得更快的结果，但是当您过渡到更高级的流程时，也会遇到阻碍，因为您必须消除在使用更简单的流程期间积累的技术债务。例如，如果您从完全手动部署过渡到自动化解决方案，则可能必须管理对部署流水线和应用的升级。

虽然可以根据工作负载的需求实现不同类型的部署流程，但这种方法也可能增加此阶段的复杂性。如果实现不同类型的部署流程，则可以从增加的灵活性中受益，但是您可能需要具有每种流程对应的专业知识、工具和资源，这意味着需要付出更多的精力。

手动部署

完全手动的部署以完全非自动化的预配、配置和部署流程为基础。尽管这种流程的每个步骤都可能有对应的规范和核对清单，但这些规范并不会自动检查或强制执行。手动流程无法重复执行，容易出现人为错误，并且其效果会受到人为因素的限制。

完全手动的部署流程有其用武之地，例如需要在沙盒环境中快速检测实验时。为持续数分钟的实验设置结构化的自动化流程可能会不必要地减慢您的速度，尤其是在迁移的早期阶段，因为您可能会缺乏用于构建自动化流程的工具和做法所需的专业知识。

尽管 Google Cloud 并没有这种限制，但是在缺少必要的管理 API 的裸机环境中操作时，完全手动的部署可能是您的唯一选择。在这种情况下，由于缺少必要的接口，您无法实现自动化流程。如果您拥有的旧版虚拟化基础架构不支持任何自动化功能，则可能必须实现完全手动的流程。

除非别无选择，我们建议避免使用完全手动的部署。

您可以使用 Google Cloud Console、Cloud Shell、Cloud API 和 Google Cloud CLI 等工具实现完全手动预配、配置和部署流程。

使用配置管理工具进行部署

借助 CM 工具，您可以通过可重复执行且受控的方式配置环境。 这些工具包括一组已经实现通用配置操作的插件和模块。使用这些工具时，您可以专注于要为环境实现的最终状态，而无需操心如何实现达到该最终状态的逻辑。如果所包含的操作集还不够，您可以使用 CM 工具带有的扩展系统来开发自己的模块。 尽管可以使用这些扩展系统，也请尽量在适用时使用预定义的模块和插件，以避免额外的开发和维护负担。

需要配置环境时，可以使用 CM 工具。您还可以使用它们来预配基础架构并为工作负载实现部署流程。与完全手动的预配、配置和部署流程相比，CM 工具是更好的处理方式，因为它可重复执行、受控且可审核。但是，CM 工具也存在一些弊端，因为这些工具不是专为预配或部署任务设计的。它们通常缺少内置的功能来实现精细的预配逻辑（例如检测和管理基础架构的实际状态与所需状态之间的差异）或者丰富的部署流程（例如无停机时间的部署或蓝绿部署）。 您可以使用上文提到的扩展点来实现缺少的功能。这些扩展程序可能会带来额外的工作量，并可能增加部署过程的整体复杂性，因为您需要具备设计、开发和维护定制化部署解决方案所需的专业知识。

您可以使用 Ansible、Chef、Puppet、SaltStack 等工具实现这类预配、配置和部署流程。

使用容器编排工具进行部署

如果您已经投资或计划投资于工作负载容器化，则可以使用容器编排工具来部署您的工作负载。

容器编排工具负责管理支持您的环境的基础架构，并支持各种部署操作和构建块，以实现在内置逻辑不足时使用的部署逻辑。借助这些工具，您可以专注于使用其提供的机制来编排实际部署逻辑，而无需自行实现。

容器编排工具还提供了抽象功能，可用于将部署流程广泛用于不同的底层环境，因此您不必为每个环境设计和实现多个流程。例如，这些工具通常包含用于扩缩和升级部署的逻辑，因此您无需自行实现它们。您甚至可以开始使用这些工具在当前环境中实现部署流程，然后将它们转移到目标环境中，因为在设计方面，实现方式大体相同。尽早采用这些工具，您将能够积累管理容器化环境的经验，这种经验对于迁移到 Google Cloud 而言非常有用。

如果您的工作负载已经被容器化，或者您将来可以对其进行容器化，并且计划投资于此，则可以使用容器编排工具。在后一种情况下，您应该对每个工作负载进行彻底分析，以确定以下内容：

  • 确保可以对工作负载进行容器化。
  • 评估容器化工作负载可能获得的潜在收益。

如果容器化的潜在弊端远大于益处，则只有在团队已经决定使用容器编排工具并且您不希望管理异构环境的情况下，才应使用容器编排工具。

例如，数据仓库解决方案通常不使用容器编排工具进行部署，因为它们并非设计为在临时容器中运行。

您可以使用 Google Kubernetes Engine (GKE) on Google Cloud 实现此部署流程。如果您对无服务器环境感兴趣，则可以使用 Cloud Run 等工具。

自动部署

无论您在环境中使用什么样的预配、配置、部署和编排工具，都可以实现完全自动化的部署流程，以最大程度地减少人为错误，并整合、简化和标准化整个组织中的流程。如有需要，您还可以在部署流程中加入人工审批步骤，但是每个步骤都是自动执行的。

典型的端到端部署流水线步骤如下：

  1. 代码审核。
  2. 持续集成 (CI)。
  3. 制品生产。
  4. 持续部署 (CD)，包括最终的手动审批。

您可以独立于其他步骤自动执行每个步骤，从而逐步将当前的部署流程迁移到自动化解决方案，也可以直接在目标环境中实现新的流程。 为使此流程生效，您需要在流水线的每个步骤中执行测试和验证过程，而不仅限于代码审核步骤或持续集成步骤。

对于代码库中的每项更改，您应执行全面的审核以评估更改的质量。大多数源代码管理工具都对代码审核提供一流的支持。它们还会频繁查看已修改的源代码区域来支持审核的自动创建和初始化，前提是您配置了负责代码库各个区域的团队。在每次审核中，您还可以对源代码运行自动检查，例如 linter 和静态分析器，以在整个代码库中实施一致性和质量标准。

审核更改并集成到代码库后，持续集成工具可以自动运行测试、评估结果，然后通知您当前构建的任何问题。您可以按照测试驱动型开发的过程为每个工作负载的功能执行完整的测试，从而使该步骤更具价值。

对于每个成功的构建，您都可以自动创建部署工件。这些工件代表具有最新更改、且准备好部署的工作负载版本。在创建工件时，您还可以对工件本身执行自动验证。例如，您针对已知问题运行漏洞扫描，并仅在未找到漏洞的情况下才批准该工件用于部署。

最后，您可以在目标环境中自动部署每个已审批的工件。如果您有多个运行时环境，则还可以为每个环境实现唯一的部署逻辑，甚至在需要时添加手动审批步骤。例如，您可以在开发、质量保证和测试环境中自动部署工作负载的新版本，同时仍需要生产控制团队的手动审核和批准才能在生产环境中进行部署。

如果需要自动化、结构化、精简且可审核的流程，则完全自动化的端到端流程是最佳方案之一，但实现此流程并非易事。在选择此类流程之前，您应该清楚了解预期收益、所需投入的成本，以及您当前的团队知识和专业水平是否足以实现完全自动化的部署流程。

您可以使用 Cloud Deploy 实现完全自动化的部署流程。

后续步骤