基于Terraform与Google Cloud Serverless架构部署高可用Dify AI平台

1. 项目概述：为什么选择 Terraform 在 Google Cloud 上部署 Dify？

如果你正在寻找一个开箱即用、能快速搭建自己专属 AI 应用平台的方案，那么 Dify 绝对是一个绕不开的名字。它把大语言模型（LLM）的应用开发、编排和运营（LLMOps）流程做了高度抽象和可视化，让开发者甚至是不太懂代码的产品经理，都能通过拖拽的方式构建复杂的 AI 工作流。但问题来了，当你兴致勃勃地准备在云端部署 Dify 时，面对云服务商琳琅满目的产品——计算引擎、数据库、存储、网络、负载均衡——该如何下手？手动在控制台点点点不仅效率低下，更致命的是缺乏可重复性和版本管理，今天能跑通的配置，下个月可能就因为某个步骤记不清而出错。

这正是 DeNA 开源的dify-google-cloud-terraform项目要解决的核心痛点。这个项目不是教你如何手动配置，而是提供了一套完整的“基础设施即代码（IaC）”解决方案。它使用 Terraform 这个行业标准的工具，将 Dify 在 Google Cloud Platform (GCP) 上运行所需的所有资源，定义成了一份可版本控制、可一键部署、可重复执行的配置文件。简单来说，它把部署一个高可用、可扩展的 Dify 生产环境，从一门“手艺”变成了一道“填空题”。

我花了几天时间深度测试了这个项目，它的价值远不止于“一键部署”。它背后体现的架构思想，比如利用 GCP 的全托管服务（Serverless）来最大化运维效率、通过 Terraform 模块化设计来保证环境一致性，都是现代云原生应用部署的典范。接下来，我将带你彻底拆解这个项目，从架构设计、实操步骤到避坑指南，手把手教你如何利用这套方案，在 GCP 上搭建一个属于自己的、坚实可靠的 Dify AI 应用平台。

2. 架构深度解析：一张图看懂高可用 Dify 的云上布局

在动手之前，我们必须先理解我们要构建的是什么。dify-google-cloud-terraform项目提供的不仅仅是一个能运行的 Dify，而是一个面向生产环境、具备弹性伸缩和数据持久化能力的企业级架构。让我们结合项目提供的架构图，来拆解其中的每一个核心组件及其设计意图。

2.1 核心服务组件与职责

整个架构可以清晰地分为计算层、数据层、网络与安全层、以及运维支撑层。

计算层（无服务器化与弹性伸缩）：这是 Dify 应用本身运行的地方。项目没有采用传统的 Google Compute Engine (GCE) 虚拟机，而是选择了Cloud Run作为核心计算服务。这是一个至关重要的设计决策。Cloud Run 是一个全托管的容器化无服务器平台。这意味着：

• 无需管理服务器：你不需要操心虚拟机的操作系统更新、安全补丁或容量规划。GCP 完全托管底层基础设施。
• 极致弹性：当没有用户访问你的 Dify 应用时，Cloud Run 可以将实例缩容到零，不产生任何计算费用。当流量涌入时，它能在毫秒级内自动横向扩容，创建多个实例来处理请求。这对于 AI 应用可能出现的突发访问量非常友好。
• 按使用付费：你只为容器实际运行的时长付费，计量精度到 100 毫秒，成本效益极高。 项目将 Dify 拆分为两个独立的 Cloud Run 服务：dify-api和dify-web。前者负责所有后端业务逻辑和 AI 模型调用，后者则提供用户交互的前端界面。这种前后端分离的部署方式，使得我们可以独立地伸缩、更新和监控两个部分。

数据层（持久化与托管服务）：AI 应用的核心资产是数据——用户对话、知识库文件、应用配置等。项目使用Cloud SQL for PostgreSQL作为关系型数据库。Cloud SQL 是 GCP 全托管的数据库服务，自动处理备份、故障转移、打补丁和扩容。你无需成为 DBA 专家，也能获得一个高可用的 PostgreSQL 实例。对于 Dify 生成的文件（如上传的文档、生成的图片），项目使用Cloud Storage来存储。Cloud Storage 是一个无限容量、高持久性的对象存储服务，非常适合存储非结构化的二进制数据。将数据库和文件存储都托管给 GCP，确保了数据的持久性和可靠性，避免了因虚拟机宕机导致的数据丢失风险。

网络与安全层（隔离与访问控制）：安全是生产系统的基石。项目创建了一个独立的Virtual Private Cloud (VPC)网络。这个 VPC 就像一个私有的虚拟数据中心，将你的 Dify 相关资源（Cloud Run、Cloud SQL）与公网以及其他 Google Cloud 项目隔离开。Cloud SQL 实例被部署在这个 VPC 内部，并且没有分配公网 IP 地址。那么 Cloud Run 如何访问它呢？这里用到了一个关键特性：Serverless VPC Access。它为 Cloud Run 服务创建了一条通往 VPC 内部的私有通道，使得无服务器容器能够以私密、安全、低延迟的方式访问 VPC 内的资源（如 Cloud SQL），数据流量完全不经过公网，极大地提升了安全性。

运维支撑层（可观测性与交付）：为了监控应用的健康状况，项目集成了Cloud Monitoring和Cloud Logging。你可以在 GCP 控制台实时查看服务的请求量、错误率、延迟等关键指标，并查询详细的运行日志，这对于排查问题至关重要。在持续集成/持续部署（CI/CD）方面，项目脚本利用了Cloud Build和Artifact Registry。Cloud Build 根据 Dockerfile 自动构建dify-api和dify-web的容器镜像，并将构建好的镜像推送到私有的 Artifact Registry 仓库中。Cloud Run 服务则从该仓库拉取镜像进行部署，实现了容器化应用的自动化构建和发布流水线。

2.2 设计优势与选型理由

为什么选择这样的架构组合？这背后是多个维度的权衡：

1. 运维复杂度最小化：尽可能选用全托管服务（Cloud Run, Cloud SQL, Cloud Storage），将运维负担转移给云厂商，让开发者聚焦于 Dify 应用本身的业务逻辑。
2. 成本优化：利用 Cloud Run 的“缩容到零”和按需计费特性，在测试或低流量时期将运行成本降至极低。
3. 生产就绪的高可用性：Cloud SQL 默认提供高可用配置，跨区域备份；Cloud Run 和 Cloud Storage 本身也是高可用设计。整个架构没有单点故障。
4. 安全最佳实践：通过 VPC 网络隔离和私有 IP 访问，遵循了“零信任网络”和“最小权限”的安全原则。
5. 基础设施即代码（IaC）：所有上述资源通过 Terraform 定义，环境搭建可重复、可审计、可版本化，是团队协作和持续交付的基础。

理解了这张蓝图，我们就能明白后续每一个 Terraform 命令背后的意义，而不是盲目地执行。接下来，我们就进入实战环节。

3. 实战部署全流程：从零到一的详细操作指南

理论清晰后，我们开始动手。我将以创建一个全新的 GCP 项目为起点，带你完整走通整个部署流程。请确保你已拥有一个 Google Cloud 账号，并安装了gcloudCLI 和terraformCLI。

3.1 前期准备与环境配置

第一步：创建与管理 GCP 项目首先，我们需要一个“沙箱”来放置所有资源，这就是 GCP 项目。

# 使用 gcloud CLI 创建一个新项目，请替换 `your-unique-project-id` 为你自己的ID gcloud projects create your-unique-project-id --name="Dify on GCP" # 将新项目设置为当前配置的活跃项目 gcloud config set project your-unique-project-id

注意：GCP 项目 ID 必须是全局唯一的。建议使用有意义的名称加随机后缀，例如dify-prod-5a2b。

创建项目后，需要为其启用计费并关联账单账户，否则无法创建任何付费资源。这需要在 GCP 控制台网页端完成。接着，启用本项目所需的所有 Google Cloud API：

# 一次性启用多个必要的 API gcloud services enable \ cloudresourcemanager.googleapis.com \ serviceusage.googleapis.com \ cloudbuild.googleapis.com \ run.googleapis.com \ sqladmin.googleapis.com \ compute.googleapis.com \ vpcaccess.googleapis.com \ artifactregistry.googleapis.com \ --project=your-unique-project-id

这些 API 分别对应资源管理、服务用量、Cloud Build、Cloud Run、Cloud SQL、计算引擎、VPC访问和容器镜像仓库。如果某个 API 启用失败，通常是因为计费未开启或权限不足。

第二步：克隆代码仓库与文件结构解析获取部署脚本：

git clone https://github.com/DeNA/dify-google-cloud-terraform.git cd dify-google-cloud-terraform

花一分钟看看目录结构，这对理解后续操作很重要：

dify-google-cloud-terraform/ ├── docker/ # 容器镜像构建脚本 ├── images/ # 架构图等资源 ├── terraform/ │ ├── modules/ # Terraform 模块定义（可复用的资源组合） │ └── environments/ │ └── dev/ # 开发环境配置 │ ├── main.tf # 环境的主资源定义 │ ├── variables.tf # 定义的输入变量 │ ├── outputs.tf # 部署后的输出信息（如访问URL） │ ├── provider.tf # 配置 Terraform 使用 GCP 提供商 │ └── terraform.tfvars.example # 变量配置模板 └── README.md

我们所有的操作都将集中在terraform/environments/dev/目录下。dev代表这是一个开发环境配置，在实际生产中，你可能会复制出staging、prod等目录来管理不同环境。

第三步：关键配置：Terraform 状态桶与变量文件这是最容易出错的两个地方，务必仔细操作。

1. 创建 Terraform 状态存储桶：Terraform 需要记录它创建的资源的状态（比如资源的ID、属性），这个状态文件默认存储在本地。但在团队协作或自动化场景中，必须将其存储在远程。项目要求使用 Cloud Storage (GCS) 桶。

# 选择一个全局唯一的桶名，GCS 桶名是全局唯一的 export TF_STATE_BUCKET="your-unique-tfstate-bucket" # 创建这个桶，并启用版本控制（防止状态文件被意外覆盖或删除） gsutil mb -l us-central1 gs://${TF_STATE_BUCKET} gsutil versioning set on gs://${TF_STATE_BUCKET}

实操心得：桶的区域（-l us-central1）最好与你后续部署应用的主要区域一致，以减少延迟。桶名一旦创建无法更改，请慎重选择。

2. 配置变量文件terraform.tfvars：这是整个部署的“控制面板”。项目提供了一个模板terraform.tfvars.example，我们需要复制并填写它。

cd terraform/environments/dev cp terraform.tfvars.example terraform.tfvars

现在，用文本编辑器打开terraform.tfvars。你需要修改以下几个核心变量：

# 你的 GCP 项目 ID project_id = "your-unique-project-id" # 部署区域，建议选择 us-central1, europe-west1, asia-northeast1 等 region = "us-central1" # 之前创建的 Terraform 状态桶名称 tfstate_bucket = "your-unique-tfstate-bucket" # Dify 的数据库密码，请务必设置一个强密码！ db_password = "your-very-strong-postgres-password-here" # Dify 管理员用户的初始密码 dify_admin_password = "your-dify-admin-password"

警告：terraform.tfvars文件包含了密码等敏感信息！绝对不要将它提交到 Git 仓库。项目已经在.gitignore中排除了*.tfvars文件，但请再次确认你的本地操作不会误提交。更安全的做法是使用环境变量（TF_VAR_db_password）或 GCP Secret Manager 来管理密码。

3. 更新后端配置：打开provider.tf文件，找到backend “gcs”配置块，确保bucket参数的值就是你刚才创建的桶名。

terraform { backend "gcs" { bucket = "your-unique-tfstate-bucket" # 确保这里已更新 prefix = "terraform/state" } }

3.2 分步执行部署命令

环境配置妥当，现在可以开始施展 Terraform 的“魔法”了。请严格按照顺序执行。

第一步：初始化 Terraform

# 在 terraform/environments/dev 目录下执行 terraform init

这个命令会做几件事：下载 GCP 的 Terraform 提供商插件、初始化配置的后端（即连接到我们刚创建的 GCS 桶）。如果成功，你会看到 “Terraform has been successfully initialized!” 的提示。

第二步：预创建容器镜像仓库Dify 的容器镜像需要有一个地方存放，这就是 Artifact Registry。我们先用 Terraform 创建这个仓库。

terraform apply -target=module.registry

-target参数允许我们只应用特定模块的资源。这里我们只创建镜像仓库模块。执行后，Terraform 会显示一个执行计划，询问你是否确认。输入yes继续。完成后，你会在 GCP 控制台的 Artifact Registry 页面看到一个新建的仓库。

第三步：构建并推送 Dify 容器镜像现在我们需要把 Dify 的官方镜像，或者自定义构建的镜像，推送到我们自己的仓库。项目提供了一个便捷的脚本。

# 返回到项目根目录 cd ../../.. # 执行构建脚本，传入项目ID和区域 sh ./docker/cloudbuild.sh your-unique-project-id us-central1

这个脚本内部使用了 Cloud Build 服务。它会：

1. 从 Docker Hub 拉取官方的dify-api和dify-web镜像。
2. 根据项目内的Dockerfile（如果需要自定义）进行构建。
3. 将构建好的镜像打上标签，并推送到你项目下 Artifact Registry 的对应仓库中。

技巧：你可以指定 Dify 的版本，例如sh ./docker/cloudbuild.sh your-project-id us-central1 v1.0.0。如果不指定，默认使用latest标签。建议为生产环境指定一个明确的版本号以保证一致性。

第四步：规划并应用完整基础设施镜像准备就绪，现在可以部署所有资源了。

# 再次进入 Terraform 环境目录 cd terraform/environments/dev # 生成执行计划，查看 Terraform 将要创建/更改哪些资源 terraform plan

仔细阅读terraform plan的输出。它会列出所有即将创建的资源（Cloud SQL 实例、VPC、Cloud Run 服务等），以及它们的详细配置。这是检查配置是否正确、成本预估（注意 Cloud SQL 实例的规格）的绝佳机会。

确认计划无误后，执行部署：

terraform apply

同样，Terraform 会再次显示计划并请求确认。输入yes后，它将开始创建所有资源。这个过程大约需要10 到 15 分钟，耗时最长的通常是创建 Cloud SQL 实例。请耐心等待，直到看到Apply complete!的输出。

第五步：获取访问信息并初始化 Dify部署成功后，Terraform 会输出一些关键信息：

Outputs: dify_api_url = "https://dify-api-xxxxxx-uc.a.run.app" dify_web_url = "https://dify-web-xxxxxx-uc.a.run.app"

dify_web_url就是你的 Dify 前端访问地址。在浏览器中打开它。

首次访问时，Dify 会进入初始化设置页面。你需要设置：

• 管理员邮箱：用于登录的账号。
• 管理员密码：使用你在terraform.tfvars中设置的dify_admin_password。
• 数据库配置：这里不需要手动填写！因为 Terraform 已经帮你创建好了 Cloud SQL 实例，并且通过环境变量将连接信息自动注入到了dify-api容器中。你只需要点击“检测”或“下一步”，Dify 应该能自动连接到数据库。

完成初始化后，使用你设置的管理员邮箱和密码登录，就可以开始使用你的 Dify AI 平台了！

4. 深入配置与优化：让部署更贴合你的需求

基础部署完成只是开始。这套 Terraform 代码提供了很高的灵活性，允许你根据实际需求进行调整。让我们深入几个关键配置点。

4.1 关键变量调优指南

再次打开terraform/environments/dev/terraform.tfvars，除了必填项，还有许多可选变量能影响部署的形态和成本。

数据库实例规格：

# 在 terraform.tfvars 中调整 db_tier = "db-custom-1-3840" # 默认是 db-f1-micro (共享核心，低成本)

db_tier决定了 Cloud SQL 实例的 CPU 和内存。对于个人测试或极小流量，db-f1-micro足够。但如果计划导入大量文档构建知识库，或有多人同时使用，建议升级：

• db-g1-small：1个vCPU，1.7 GB内存，适合小型团队。
• db-custom-1-3840：1个vCPU，3.75 GB内存，性能更好。
• 更高规格：可根据需要选择更多 CPU 和内存的组合。

成本提醒：Cloud SQL 实例是持续计费的（即使空闲），规格升级会直接增加月度成本。务必在terraform plan阶段留意预估费用。

Cloud Run 服务配置：相关的配置在terraform/modules/下的模块定义中，但你可以通过环境变量或修改main.tf来调整。例如，你可能想调整每个 Cloud Run 服务的并发数、内存大小或最大实例数，以优化性能和成本。这需要你稍微深入 Terraform 代码，找到google_cloud_run_v2_service资源定义进行修改。

区域与多区域考虑：region变量不仅影响资源位置，也影响延迟和可用性。对于全球用户，可以考虑：

1. 单一区域部署：如us-central1，简单，成本较低。
2. 多区域部署：这需要更复杂的架构，本项目当前模板是单区域的。你可以通过复制dev目录为europe-west1等，并利用 Terraform 工作区（workspace）或不同的状态文件来管理多个区域的部署，然后使用 Global Load Balancer 进行流量分发。

4.2 安全加固建议

默认部署已经具备良好的安全基础（私有 VPC，无公网 IP 的数据库）。你还可以进一步加固：

1. 使用 Secret Manager 管理密码：最佳实践是不将密码明文写在terraform.tfvars中。GCP 提供了 Secret Manager。

• 在 GCP 控制台或使用gcloud创建 Secret，存入你的数据库密码。
• 修改 Terraform 代码，通过data “google_secret_manager_secret_version”数据源来获取密码。
• 在 Cloud Run 服务定义中，通过secret_environment_variables将密码以环境变量的方式注入。 这样，密码完全由 Secret Manager 托管，访问记录可审计，且 Terraform 状态文件中不会出现明文密码。

2. 配置自定义域名和 SSL：默认的 Cloud Run 域名（*.run.app）可能不满足品牌需求。你可以：

• 在main.tf中为google_cloud_run_v2_service资源添加template.spec.containers.ports配置。
• 结合使用Cloud Load Balancing和Google-managed SSL certificates，为你的 Dify 服务绑定自定义域名并自动启用 HTTPS。这需要额外的 Terraform 资源定义。

3. 访问控制：默认 Cloud Run 服务是允许所有用户访问的。你可以通过 IAM 绑定，限制只有特定用户或服务账号可以调用 API 服务 (dify-api)，而将前端服务 (dify-web) 保持公开。

4.3 监控与日志排查

部署完成后，知道如何查看运行状态至关重要。

Cloud Logging：在 GCP 控制台导航到Logging > Logs Explorer。

• 查询dify-api日志：在查询构建器中，资源类型选择 “Cloud Run Revision”，服务名称选择你的dify-api服务。
• 查询dify-web日志：同理，选择对应的dify-web服务。 在这里，你可以看到应用的标准输出（stdout）和标准错误（stderr），是排查应用启动失败、运行时错误的第一现场。

Cloud Monitoring：在 GCP 控制台导航到Monitoring > Dashboards。

• Cloud Run 仪表板：查看每个服务的请求数量、延迟、错误率以及容器实例数量（自动伸缩情况）。
• Cloud SQL 仪表板：监控数据库的 CPU、内存、连接数和存储空间使用情况。 你可以基于这些指标设置告警策略，例如当数据库连接数超过阈值或 Cloud Run 错误率飙升时，通过邮件、短信等方式通知你。

5. 故障排除与运维常见问题实录

即使按照指南操作，你也可能会遇到一些问题。以下是我在测试过程中遇到的一些典型情况及解决方法。

5.1 部署阶段常见错误

错误1：Error 403: Permission denied on resource或Service account does not have permission

• 问题描述：在执行terraform apply时，Terraform 使用的服务账号没有足够权限创建某些资源。
• 根本原因：你当前登录的 Google 账号（通过gcloud auth application-default login设置）或其关联的服务账号，缺少必要的 IAM 角色。
• 解决方案：
  1. 确认当前活跃账号：gcloud config list account。
  2. 为这个账号在 GCP 项目上授予“所有者”（roles/owner）角色，这能提供最大权限（仅限测试环境）。对于生产环境，应遵循最小权限原则，精确授予roles/editor、roles/cloudsql.admin、roles/run.admin等角色。
  3. 可以在 GCP 控制台IAM 和管理 > IAM页面进行角色分配。

错误2：Error creating Instance: googleapi: Error 400: Invalid request: Failed to create subnetwork.

• 问题描述：创建 Cloud SQL 实例或 VPC 相关资源时失败。
• 根本原因：通常是因为项目所在的区域（Region）没有可用的 IP 地址空间来创建子网，或者请求的 VPC 网络配置有冲突。
• 解决方案：
  1. 尝试更换一个region，例如从us-central1换到us-east1。
  2. 检查项目中是否已存在大量网络资源，接近配额限制。可以在 GCP 控制台“配额”页面查看。
  3. 确保在terraform.tfvars中指定的network_name和subnet_ip_range是唯一的，不与现有网络冲突。

错误3：docker/cloudbuild.sh脚本执行失败，提示gcloud命令未找到或认证失败

• 问题描述：构建镜像的脚本无法运行。
• 根本原因：gcloudCLI 未安装，或未登录，或未设置正确的活跃项目。
• 解决方案：
  1. 确认gcloud已安装：gcloud --version。
  2. 运行gcloud auth login进行登录。
  3. 运行gcloud config set project your-unique-project-id设置项目。
  4. 确保已启用 Cloud Build API：gcloud services enable cloudbuild.googleapis.com。

5.2 运行阶段常见问题

问题1：Dify 初始化页面无法连接到数据库

• 排查步骤：
  1. 检查 Cloud SQL 实例状态：在 GCP 控制台确认 Cloud SQL 实例已创建成功且处于“运行中”状态。
  2. 检查 VPC 连接器：在 GCP 控制台搜索“Serverless VPC Access”，查看 VPC 连接器是否状态为“已就绪”。如果创建失败，可能是子网 IP 范围问题。
  3. 查看 dify-api 日志：在 Cloud Logging 中查看dify-api服务启动时的日志，寻找数据库连接错误信息（如 “connection refused”, “password authentication failed”）。
  4. 核对密码：确认terraform.tfvars中的db_password与 Dify 初始化页面尝试的密码一致（虽然理论上应该自动注入）。
• 终极方案：如果以上都正常，可以尝试进入 Cloud SQL 实例，创建一个新的数据库用户，并在 Dify 初始化页面手动填写连接信息（主机为 Cloud SQL 实例的私有 IP，端口 5432）。这能帮助隔离是连接问题还是权限问题。

问题2：上传文件到知识库失败，或文件处理异常

• 排查步骤：
  1. 检查 Cloud Storage 桶：确认 Terraform 成功创建了存储桶，并且dify-api服务账号拥有该桶的读写权限（默认配置应该已赋予）。
  2. 查看存储日志：在 Cloud Logging 中过滤dify-api服务关于“storage”或“upload”的日志错误。
  3. 检查 CORS 配置（如果通过前端直传）：虽然本项目架构是前端通过 API 上传，但如果你修改了架构，可能需要为 Cloud Storage 桶配置 CORS 策略。

问题3：应用响应缓慢，或自动伸缩不灵敏

• 可能原因与优化：
  1. Cloud Run 冷启动：如果服务缩容到零，新的请求到来时会触发“冷启动”，需要时间拉取容器镜像并启动，导致首次请求延迟高。可以通过设置最小实例数为 1 来避免冷启动，但会增加成本。
  2. 数据库性能瓶颈：使用db-f1-micro等低规格实例在高负载下容易成为瓶颈。监控 Cloud SQL 的 CPU 和内存使用率，考虑升级实例规格。
  3. 并发设置：调整 Cloud Run 服务的“每个容器的最大并发请求数”。设置过低（如默认的80）可能导致请求排队；设置过高可能使单个容器过载。需要根据应用特性（AI 推理通常较慢）进行压测调整。

5.3 资源清理与成本控制

重要警告：直接运行terraform destroy并不能删除所有资源！

正如项目 README 中强调的，出于安全和数据持久化的考虑，Terraform 配置中故意省略了某些资源的销毁策略，特别是 Cloud Storage（存储桶）、Cloud SQL（数据库）和 VPC 网络。这是为了防止误操作导致宝贵数据丢失。

正确的清理步骤：

1. 手动删除关键数据资源：
   • Cloud Storage 桶：进入 GCP 控制台，找到为 Dify 创建的存储桶（名称通常包含dify和随机后缀），清空桶内所有对象和版本，然后删除桶。
   • Cloud SQL 实例：在控制台找到实例，先停止实例，然后删除它。删除前请确认已备份必要数据。
   • VPC 网络与子网：确保没有其他资源在使用后，删除相关的 VPC 网络和子网。
2. 执行 Terraform 销毁：完成上述手动删除后，再运行terraform destroy。此时，Terraform 会安全地删除剩余的资源，如 Cloud Run 服务、VPC 连接器、Artifact Registry 仓库等。
3. 验证与成本监控：销毁后，访问 GCP 的“结算报告”页面，确认相关资源已停止计费。养成定期查看账单的习惯，可以有效控制云上成本。

整个流程走下来，你会发现，虽然初始的配置看起来有些复杂，但一旦这套 IaC 代码准备就绪，后续的部署、复制、销毁都变得极其高效和可控。这正体现了现代云运维的核心思想：将繁琐、易错的手工操作，转化为可重复、可版本化的自动化流程。希望这份超详细的指南，能帮助你顺利在 Google Cloud 上搭建起属于自己的 AI 应用工场。