使用 Deployment Manager 的最佳做法

本页面介绍了使用 Google Cloud Deployment Manager 创建部署的最佳做法。本页面专为熟悉 Deployment Manager 的用户设计，并未介绍如何使用 Deployment Manager。

如果您刚接触 Deployment Manager，请查看快速入门。

管理资源

❑  
在部署过程中创建资源后，如果需要修改资源，请使用 Deployment Manager。如果您修改资源时未使用 Deployment Manager，而是使用 Google Cloud 控制台或 gcloud 等方式，则在尝试修改原始部署中的资源时，您可能会看到错误。

如果要在不删除资源的情况下从部署中移除资源，请按照以下步骤操作：

  1. 在部署配置中，删除该资源的定义。
  2. 更新部署，并在 `gcloud` 命令中添加 --delete-policy ABANDON。这样，资源将不再与部署关联，然后您便可以使用 Google Cloud 控制台或 gcloud 修改资源。
❑  
如果您的部署中有 Compute Engine 实例并且希望将永久性磁盘挂接到实例，请将磁盘与实例分开定义，以便您可以轻松对其进行管理。例如，在以下部署中，磁盘 example-disk 是与实例 example-instance 分开定义的。为了挂接磁盘，配置具有对磁盘的引用：
    resources:
    # instance
    - name: example-instance
      type: compute.v1.instance
      properties:
        disks:
          - type: PERSISTENT
            source:$(ref.example-disk.selfLink)
   # disk
   - name: example-disk
     type: compute.v1.disk
     properties:
       zone: us-central1-a
       sizeGb: 10
       type: ...
❑  

如果要使用 Deployment Manager 创建和管理专用 Google Kubernetes Engine (GKE) 集群，请在您的部署中设置以下 privateClusterConfig 和 ipAllocationPolicy 选项。

     privateClusterConfig:
        enablePrivateNodes: true
        enablePrivateEndpoint: true
        #  Configure the IP range for the hosted master network
        masterIpv4CidrBlock: IP_RANGE
      ipAllocationPolicy:
        useIpAliases: true
        createSubnetwork: true

如需了解使用 GKE 创建专用集群时的要求和其他注意事项，请阅读设置专用集群。

在部署中附上凭据

❑  
Deployment Manager 会隐去 YAML 配置中属性的凭据的相关字段。隐去会基于属性的键触发。以下示例演示了一种此类隐去：
    # Config provided to Deployment Manager
    resources:
    - name: example-resource
      type: gcp-types/service-v1:sample-type-with-password
      properties:
        zone: us-central1-a
        username: test-user
        password: hunter2

   # Config as surfaced by Deployment Manager
   resources:
    - name: example-resource
      type: gcp-types/service-v1:sample-type-with-password
      properties:
        zone: us-central1-a
        username: test-user
        password: (redacted)
❑  
如果在部署的 Jinja 或 Python 模板中添加了凭据，则该凭据会从生成的扩展配置和布局文件中隐去，但在原始导入文件中仍可见。因此，我们强烈建议将您有意对密文保密的所有凭据放在顶层 YAML 配置中。您可用模板属性对其进行引用。
❑  
YAML 文件或项列表中键值对中包含的任何凭据都不会隐去，如以下示例所示。因此，我们强烈建议您不要在 YAML 文件或项列表中以键值对的形式向 Deployment Manager 提供凭据。
    # Not a valid instance configuration, used solely for demonstration
    resources:
    - name: example-resource
      type: gcp-types/compute-v1:instances
      properties:
        zone: us-central1-a
        disks:
        - autoDelete: true
          boot: true
    # Will not be redacted
          password: hunter2

构建模板

❑  
要加快定义模板的速度，请考虑使用 Cloud Foundation Toolkit 项目中可正式投入使用的示例模板。
❑  
如果您有复杂的基础架构要求，例如需要创建多个环境，请阅读大规模使用 Deployment Manager 的教程并查看其中的示例。
❑  
使用 Python 构建模板。您可以使用 Python 或 Jinja2 来创建模板。Jinja 更容易上手，但对于可能需要将许多资源拆分到多个环境的复杂部署，Python 更灵活。
❑  
构造您的配置文件（YAML 文件），使其只使用一种类型，并将顶层模板用作该类型，来调用所有其他模板。采用这种做法，您可以更容易地将一组模板更改为复合类型。
❑  
使用架构文件。架构定义了一组配置文件使用特定模板必须遵循的规则。通过定义架构并鼓励其他人查看架构中定义的要求，您的用户可以轻松了解相应的模板有哪些可设置或需要的属性。这有助于用户使用配置，而无需调查模板的详细信息。至少，用户可以定义用于顶层模板的架构文件。
❑  
使用模板属性和输出。通过属性和输出，您可以将区域、机器大小、机器数量、应用状态（测试、生产和预演）等变量传入模板中，然后获得输出值（如虚拟机实例的 IP 地址和 selfLink）。属性和输出让模板具有灵活性，使其可以重复使用而无需修改基础模板。
❑  
使用您导入主配置文件的各个独立模板文件。这为您提供了一种更易于管理的配置方式。
❑  
将您的配置分解为逻辑单元。例如，为有状态服务（如数据库和存储分区）和更为瞬时性的服务（如前端实例）创建各自的配置。
❑  
使用引用。那些在资源创建后才得到定义的值应该使用引用，例如资源的 selfLink、IP 地址或系统生成的 ID。如果没有引用，Deployment Manager 将并行创建所有资源，无法保证以正确的顺序创建依赖资源。使用引用将强制执行创建资源的顺序。
❑  
预览部署可以评估进行更新将如何影响部署。预览配置时，Deployment Manager 不会实例化任何实际资源，而是展开完整配置并创建“空壳”资源。这让您可以在提交前先查看对部署的更改。
❑  
检查特定资源的 API 方法，以了解执行更新的含义。更新部署时设置更新政策，这可帮助您控制 Deployment Manager 将如何应用每个更新。
❑  
为您的资源使用标签。如果您定义的资源支持标签，请用标签标记您的资源。标签可以帮助对属于不同部署的资源进行分类，也可以区分资源可能所处的阶段，例如资源是支持生产环境还是测试环境。

管理部署的大小

Deployment Manager 可处理大量资源，但受配额限制的约束。如果您想要降低创建、更新或删除部署所需的时间，则可以减少每个部署中的资源数量。

❑  
如果一组资源不依赖于该组外部的任何资源，则可以将这组资源移至单独的部署中。例如，如果您的部署包含多个模板，则您可以将每个模板打包为单独的部署。
❑  
从配置中移除不必要的资源。如果您日后需要更多资源，则可以在那时向部署添加更多资源。
❑  
（可选）将部署限制为不超过 1000 个资源。

权限

默认情况下，Deployment Manager 使用 Google API 服务账号的凭据向其他 API 进行身份验证。Google API 服务账号专门用于代表您运行内部 Google 流程。

如果要授予其他用户对 Deployment Manager 项目的访问权限，则需要向用户授予具有相应 Deployment Manager 使用权限的 IAM 角色。您可以使用多种预定义的 IAM 角色来确定用户调用 Deployment Manager 需要的具体访问权限。

❑  
使用 IAM 角色对授予用户的 Deployment Manager 使用权限进行限制。
❑  
如果您希望用户能够访问 Deployment Manager 创建的资源，请向用户授予使用资源所需的角色，但不要授予他们直接部署资源的权限。
❑  
为主账号授予 owner 角色可允许他们修改 IAM 政策。因此，只有当成员因合法目的而需要管理 IAM 政策时才授予其所有者角色，因为您的政策包含敏感的访问权限控制数据。有尽可能少的用户参与政策管理，将会简化可能必须进行的任何审核。
❑  
Deployment Manager 使用 Google API 服务账号来创建和管理您的资源。如果您使用 Deployment Manager 来管理关键资源（如自定义 IAM 角色），则必须为默认的 Google API 服务账号分配其他 IAM 角色。例如，如果要使用 Deployment Manager 创建和管理自定义 IAM 角色，您必须将 Role Administrator 角色分配给 Google API 服务账号。

如需简要了解 Google API 服务账号，请参阅 Google 管理的服务账号。

如需了解将角色分配给服务账号的步骤，请参阅为服务账号授予角色。

自动化

请考虑将创建项目以及创建项目中所含的资源自动化。这使您可以采用基础架构即代码方法进行项目预配。这种方法具备多种优势，例如能够：

  • 在向需要访问 Google Cloud 资源的团队提供项目时，允许执行公司要求。
  • 提供一系列可快速轻松预配的预定义项目环境。
  • 利用版本控制来管理基本项目配置。
  • 确信您正在部署的项目配置可重现且一致。
  • 将创建项目整合在自动预配过程中。
❑  
首先，利用 GitHub 上提供的模板自动创建项目。

持续集成 (CI) /持续部署 (CD)

将 Deployment Manager 作为 CI/CD 流水线的一部分。

❑  
不要将 CI/CD 流水线用于创建和删除整个测试和 QA 项目。
  • 您可能会选择销毁可能产生额外费用的虚拟机实例或资源，但请考虑留下可能需要一段时间才能重新创建的可重复使用资产，因为删除这些资源可能会对完成构建流水线所需的时间产生负面影响。设置网络、子网或防火墙规则不需要任何费用。
  • 请注意，如果您删除项目，该项目将会占用项目配额几天，直到项目完全删除。这也意味着您无法重复使用项目名称。
  • 您可以使用 Deployment Manager 轻松地从项目中删除资源，这样就不会占用资源配额。
❑  
在初始设置过程中，使用 Deployment Manager 创建项目和网络配置的有状态部分，并在 CI/CD 过程之外部署它们。测试完成后，您可以删除仅包含在流水线中部署的无状态资源的部署。
❑  
在 CI/CD 过程中，请使用单独的配置将资源部署到测试和 QA 项目。完成测试后，您可以使用 Deployment Manager 从测试和 QA 项目中删除资源。
测试部署。Deployment Manager 可以将资源预配整合在 CI/CD 流水线中，让您将项目配置作为代码轻松测试，复制当前生产环境或当前环境的一致副本，并应用更改以进行保密测试。
❑  
使用版本控制。在开发过程中对部署使用版本控制系统有以下作用：
  • 还原到之前已知良好的配置。
  • 提供对更改的审计跟踪。
  • 将配置用作连续部署系统的一部分。