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

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

本文档是关于迁移到 Google Cloud 的系列文章中的一篇。如果您想要了解该系列文章,请参阅迁移到 Google Cloud:选择迁移路径

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

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

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

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

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

  1. 使用容器编排工具进行部署
  2. 自动部署
  3. 通过应用 IaC 模式进行部署

下图展示了此迁移的路径:

从手动部署迁移到自动部署的迁移路径。

在每个迁移步骤中,您会按照《迁移到 Google Cloud:使用入门》中定义的阶段执行操作:

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

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

迁移路径包含四个阶段。

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

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

迁移到容器编排工具

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

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

评估和发现工作负载

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

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

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

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

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

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

规划和构建基础

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

创建 Google Cloud 组织文件夹项目时,请考虑跨多个环境共享部署流程。 我们建议使用面向功能的层次结构面向精细访问的层次结构。这些层次结构提供了管理资源所需的灵活性,以及具有多个用于开发和测试的环境的可能性。

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

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

通过使用容器编排工具,您不必担心在部署新的工作负载时预配基础架构。例如,您可以根据需要使用集群自动扩缩程序自动调整 GKE 集群的大小。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

优化环境

实现部署流程后,您可以使用容器编排工具开始优化部署流程。迁移到 Google Cloud:使用入门文档包含有关如何优化环境的指南。

此优化迭代的要求如下:

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

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

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

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

迁移到部署自动化

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

评估和发现工作负载

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

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

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

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

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

规划和构建基础

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

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

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

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

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

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

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

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

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

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

优化环境

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

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

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

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

鉴于部署流程具有完全自动化的特性,我们建议您设计和实现紧急访问权限流程,以便在不使用常规部署流程的情况下与运行时环境交互。只有在特殊情况下并且经过您团队的高级成员预批准,您才能使用此流程。例如,如果部署流程的问题导致您无法访问环境,您可以使用紧急访问权限流程来回滚导致该问题的更改。

采用基础架构即代码

在您的团队知道如何有效使用 Google Cloud 后,您便可以应用 IaC 模式了。IaC 是一个过程,在该过程中,您可以按照处理工作负载源代码的方式处理运行时环境中的资源预配。

评估和发现基础架构

在此评估阶段,您将深入了解在之前的迁移步骤中预配的基础架构,包括:

  • 您配置为基础架构的一部分的 Google Cloud 资源。
  • 您当前设置的变更管理流程。
  • 您的组织中有权修改基础架构的成员。

具有基础架构中当前资源的清单对于采用 IaC 至关重要,因为在此迁移步骤中,您必须使用代码来描述这些资源。

变更管理流程对于管理基础架构的演变很重要。如果您有任何流程,可以对其进行调整以处理 IaC。如果您的基础架构没有任何变更管理流程,则可以通过此阶段设计和实现这样一个流程。变更管理流程应至少包含一个审核阶段,您可以在此阶段中分析建议的更改。此分析以及有关哪些团队成员可以修改基础架构的评估,对于降低因基础架构更改而导致停机或意外计费的几率很重要。

规划和构建基础

要扩展您在上一步中构建的基础,您需要预配和配置基础架构以支持采用 IaC。

首先,您需要选择要采用的工具。Google Cloud 上提供了以下一些常用工具:

  • Deployment Manager,这是一种代管式服务,完全支持所有 Google Cloud 资源。
  • Terraform,这是一种开源预配工具,支持 Google Cloud 和其他云服务商。
  • ChefPuppetAnsible,它们是支持 Google Cloud 的开源配置工具。

选择 IaC 工具后,您需要预配和配置所有必要的基础架构以支持这些工具。您至少需要以下项:

  • 源代码库,用于管理资源的描述符并对其进行版本控制。
  • 一种代码审核工具,用于在每项更改发布之前对其进行分析和批准。
  • 一种运行时环境,用于在团队在审核期间批准更改后执行 IaC 工具。

一些 IaC 工具需要服务来管理基础架构。例如,如果您希望与组织中的其他成员协作来管理您的基础架构,则 Terraform 需要远程数据存储

如果您选择使用 IaC 工具来管理此基础,我们建议您实施保护措施,以免在应用更改时破坏该基础。 这些破坏可能会导致较长的停机时间以及无法恢复的数据丢失。例如,如果您意外删除存储基础架构描述符的源代码库,则可能会导致无法恢复的数据丢失。您可以使用安全锁等工具来防止删除项目。

使用 IaC 预配 Google Cloud 资源

当 Google Cloud 环境准备就绪后,您可以采用 IaC 来管理环境中的资源:

  • 使用代码描述现有资源。
  • 使用 IaC 预配新资源。

在上述迁移步骤中,您使用 Cloud ConsoleCloud SDKCloud API 预配了 Google Cloud 资源。 在此阶段,您将按照所选 IaC 工具的语法和惯例,使用代码描述这些资源。

您可能需要导入工具清单中的当前资源和实例,使 IaC 工具知道这些资源和实例。您选择的 IaC 工具没有关于当前资源和实例的状态信息。您必须导入资源或者手动销毁这些实例并让 IaC 工具重新创建它们。例如,Terraform 可以导入您的现有基础架构

如果必须在基础架构中定义新组件,您现在可以直接使用代码描述这些组件,而无需执行任何其他预配过程。

优化环境

采用 IaC 之后,您可以执行另一优化迭代。此迭代具有以下要求:

  • 根据需要扩展监控系统。
  • 扩展测试套件以覆盖您的基础架构。
  • 自动预配和配置基础架构。
  • 扩展紧急访问权限流程,以覆盖您的基础架构。

基于在上一部署阶段上一迁移步骤的优化阶段执行的操作,您可以将监控扩展到支持 IaC 采用的基础架构。例如,您可以监控运行 IaC 工具的所有运行时环境,并准确记录每次执行,以构建可供日后检查的审核跟踪。

您可以扩展测试套件以覆盖基础架构,而不仅仅覆盖工作负载和容器映像。您可以使用 InSpecServerSpecRSpec 等工具为您的运行时环境运行合规性测试套件。您可以防止基础架构遭到手动更改或来自 IaC 流水线外部的更改。通过针对基础架构持续运行测试套件,您可以检测到未经授权的更改并纠正这种情况。

确定采用 IaC 后,可以考虑通过设计和实施新流程来实现基础架构的自动预配。这些新预配流程与您用于生产和部署工件的流程大不相同。 基础架构预配流程用于处理对基础架构(而非应用)的更改。因此,与工件生产和部署流程相比,这些流程解决的是不同的问题,并且具有不同的错误波及范围和影响。当基础架构的某个元素发生故障时,错误波及范围会描述此故障产生的影响。例如,如果部署了有故障的工件,则可能会导致服务中断,从而影响一个或多个使用场景。如果预配了有故障的基础架构组件,则可能的服务中断可能会影响环境中的多个(如果并非全部)服务。

寻求帮助

Google Cloud 提供以下支持资源:

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

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

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

后续步骤