Google ACE: 部署、配置和自动化 — 学习指南

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

属于 Google Associate Cloud Engineer — 学习指南. 使用经过验证的答案练习： Google 考试中心, 或参加限时模拟考试： ExamRoll.io.

概览

Google Cloud 上的部署、配置和自动化专注于可重复、可审计且安全的变更交付。良好的实践依赖于基础设施即代码 (IaC)、声明式模板、不可变构件和标准化流水线。卓越运营源于幂等性设计、变更预览、策略强制执行以及规划具有明确回滚路径的受控发布。以下各节提供了实用模式、命令示例、设计选择背后的原因，包括常见的陷阱和权衡。

基础设施即代码和配置基础

原则：

• 声明式模板描述期望的最终状态；工具会协调实际状态以使其匹配。这提高了幂等性、可重复性和可审计性。
• 不可变基础设施通过部署新实例或新版本来代替原地修改，从而简化回滚并减少偏差。
• 关注点分离：参数化特定于环境的值，同时重用共享模块或模板。

Google Cloud 上的 Terraform：

• 配置：HCL 文件定义资源、变量和输出。使用模块来封装 VPC、服务账号或 GKE 集群；在内部发布共享模块以实现模式标准化。
• 状态：保持状态远程存储并进行版本控制。使用带有对象版本控制和存储桶保留策略（如果适用）的 Cloud Storage 后端。
  • 后端块示例：

undefined

• 故障模式：本地状态或未版本化的存储桶存在数据丢失和并发写入的风险。对状态存储桶强制执行最小权限访问；优先使用短期凭证和服务账号模拟，而不是密钥。
• 计划与应用：terraform plan 提供预览；在 CI/CD 中通过人工审批来控制生产环境的应用（apply）。谨慎使用 -target；频繁使用会增加偏差风险。
• 模块：对模块进行语义化版本控制；固定版本以避免意外变更。在应用前使用 terraform validate 和策略检查进行验证。
• 导入与偏差：terraform import 将现有资源纳入管理；之后需仔细审查状态。通过定期运行 terraform plan 来检测偏差。
• 远程执行：在 Cloud Build 或 Cloud Run 作业中使用 Workload Identity Federation 运行 Terraform，以避免使用服务账号密钥。缓存 provider 以减少构建时间。

Deployment Manager：

• 虽然许多团队都以 Terraform 为标准，但您也可能会遇到 Deployment Manager。通过更新配置来无停机更新部署：

undefined

配置标准：

• 命名：应用一致且可解析的名称，包含环境、区域、用途和序列，例如 vpc-prod-usw1-core。
• 标签：为所有资源附加 env、cost_center、owner 和 app 等标签；通过策略或验证来强制执行。
• 标记 (Tag)：使用网络标记来限定防火墙规则的范围；避免将标记过度用于身份或所有权（标签是更好的选择）。
• 元数据：利用实例元数据进行启动脚本和配置；优先使用带有校验和或版本标志的元数据来控制重复运行。避免将密钥放入元数据中；应使用 Secret Manager。

API、服务启用、配额和服务账号：

• 在自动化的早期阶段启用所需的服务：

undefined

• 在规划期间验证配额余量；规模测试应包括配额检查以避免被限制。
• 为每个工作负载和环境使用专用的服务账号；在最小范围内授予最小权限的 IAM 角色。对于人工访问，优先使用群组成员身份；对于自动化，优先使用服务账号模拟。

交付流水线和构件提升

Cloud Build：

• 定义 Cloud Build 步骤来构建、测试和打包构件。使用替换变量来处理动态值，并使用 Secret Manager 管理凭证。
• 根据源代码变更触发构建；按代码库或环境隔离构建服务账号，并仅授予所需权限。
• 缓存 Docker 层和语言依赖项以缩短构建时间。注意并发构建限制和临时工作器配额。

构件提升：

• 将容器镜像或语言包存储在 Artifact Registry 中。通过以下方式进行提升：
  • 为不可变摘要重新打上环境标签（例如，:qa、:prod），或
  • 将构件复制到特定于环境的代码库中。
• 权衡：使用标签的单一代码库简化了发现过程，但需要严格的治理；每个环境使用独立的代码库则加强了隔离和策略执行。

Cloud Deploy：

• 使用有序的目标（例如，dev → qa → prod）来建模交付流水线。版本（Release）会引用特定的构件摘要和部署清单。
• 对于 GKE 和 Cloud Run，Cloud Deploy 使用 Skaffold 配置来渲染和应用清单。配置审批、验证和门控。
• 发布和回滚：
  • 通过增量流量转移进行金丝雀发布可以减小爆炸半径。
  • 蓝/绿部署以额外的容量为代价，实现了快速切换和回滚。
  • 通过固定到上一个良好版本来进行回滚；避免会造成偏差的原地修复。
• 故障模式：集群权限不匹配、API 缺失以及清单架构错误。通过在构建期间渲染清单并根据集群策略进行验证来及早发现问题。

安全变更规划：

• 对生产环境的变更要求进行预览（plan 或 render）、自动化测试、策略验证和人工审批。
• 对于 Compute Engine 代管实例组，当应用就绪速度较慢时，应调整更新策略中的 maxSurge/maxUnavailable 和健康检查设置，以避免过度预配。

命令行操作与环境管理

Cloud Shell 和 gcloud 配置：

• Cloud Shell 提供了一个托管的管理环境，其中包含预先通过身份验证的 gcloud 和一个持久化的主目录。
• 使用命名配置可快速切换账号、项目和区域： gcloud config configurations create prod gcloud config set project my-prod gcloud config set compute/region us-central1 gcloud config set compute/zone us-central1-a gcloud config configurations activate prod
• 使用 gcloud config list 检查当前活动的配置。对于 GKE，获取凭据： gcloud container clusters get-credentials my-cluster –region us-central1

Compute 命令模式：

• 创建具有预留内部 IP 的虚拟机： gcloud compute addresses create license-ip –region=us-central1 –subnet=default –addresses=10.0.3.21 gcloud compute instances create license-server –zone=us-central1-a –subnet=default –private-network-ip=10.0.3.21 –tags=license
• 创建自定义 VPC、子网和防火墙规则： gcloud compute networks create core –subnet-mode=custom gcloud compute networks subnets create core-us –network=core –range=10.0.0.0/20 –region=us-central1 gcloud compute firewall-rules create allow-https –network=core –allow=tcp:443 –target-tags=web

IAM 模式：

• 在项目范围授予角色： gcloud projects add-iam-policy-binding my-project –member=group:ops@example.com –role=roles/logging.viewer
• 跨项目复制自定义角色： gcloud iam roles copy myCustomRole –source=my-dev –destination=my-prod

Storage 模式：

• 创建存储桶并上传对象： gcloud storage buckets create gs://backups-prod –location=us-central1 –class=coldline –uniform-bucket-level-access gcloud storage cp ./backup.tar.gz gs://backups-prod/
• 通过文件配置生命周期，并使用 gcloud storage buckets update –lifecycle-file=policy.json 应用配置

API 启用与验证：

• 为应用启用 Pub/Sub： gcloud services enable pubsub.googleapis.com
• 列出已启用的服务： gcloud services list –enabled

治理、漂移与自动化

配置漂移与策略执行：

• 通过按计划运行 terraform plan 来检测漂移；在出现意外变更时使构建失败。
• 在应用（apply）前，通过“策略即代码”（policy-as-code）强制执行组织策略约束（例如，限制外部 IP）并验证资源配置。
• 对于 Kubernetes，使用 Config Sync 和 Policy Controller 持续协调并阻止不合规的变更。
• 可审计性：依赖管理员活动（Admin Activity）和数据访问（Data Access）日志；路由到 BigQuery 进行分析。使用 Cloud Asset Inventory 进行时间点和时序状态查询。

配额与限制：

• 检查每个区域和项目的配额；为自动扩缩和发布规划冗余空间： gcloud compute regions describe us-central1 –format=“yaml(quotas)”
• 在计划增长或大规模发布之前申请增加配额。

自动化运维任务：

• Cloud Scheduler 按 cron 计划触发 HTTP 端点、Pub/Sub 主题或 Workflows。确保处理程序是幂等的；配置重试和死信主题。
• Workflows 跨 Google API 编排多步骤自动化，支持重试、并行步骤和补偿逻辑。
• Cloud Run 作业可按需或通过 Scheduler 执行容器化的批处理或管理任务。对于一次性或迭代性工作负载，优先使用作业；为作业的服务账号授予最小权限。

发布安全性与可观测性：

• 将健康检查（health checks）和就绪探针（readiness probes）内置于服务中。对于启动缓慢的 MIG，增加初始延迟以防止过早的扩缩容操作。
• 收集部署指标和错误预算；当 SLO 下降时，暂停或自动中止发布。

实际问题场景

Altostrat Media 需要为其基于 GKE 的服务标准化多环境部署，同时消除配置漂移并确保快速回滚。他们还必须为一个旧版的许可证服务器保留一个固定的内部 IP，而无需重新配置应用程序。

1. 创建基础 Terraform 模块和远程状态

• 为 VPC、子网、GKE、服务账号和防火墙规则实现模块。为状态存储桶配置一个带有版本控制和保留策略的 Cloud Storage 后端。
• 理由：模块化促进了复用和一致性；远程、版本化的状态支持协作、可恢复性和锁定。

2. 启用所需服务并建立最小权限自动化身份

• 启用 compute.googleapis.com、container.googleapis.com、clouddeploy.googleapis.com、artifactregistry.googleapis.com。
• 为 Terraform、Cloud Build 和 Cloud Deploy 创建每个环境的服务账号；授予最小角色（例如，将 roles/container.admin 授予部署者，而非构建者）。
• 理由：预先启用服务和限定角色范围可以减少部署失败并限制爆炸半径。

3. 配置网络并预留旧版 IP

• 使用 Terraform 创建自定义 VPC、区域子网以及基于网络标签的防火墙规则。
• 预留内部 IP： gcloud compute addresses create license-ip –region=us-central1 –subnet=core-us –addresses=10.0.3.21
• 理由：声明式网络确保了可重复性；预留 IP 保留了应用程序的假设。

4. 使用 Cloud Build 构建工件并发布到 Artifact Registry

• 定义 cloudbuild.yaml 以运行测试、构建容器、扫描，并将不可变的摘要推送到 Artifact Registry。
• 理由：不可变的、经过扫描的工件是安全晋级和来源追溯的基础。

5. 配置具有 dev → qa → prod 目标的 Cloud Deploy 流水线

• 定义交付流水线和目标；引用 Skaffold 配置来渲染清单（manifests）。要求对 prod 环境进行手动批准并配置验证。
• 理由：结构化的晋级强制执行了控制；针对每个目标的策略可避免意外的生产部署。

6. 使用金丝雀策略和健康门禁推出 GKE 更新

• 使用金丝雀发布策略，根据 SLO 和错误率检查，将流量分阶段切换到 10%、50%，然后是 100%。
• 理由：渐进式交付降低了风险，并提供了自然的回滚点。

7. 通过定时的计划和策略检查消除漂移

• 夜间作业运行 terraform plan 和一个“策略即代码”验证器；对意外的差异或违规行为发出警报。
• 理由：及早发现可以防止漂移累积并破坏未来的应用操作。

8. 使用预留 IP 将许可证服务器虚拟机投入运营

• 创建绑定到预留地址和相应标签的虚拟机： gcloud compute instances create license-server –zone=us-central1-a –subnet=core-us –private-network-ip=10.0.3.21 –tags=license
• 理由：在不更改应用程序的情况下确保其可达性；标签使防火墙规则的范围保持精确。

9. 使用 Scheduler、Workflows 和作业自动化周期性任务

• Cloud Scheduler 触发一个 Workflow，在不可避免的情况下轮换服务账号密钥，并启动一个 Cloud Run 作业来执行每周的数据库清理（vacuum）任务。
• 理由：集中式调度加上编排，通过重试和补偿机制，带来了可靠性和可观测性。

10. 规划回滚并验证就绪阈值

• 定义回滚预案，以重新晋级上一个正常的版本。调整就绪探针，对于任何基于 MIG 的工作负载，增加初始健康检查延迟以匹配应用的预热时间。
• 理由：预先规划的回滚和经过调整的健康检查可以防止在事件中发生级联故障和过度配置。

这种方法整合了不可变工件、声明式基础设施、门控式晋级和最小权限自动化，以在 Google Cloud 上实现安全、可审计和可重复的运维。

← 存储、数据库和数据服务 · 所有领域 · 监控、日志记录和运维排障 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Google →