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

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

本文是以下系列文章中的一篇:

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

迁移路径包含四个阶段。

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

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

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

  1. 手动部署。
  2. 使用配置管理 (CM) 工具进行部署。
  3. 使用容器编排工具进行部署。
  4. 自动部署。
  5. 通过应用基础架构即代码模式进行部署。

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

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

手动部署

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

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

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

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

您可以使用 Google Cloud ConsoleCloud ShellCloud APICloud SDK 等工具实现完全手动预配、配置和部署流程。

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

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

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

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

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

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

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

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

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

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

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

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

您可以使用 Kubernetes 等工具以及 Google Cloud 上的 Google Kubernetes Engine (GKE) 等代管式服务来实现此部署流程。如果您对无服务器环境感兴趣,可以使用 App Engine 柔性环境Cloud FunctionsCloud Run 等工具。

自动部署

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

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

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

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

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

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

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

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

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

您可以使用 SonarQubeJenkinsCloud BuildContainer RegistrySpinnaker 等工具实现完全自动化的流程。

通过应用基础架构即代码模式进行部署

基础架构即代码是一种流程,在这种流程中,您使用与处理工作负载的源代码相同的方式来处理运行时环境中的资源预配。 例如,您可以使用 Cloud API 全面管理 Google Cloud 资源的整个生命周期,并在源代码中标准化最终状态。然后,您可以为您的基础架构实现完全自动化的预配流程(该流程类似于您为工作负载实现的流程),并为此流程添加全面的测试套件。

预配工具旨在引导您的基础架构,将其准备就绪以便进行配置。它不适合完成配置任务。因此,在预配基础架构中的所有资源后,应使用 CM 工具根据需要配置这些资源。虽然您可以使用预配工具完成配置任务,也可以使用 CM 工具完成预配任务,但它们是为特定目的而设计的,并且可以相互补充。 您应使用正确的工具来完成对应的作业,因此请使用预配工具预配基础架构,并使用 CM 工具进行配置。

如果您可以完全使用 API 来管理目标环境中的资源(例如在 Google Cloud 中),则应实现基础架构即代码流程。您将立即获得整个云基础架构的完全可审核性和版本控制。此外,您甚至可以实现持续集成和持续部署 (CI/CD) 流程,以自动将更改应用于基础架构。

另一方面,如果目标环境不提供用于管理和配置资源的编程访问权限,则无法实现基础架构即代码部署。另外,您应该咨询采购部门,因为在云环境中进行资源预配和取消预配会导致结算和支出方面存在差异。

您可以使用 Terraform 等工具和 Deployment Manager 等代管式服务来实现基础架构即代码流程。您也可以使用 RSpecServerspecInSpec 等工具为基础架构实现测试套件。

总结

现在您已经了解了不同的方案、何时应使用它们、何时应避免使用它们,并了解了一些示例工具,下面的图表可以帮助您轻松比较和对比适用于您的工作负载和使用场景的各个方案。

部署流程类型 何时使用 何时避免 工具和服务
完全手动部署 当您需要在沙盒环境中快速检测实验,或者在缺少必要的管理 API 的裸机环境或旧版虚拟化基础架构中进行处理时 当存在可管理性更强的替代方法时
使用 CM 工具进行部署 当您需要一种自动化手动部署的方法并且已经在用于配置环境的 CM 工具上投入大量资金时 当您在克服使用 CM 工具进行部署的局限性方面需要过高的投入时 AnsibleChefPuppetSaltStack
容器编排 当您的工作负载已经被容器化,或者将来可以对其进行容器化,并且您计划投资于此时 当潜在的弊端远大于容器化的益处时 KubernetesGKEApp Engine 柔性环境Cloud FunctionsCloud Run
部署自动化 当您需要自动化、结构化、精简且可审核的流程时 当您的团队成员缺乏必要的技能并且没有机会接受培训,或者您无力承担实现完全自动化流程所需付出的精力时 SonarQubeJenkinsCloud BuildContainer RegistrySpinnaker
基础架构即代码 当目标环境中的资源可以完全通过 API 以编程方式进行管理时 当目标环境不提供用于管理和配置资源的编程访问权限时 TerraformCloud Deployment Manager

并不存在最佳部署流程,因为您应采用的部署流程完全取决于您当前的具体状况、专业知识水平以及您期望该流程达到的效果。

寻求帮助

Google Cloud 提供了各种选项和资源,方便您获取必要的帮助和支持,以充分利用 Google Cloud 服务:

  • 自助资源。如果您不需要专属支持,则可以按照自己的进度使用各种选项。
  • 技术合作伙伴。Google Cloud 已与多家公司达成合作,便于您使用 Google Cloud 产品和服务。
  • Google Cloud 专业服务。我们的专业服务可以帮助您充分利用在 Google Cloud 中的投资。

Google Cloud 迁移中心提供了更多资源来帮助您将工作负载迁移到 Google Cloud。

如需详细了解这些资源,请参阅《迁移到 Google Cloud:使用入门》中的“寻求帮助”部分

后续步骤