ZenML 与 Terraform 基础设施即代码用 zenml-io/zenml Provider 将现有云资源注册为可运行 ML 栈的完整指南【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml基础设施即代码Infrastructure as CodeIaC是当今云原生团队管理资源的标准实践用代码描述、版本化、审计并自动应用基础设施变更取代手工操作。在 ZenML 的语境下IaC 意味着既能用 Terraform 一次性部署云资源也能用 Terraform 把这些资源正式登记为 ZenML 栈Stack与栈组件Stack Component。本文面向已经拥有自有 Terraform 代码的进阶用户讲解 ZenML 官方 Terraform Providerzenml-io/zenml的完整用法从配置 Provider、创建服务连接器、注册 artifact store / container registry / orchestrator 等组件到组装一个完整栈并切换激活最终用一套 GCP 端到端实战演练把全部环节串起来。读完本文你将掌握基础设施部署与ZenML 注册两阶段解耦的最佳实践并能把同样的模式迁移到 AWS 与 Azure。为什么要用 IaC 管理 ZenML两阶段方法论在深入代码之前先建立本文最重要的心智模型。当使用 Terraform 与 ZenML 协作时存在两个彼此独立、可以分属不同团队的阶段基础设施部署Infrastructure Deployment创建云资源例如 GCS 存储桶、Artifact Registry 仓库、Vertex AI 等。这一步通常由平台团队Platform Team负责属于传统 IaC 范畴。ZenML 注册ZenML Registration把上述云资源登记为 ZenML 栈组件并赋予 ZenML 访问它们的权限。这一步由 MLOps 平台接入完成。ZenML 团队在 Terraform Registry 上维护了一组官方模块zenml-stack/aws、zenml-stack/gcp、zenml-stack/azure这些模块同时覆盖两个阶段既创建云资源又自动完成 ZenML 侧的注册与授权。如果你是从零开始、追求最快落地可以参考仓库中的 deploy-a-cloud-stack-with-terraform.md其中详细记录了官方模块的用法、各云厂商的认证方式、组件清单与集成安装命令。但很多公司早已有既定的 Terraform 配置云资源存储桶、镜像仓库、计算服务已经存在。此时再引入官方模块等于重复管理同一批资源容易产生状态冲突。本文的场景正是继续沿用你自己的 Terraform 管理基础设施只把 ZenML 相关的登记动作交给 ZenML Provider 完成。这与 ZenML 提供的另外两种栈部署方式形成互补方式适用场景基础设施管理方ZenML 登记方式一键部署1-click stack deployment快速起步、无需了解云细节ZenML自动完成官方 Terraform 模块从零部署整套云栈模块内部完成模块自动完成自建 Terraform ZenML Provider本文已有基础设施、希望完全掌控 IaC你自己的 TerraformZenML Provider 完成Phase 1基础设施部署如果你已经在用 Terraform 管理云资源这一步无需任何改动。下面是一个典型的既有 GCP 基础设施声明——一个存放 ML 产物的 GCS 存储桶以及一个用于构建容器镜像的 Artifact Registry 仓库# Example of existing GCP infrastructure resource google_storage_bucket ml_artifacts { name company-ml-artifacts location US } resource google_artifact_registry_repository ml_containers { repository_id ml-containers format DOCKER }这些资源本身与 ZenML 无关是任何 ML 平台都需要的基础设施。Phase 1 的关键原则是不修改、不重复声明这些资源只把它们作为 Phase 2 的引用输入。Phase 2ZenML 注册配置 ZenML Provider第一步是在 Terraform 配置中声明zenml-io/zenmlProvider并让它能够访问你的 ZenML 服务器terraform { required_providers { zenml { source zenml-io/zenml } } } provider zenml { # Configuration options will be loaded from environment variables: # ZENML_SERVER_URL (for Pro users, this should be your Workspace URL from the dashboard) # ZENML_API_KEY }Provider 的认证配置推荐从环境变量加载而不是硬编码进.tf文件export ZENML_SERVER_URLhttps://your-zenml-server.com export ZENML_API_KEYyour-api-keyZenML Pro 用户特别提示ZENML_SERVER_URL应为仪表盘中的 Workspace URL形如https://1bfe8d94-zenml.cloudinfra.zenml.io。务必使用完整的 Workspace URL 而非裸域名。ZENML_API_KEY可以是组织级服务账户Service Account生成的 API Key也可以使用个人访问令牌Personal Access Token。为 OSS 服务器生成 API Key对于自托管OSS的 ZenML 服务器只需在已连接服务器的客户端上运行一条命令即可创建服务账户并获得 API Keyzenml service-account create SERVICE_ACCOUNT_NAME命令输出示例与仓库中 CLI 文档一致$ zenml service-account create terraform-account Created service account terraform-account. Successfully created API key default. The API key value is: ZENKEY_... Please store it safely as it will not be shown again.这条命令背后对应的是 ZenML CLI 中完整的 service-account 命令族其使用说明记录在 src/zenml/cli/init.pyzenml service-account list与zenml service-account api-key SERVICE_ACCOUNT_NAME list列出服务账户及其 API Keyzenml service-account describe SERVICE_ACCOUNT_NAME与zenml service-account api-key SERVICE_ACCOUNT_NAME describe API_KEY_NAME查看明细zenml service-account api-key SERVICE_ACCOUNT_NAME rotate API_KEY_NAME [--retain 60]轮换 API Key可设置旧 Key 的保留期便于平滑迁移存量负载zenml service-account update SERVICE_ACCOUNT_NAME --active false与zenml service-account api-key SERVICE_ACCOUNT_NAME update API_KEY_NAME --active false停用服务账户或 API Key立即生效zenml service-account api-key SERVICE_ACCOUNT_NAME delete API_KEY_NAME永久删除 API Key。两条关键注意事项API Key 只在创建时显示一次之后无法再次检索。一旦丢失只能重新创建。因此请立即把输出保存到安全的密钥管理系统中。API Key没有过期时间。出于安全考虑建议定期轮换并通过--retain参数保留旧 Key 一段时间确保所有使用方都已切换到新 Key 后再让旧 Key 失效。如果使用 ZenML Pro 服务器则需要创建个人访问令牌Personal Access Token或创建组织级服务账户并为其签发 API Key。创建服务连接器组件之间认证的关键服务连接器Service Connector是 ZenML 管理ZenML 服务器如何安全访问云资源的机制——它封装了云厂商的凭据如 GCP 服务账户 JSON、AWS IAM Role、Azure 服务主体等让各个栈组件复用同一份认证配置。在源码层面服务连接器的数据模型定义于 src/zenml/models/v2/core/service_connector.py核心字段包括connector_type连接器类型如gcp、auth_method认证方法、resource_id与configuration连接器配置而 src/zenml/service_connectors/service_connector.py 中的ServiceConnector基类则定义了各类型连接器共享的校验、凭据管理与连接逻辑。在 Terraform 中服务连接器的声明方式如下# First, create a service connector resource zenml_service_connector gcp_connector { name gcp-${var.environment}-connector type gcp auth_method service-account configuration { project_id var.project_id service_account_json file(service-account.json) } } # Create a stack component referencing the connector resource zenml_stack_component artifact_store { name existing-artifact-store type artifact_store flavor gcp configuration { path gs://${google_storage_bucket.ml_artifacts.name} } connector_id zenml_service_connector.gcp_connector.id }注意上述代码的关键模式服务连接器通过configuration携带云凭据这里是service_account.json文件内容栈组件通过connector_id字段引用服务连接器而不是各自重复保存凭据type artifact_store、flavor gcp表示这是一个 GCP 风格的对象存储组件其path直接指向 Phase 1 中创建的 GCS 存储桶。这种连接器 组件引用的设计让多个组件共享一份认证、权限变更只改一处也正是 register-a-cloud-stack.md 中栈向导Stack Wizard在 CLI 与 Dashboard 两侧遵循的同一套语义。各云厂商支持的认证方法可参考仓库中的服务连接器组件指南docs/book/component-guide/service-connectors例如 GCP 支持用户账户、服务账户、外部账户、OAuth 2.0 Token、服务账户模拟Impersonation等多种方法。注册栈组件通用登记模式ZenML 栈组件类型是开放的artifact_store、container_registry、orchestrator、step_operator、model_deployer 等因此可以用for_each把多个组件的登记收敛成一段声明式代码# Generic component registration pattern locals { component_configs { artifact_store { type artifact_store flavor gcp configuration { path gs://${google_storage_bucket.ml_artifacts.name} } } container_registry { type container_registry flavor gcp configuration { uri ${var.region}-docker.pkg.dev/${var.project_id}/${google_artifact_registry_repository.ml_containers.repository_id} } } orchestrator { type orchestrator flavor vertex configuration { project var.project_id region var.region } } } } # Register multiple components resource zenml_stack_component components { for_each local.component_configs name existing-${each.key} type each.value.type flavor each.value.flavor configuration each.value.configuration connector_id zenml_service_connector.env_connector.id }这个模式的价值在于新增组件只需要在locals里加一个条目Terraform 会自动完成注册。每个组件的typeflavor组合决定了它在 ZenML 侧被实例化为什么具体的实现例如orchestratorvertex对应 Vertex AI 编排器、container_registrygcp对应 Artifact Registry 仓库。组装栈最后一步是把已经登记好的组件组装成一个栈。栈是 ZenML 中编排配置 存储 容器 计算的完整打包概念其服务端数据模型可参见 src/zenml/models/v2/core/stack.py 中的StackResponseresource zenml_stack ml_stack { name ${var.environment}-ml-stack components { for k, v in zenml_stack_component.components : k v.id } }components映射的键如artifact_store、orchestrator就是栈中组件的角色名值是对应组件资源的 ID。至此一个完全由 IaC 声明出来的 ZenML 栈便已注册到你的 ZenML 服务器上可以像手工创建的栈一样被zenml stack set激活使用。实战演练注册现有 GCP 基础设施的完整示例下面把前面所有片段拼装成一个可直接运行的完整工程。该示例同时演示了搭建 GCP 基础设施、创建带认证的服务连接器、注册三个核心组件、组装完整栈、管理敏感变量与输出。前置条件一个用于存放产物的 GCS 存储桶一个 Artifact Registry 仓库一个用于 ML 操作的服务账户Service Account已启用 Vertex AI 用于编排机器上已安装 Terraform官方模块要求版本不低于 1.9建议自建配置同样遵循该基线已通过gcloud init或gcloud auth application-default login完成 GCP 本地认证。Step 1变量配置variables.tf# variables.tf variable zenml_server_url { description URL of the ZenML server (for Pro users, this is your Workspace URL) type string } variable zenml_api_key { description API key for ZenML server authentication type string sensitive true } variable project_id { description GCP project ID type string } variable region { description GCP region type string default us-central1 } variable environment { description Environment name (e.g., dev, staging, prod) type string } variable gcp_service_account_key { description GCP service account key in JSON format type string sensitive true }要点sensitive true标记的变量zenml_api_key、gcp_service_account_key在terraform plan/apply输出与状态文件中会被脱敏展示避免凭据泄露到日志。Step 2主配置main.tf# main.tf terraform { required_providers { zenml { source zenml-io/zenml } google { source hashicorp/google } } } # Configure providers provider zenml { server_url var.zenml_server_url # For Pro users, this is your Workspace URL api_key var.zenml_api_key } provider google { project var.project_id region var.region } # Create GCP resources if needed resource google_storage_bucket artifacts { name ${var.project_id}-zenml-artifacts-${var.environment} location var.region } resource google_artifact_registry_repository containers { location var.region repository_id zenml-containers-${var.environment} format DOCKER } # ZenML Service Connector for GCP resource zenml_service_connector gcp { name gcp-${var.environment} type gcp auth_method service-account configuration { project_id var.project_id region var.region service_account_json var.gcp_service_account_key } labels { environment var.environment managed_by terraform } } # Artifact Store Component resource zenml_stack_component artifact_store { name gcs-${var.environment} type artifact_store flavor gcp configuration { path gs://${google_storage_bucket.artifacts.name}/artifacts } connector_id zenml_service_connector.gcp.id labels { environment var.environment } } # Container Registry Component resource zenml_stack_component container_registry { name gcr-${var.environment} type container_registry flavor gcp configuration { uri ${var.region}-docker.pkg.dev/${var.project_id}/${google_artifact_registry_repository.containers.repository_id} } connector_id zenml_service_connector.gcp.id labels { environment var.environment } } # Vertex AI Orchestrator resource zenml_stack_component orchestrator { name vertex-${var.environment} type orchestrator flavor vertex configuration { location var.region synchronous true } connector_id zenml_service_connector.gcp.id labels { environment var.environment } } # Complete Stack resource zenml_stack gcp_stack { name gcp-${var.environment} components { artifact_store zenml_stack_component.artifact_store.id container_registry zenml_stack_component.container_registry.id orchestrator zenml_stack_component.orchestrator.id } labels { environment var.environment managed_by terraform } }本示例中几个值得细读的细节命名规范化所有 ZenML 资源名都以${var.environment}结尾配合labels中的environment与managed_by terraform标签让多环境dev/staging/prod共存的资源一目了然也便于事后审计哪些资源由 Terraform 托管。组件 flavor 与配置artifact store 的path是gs://.../artifacts子目录隔离产物container registry 的uri严格遵循 GCP Artifact Registry 的地址规范${region}-docker.pkg.dev/${project}/${repo}Vertex 编排器通过location指定区域、synchronous true表示同步等待任务完成。全部组件共享同一个服务连接器三个组件都引用zenml_service_connector.gcp.id权限管理集中在一处。如果你已有这些 GCP 资源只需把google_storage_bucket与google_artifact_registry_repository两个块替换为data google_storage_bucket/data google_artifact_registry_repository数据源引用其余 ZenML 部分完全不变——这正是基础设施已存在场景的标准做法。Step 3输出配置outputs.tf# outputs.tf output stack_id { description ID of the created ZenML stack value zenml_stack.gcp_stack.id } output stack_name { description Name of the created ZenML stack value zenml_stack.gcp_stack.name } output artifact_store_path { description GCS path for artifacts value ${google_storage_bucket.artifacts.name}/artifacts } output container_registry_uri { description URI of the container registry value ${var.region}-docker.pkg.dev/${var.project_id}/${google_artifact_registry_repository.containers.repository_id} }stack_name输出会被后续的zenml stack set $(terraform output -raw stack_name)直接消费因此建议始终保留。Step 4terraform.tfvars 与环境变量创建terraform.tfvars文件存放非敏感变量切记不要提交到版本控制zenml_server_url https://your-zenml-server.com # For Pro users: your Workspace URL from dashboard project_id your-gcp-project-id region us-central1 environment dev敏感变量通过环境变量注入Terraform 会自动读取TF_VAR_前缀的环境变量export TF_VAR_zenml_api_keyyour-zenml-api-key export TF_VAR_gcp_service_account_key$(cat path/to/service-account-key.json)使用步骤安装所需 Provider 并初始化 Terraformterraform init安装 ZenML 所需的 GCP 集成让本机 ZenML 客户端具备 GCP 相关 flavor 的解析能力zenml integration install gcp审查将要执行的变更terraform plan应用配置Terraform 会提示确认输入yes继续terraform apply把新创建的栈设为当前激活栈zenml stack set $(terraform output -raw stack_name)验证配置zenml stack describe完成以上步骤后你的 ZenML 客户端便已指向这个由 IaC 全量管理的 GCP 栈可以直接用它运行流水线。这个完整示例涵盖了搭建 GCP 基础设施、创建带认证的服务连接器、注册栈组件、组装完整栈、变量与输出管理、敏感信息处理的全部最佳实践。扩展把模式迁移到 AWS 与 Azure同样的Phase 1 基础设施 Phase 2 Provider 注册模式可以直接迁移到其他云厂商只需替换 Provider 声明、服务连接器的type/auth_method以及各组件 flavor 与配置环节GCP本文示例AWSAzure云 Providerhashicorp/googlehashicorp/awshashicorp/azurermhashicorp/azuread服务连接器类型gcp/service-accountawsSecret Key、STS Token、IAM Role、Federation Token 等方法azureService Principal、Access Token 等方法Artifact Store flavorgcpGCS 路径s3s3://bucket/pathazureaz://container/pathContainer Registry flavorgcpArtifact Registry URIawsECR URIazureACR URIOrchestrator flavorvertexsagemakerazureml或skypilot各云厂商服务连接器的完整认证方法矩阵可查阅 docs/book/component-guide/service-connectors 下的对应文档组件 flavor 的配置细节可参考 docs/book/component-guide/artifact-stores、docs/book/component-guide/container-registries 与 docs/book/component-guide/orchestrators。如果你希望从零部署整套云栈而非登记存量资源则优先使用官方 Terraform 模块见 deploy-a-cloud-stack-with-terraform.md其中还包含各模块产出的组件清单与对应的zenml integration install命令。最佳实践与安全提示遵循最小权限原则为 ML 服务账户配置恰当的 IAM 角色与权限只授予组件实际需要的操作范围如 GCS 读写、Artifact Registry 推送、Vertex 任务提交避免使用过高权限的凭据。敏感信息不入库API Key、服务账户 JSON 等凭据一律通过TF_VAR_*环境变量或企业密钥管理系统注入.tfvars与密钥文件加入.gitignore。用 Terraform Workspace 管理多环境为 dev / staging / prod 各建一个 workspace或在配置中通过environment变量区分避免环境间资源互相覆盖。定期备份 Terraform 状态state 文件记录了资源与声明的对应关系建议存储在远程后端如 GCS 后端 版本控制并开启锁防止并发冲突与丢失。版本控制 Terraform 配置所有.tf文件都应纳入版本控制排除含敏感信息的文件使基础设施变更可评审、可回溯。谨慎对待 state 目录Terraform 会就地保存 state 文件。不要随意删除配置目录除非确认不再需要管理这些资源或已通过terraform destroy完成资源清理——官方文档同样强调这一点见 deploy-a-cloud-stack-with-terraform.md。需要拆除时运行terraform destroy该命令会销毁 Terraform 声明的云资源并删除在 ZenML 服务器上注册的对应栈。小结通过本文的两阶段方法论你已经可以把 ZenML 的栈与组件纳入公司现有的 Terraform 体系平台团队继续用自己熟悉的 IaC 管理云资源MLOps 团队用zenml-io/zenmlProvider 完成资源的 ZenML 登记两者通过服务连接器安全地衔接。整套流程声明式、可版本化、可审计且不依赖任何 ZenML 专有的部署工具——这正是 IaC 在 ML 基础设施领域的正确打开方式。【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ZenML 与 Terraform 基础设施即代码：用 zenml-io/zenml Provider 将现有云资源注册为可运行 ML 栈的完整指南
ZenML 与 Terraform 基础设施即代码用 zenml-io/zenml Provider 将现有云资源注册为可运行 ML 栈的完整指南【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml基础设施即代码Infrastructure as CodeIaC是当今云原生团队管理资源的标准实践用代码描述、版本化、审计并自动应用基础设施变更取代手工操作。在 ZenML 的语境下IaC 意味着既能用 Terraform 一次性部署云资源也能用 Terraform 把这些资源正式登记为 ZenML 栈Stack与栈组件Stack Component。本文面向已经拥有自有 Terraform 代码的进阶用户讲解 ZenML 官方 Terraform Providerzenml-io/zenml的完整用法从配置 Provider、创建服务连接器、注册 artifact store / container registry / orchestrator 等组件到组装一个完整栈并切换激活最终用一套 GCP 端到端实战演练把全部环节串起来。读完本文你将掌握基础设施部署与ZenML 注册两阶段解耦的最佳实践并能把同样的模式迁移到 AWS 与 Azure。为什么要用 IaC 管理 ZenML两阶段方法论在深入代码之前先建立本文最重要的心智模型。当使用 Terraform 与 ZenML 协作时存在两个彼此独立、可以分属不同团队的阶段基础设施部署Infrastructure Deployment创建云资源例如 GCS 存储桶、Artifact Registry 仓库、Vertex AI 等。这一步通常由平台团队Platform Team负责属于传统 IaC 范畴。ZenML 注册ZenML Registration把上述云资源登记为 ZenML 栈组件并赋予 ZenML 访问它们的权限。这一步由 MLOps 平台接入完成。ZenML 团队在 Terraform Registry 上维护了一组官方模块zenml-stack/aws、zenml-stack/gcp、zenml-stack/azure这些模块同时覆盖两个阶段既创建云资源又自动完成 ZenML 侧的注册与授权。如果你是从零开始、追求最快落地可以参考仓库中的 deploy-a-cloud-stack-with-terraform.md其中详细记录了官方模块的用法、各云厂商的认证方式、组件清单与集成安装命令。但很多公司早已有既定的 Terraform 配置云资源存储桶、镜像仓库、计算服务已经存在。此时再引入官方模块等于重复管理同一批资源容易产生状态冲突。本文的场景正是继续沿用你自己的 Terraform 管理基础设施只把 ZenML 相关的登记动作交给 ZenML Provider 完成。这与 ZenML 提供的另外两种栈部署方式形成互补方式适用场景基础设施管理方ZenML 登记方式一键部署1-click stack deployment快速起步、无需了解云细节ZenML自动完成官方 Terraform 模块从零部署整套云栈模块内部完成模块自动完成自建 Terraform ZenML Provider本文已有基础设施、希望完全掌控 IaC你自己的 TerraformZenML Provider 完成Phase 1基础设施部署如果你已经在用 Terraform 管理云资源这一步无需任何改动。下面是一个典型的既有 GCP 基础设施声明——一个存放 ML 产物的 GCS 存储桶以及一个用于构建容器镜像的 Artifact Registry 仓库# Example of existing GCP infrastructure resource google_storage_bucket ml_artifacts { name company-ml-artifacts location US } resource google_artifact_registry_repository ml_containers { repository_id ml-containers format DOCKER }这些资源本身与 ZenML 无关是任何 ML 平台都需要的基础设施。Phase 1 的关键原则是不修改、不重复声明这些资源只把它们作为 Phase 2 的引用输入。Phase 2ZenML 注册配置 ZenML Provider第一步是在 Terraform 配置中声明zenml-io/zenmlProvider并让它能够访问你的 ZenML 服务器terraform { required_providers { zenml { source zenml-io/zenml } } } provider zenml { # Configuration options will be loaded from environment variables: # ZENML_SERVER_URL (for Pro users, this should be your Workspace URL from the dashboard) # ZENML_API_KEY }Provider 的认证配置推荐从环境变量加载而不是硬编码进.tf文件export ZENML_SERVER_URLhttps://your-zenml-server.com export ZENML_API_KEYyour-api-keyZenML Pro 用户特别提示ZENML_SERVER_URL应为仪表盘中的 Workspace URL形如https://1bfe8d94-zenml.cloudinfra.zenml.io。务必使用完整的 Workspace URL 而非裸域名。ZENML_API_KEY可以是组织级服务账户Service Account生成的 API Key也可以使用个人访问令牌Personal Access Token。为 OSS 服务器生成 API Key对于自托管OSS的 ZenML 服务器只需在已连接服务器的客户端上运行一条命令即可创建服务账户并获得 API Keyzenml service-account create SERVICE_ACCOUNT_NAME命令输出示例与仓库中 CLI 文档一致$ zenml service-account create terraform-account Created service account terraform-account. Successfully created API key default. The API key value is: ZENKEY_... Please store it safely as it will not be shown again.这条命令背后对应的是 ZenML CLI 中完整的 service-account 命令族其使用说明记录在 src/zenml/cli/init.pyzenml service-account list与zenml service-account api-key SERVICE_ACCOUNT_NAME list列出服务账户及其 API Keyzenml service-account describe SERVICE_ACCOUNT_NAME与zenml service-account api-key SERVICE_ACCOUNT_NAME describe API_KEY_NAME查看明细zenml service-account api-key SERVICE_ACCOUNT_NAME rotate API_KEY_NAME [--retain 60]轮换 API Key可设置旧 Key 的保留期便于平滑迁移存量负载zenml service-account update SERVICE_ACCOUNT_NAME --active false与zenml service-account api-key SERVICE_ACCOUNT_NAME update API_KEY_NAME --active false停用服务账户或 API Key立即生效zenml service-account api-key SERVICE_ACCOUNT_NAME delete API_KEY_NAME永久删除 API Key。两条关键注意事项API Key 只在创建时显示一次之后无法再次检索。一旦丢失只能重新创建。因此请立即把输出保存到安全的密钥管理系统中。API Key没有过期时间。出于安全考虑建议定期轮换并通过--retain参数保留旧 Key 一段时间确保所有使用方都已切换到新 Key 后再让旧 Key 失效。如果使用 ZenML Pro 服务器则需要创建个人访问令牌Personal Access Token或创建组织级服务账户并为其签发 API Key。创建服务连接器组件之间认证的关键服务连接器Service Connector是 ZenML 管理ZenML 服务器如何安全访问云资源的机制——它封装了云厂商的凭据如 GCP 服务账户 JSON、AWS IAM Role、Azure 服务主体等让各个栈组件复用同一份认证配置。在源码层面服务连接器的数据模型定义于 src/zenml/models/v2/core/service_connector.py核心字段包括connector_type连接器类型如gcp、auth_method认证方法、resource_id与configuration连接器配置而 src/zenml/service_connectors/service_connector.py 中的ServiceConnector基类则定义了各类型连接器共享的校验、凭据管理与连接逻辑。在 Terraform 中服务连接器的声明方式如下# First, create a service connector resource zenml_service_connector gcp_connector { name gcp-${var.environment}-connector type gcp auth_method service-account configuration { project_id var.project_id service_account_json file(service-account.json) } } # Create a stack component referencing the connector resource zenml_stack_component artifact_store { name existing-artifact-store type artifact_store flavor gcp configuration { path gs://${google_storage_bucket.ml_artifacts.name} } connector_id zenml_service_connector.gcp_connector.id }注意上述代码的关键模式服务连接器通过configuration携带云凭据这里是service_account.json文件内容栈组件通过connector_id字段引用服务连接器而不是各自重复保存凭据type artifact_store、flavor gcp表示这是一个 GCP 风格的对象存储组件其path直接指向 Phase 1 中创建的 GCS 存储桶。这种连接器 组件引用的设计让多个组件共享一份认证、权限变更只改一处也正是 register-a-cloud-stack.md 中栈向导Stack Wizard在 CLI 与 Dashboard 两侧遵循的同一套语义。各云厂商支持的认证方法可参考仓库中的服务连接器组件指南docs/book/component-guide/service-connectors例如 GCP 支持用户账户、服务账户、外部账户、OAuth 2.0 Token、服务账户模拟Impersonation等多种方法。注册栈组件通用登记模式ZenML 栈组件类型是开放的artifact_store、container_registry、orchestrator、step_operator、model_deployer 等因此可以用for_each把多个组件的登记收敛成一段声明式代码# Generic component registration pattern locals { component_configs { artifact_store { type artifact_store flavor gcp configuration { path gs://${google_storage_bucket.ml_artifacts.name} } } container_registry { type container_registry flavor gcp configuration { uri ${var.region}-docker.pkg.dev/${var.project_id}/${google_artifact_registry_repository.ml_containers.repository_id} } } orchestrator { type orchestrator flavor vertex configuration { project var.project_id region var.region } } } } # Register multiple components resource zenml_stack_component components { for_each local.component_configs name existing-${each.key} type each.value.type flavor each.value.flavor configuration each.value.configuration connector_id zenml_service_connector.env_connector.id }这个模式的价值在于新增组件只需要在locals里加一个条目Terraform 会自动完成注册。每个组件的typeflavor组合决定了它在 ZenML 侧被实例化为什么具体的实现例如orchestratorvertex对应 Vertex AI 编排器、container_registrygcp对应 Artifact Registry 仓库。组装栈最后一步是把已经登记好的组件组装成一个栈。栈是 ZenML 中编排配置 存储 容器 计算的完整打包概念其服务端数据模型可参见 src/zenml/models/v2/core/stack.py 中的StackResponseresource zenml_stack ml_stack { name ${var.environment}-ml-stack components { for k, v in zenml_stack_component.components : k v.id } }components映射的键如artifact_store、orchestrator就是栈中组件的角色名值是对应组件资源的 ID。至此一个完全由 IaC 声明出来的 ZenML 栈便已注册到你的 ZenML 服务器上可以像手工创建的栈一样被zenml stack set激活使用。实战演练注册现有 GCP 基础设施的完整示例下面把前面所有片段拼装成一个可直接运行的完整工程。该示例同时演示了搭建 GCP 基础设施、创建带认证的服务连接器、注册三个核心组件、组装完整栈、管理敏感变量与输出。前置条件一个用于存放产物的 GCS 存储桶一个 Artifact Registry 仓库一个用于 ML 操作的服务账户Service Account已启用 Vertex AI 用于编排机器上已安装 Terraform官方模块要求版本不低于 1.9建议自建配置同样遵循该基线已通过gcloud init或gcloud auth application-default login完成 GCP 本地认证。Step 1变量配置variables.tf# variables.tf variable zenml_server_url { description URL of the ZenML server (for Pro users, this is your Workspace URL) type string } variable zenml_api_key { description API key for ZenML server authentication type string sensitive true } variable project_id { description GCP project ID type string } variable region { description GCP region type string default us-central1 } variable environment { description Environment name (e.g., dev, staging, prod) type string } variable gcp_service_account_key { description GCP service account key in JSON format type string sensitive true }要点sensitive true标记的变量zenml_api_key、gcp_service_account_key在terraform plan/apply输出与状态文件中会被脱敏展示避免凭据泄露到日志。Step 2主配置main.tf# main.tf terraform { required_providers { zenml { source zenml-io/zenml } google { source hashicorp/google } } } # Configure providers provider zenml { server_url var.zenml_server_url # For Pro users, this is your Workspace URL api_key var.zenml_api_key } provider google { project var.project_id region var.region } # Create GCP resources if needed resource google_storage_bucket artifacts { name ${var.project_id}-zenml-artifacts-${var.environment} location var.region } resource google_artifact_registry_repository containers { location var.region repository_id zenml-containers-${var.environment} format DOCKER } # ZenML Service Connector for GCP resource zenml_service_connector gcp { name gcp-${var.environment} type gcp auth_method service-account configuration { project_id var.project_id region var.region service_account_json var.gcp_service_account_key } labels { environment var.environment managed_by terraform } } # Artifact Store Component resource zenml_stack_component artifact_store { name gcs-${var.environment} type artifact_store flavor gcp configuration { path gs://${google_storage_bucket.artifacts.name}/artifacts } connector_id zenml_service_connector.gcp.id labels { environment var.environment } } # Container Registry Component resource zenml_stack_component container_registry { name gcr-${var.environment} type container_registry flavor gcp configuration { uri ${var.region}-docker.pkg.dev/${var.project_id}/${google_artifact_registry_repository.containers.repository_id} } connector_id zenml_service_connector.gcp.id labels { environment var.environment } } # Vertex AI Orchestrator resource zenml_stack_component orchestrator { name vertex-${var.environment} type orchestrator flavor vertex configuration { location var.region synchronous true } connector_id zenml_service_connector.gcp.id labels { environment var.environment } } # Complete Stack resource zenml_stack gcp_stack { name gcp-${var.environment} components { artifact_store zenml_stack_component.artifact_store.id container_registry zenml_stack_component.container_registry.id orchestrator zenml_stack_component.orchestrator.id } labels { environment var.environment managed_by terraform } }本示例中几个值得细读的细节命名规范化所有 ZenML 资源名都以${var.environment}结尾配合labels中的environment与managed_by terraform标签让多环境dev/staging/prod共存的资源一目了然也便于事后审计哪些资源由 Terraform 托管。组件 flavor 与配置artifact store 的path是gs://.../artifacts子目录隔离产物container registry 的uri严格遵循 GCP Artifact Registry 的地址规范${region}-docker.pkg.dev/${project}/${repo}Vertex 编排器通过location指定区域、synchronous true表示同步等待任务完成。全部组件共享同一个服务连接器三个组件都引用zenml_service_connector.gcp.id权限管理集中在一处。如果你已有这些 GCP 资源只需把google_storage_bucket与google_artifact_registry_repository两个块替换为data google_storage_bucket/data google_artifact_registry_repository数据源引用其余 ZenML 部分完全不变——这正是基础设施已存在场景的标准做法。Step 3输出配置outputs.tf# outputs.tf output stack_id { description ID of the created ZenML stack value zenml_stack.gcp_stack.id } output stack_name { description Name of the created ZenML stack value zenml_stack.gcp_stack.name } output artifact_store_path { description GCS path for artifacts value ${google_storage_bucket.artifacts.name}/artifacts } output container_registry_uri { description URI of the container registry value ${var.region}-docker.pkg.dev/${var.project_id}/${google_artifact_registry_repository.containers.repository_id} }stack_name输出会被后续的zenml stack set $(terraform output -raw stack_name)直接消费因此建议始终保留。Step 4terraform.tfvars 与环境变量创建terraform.tfvars文件存放非敏感变量切记不要提交到版本控制zenml_server_url https://your-zenml-server.com # For Pro users: your Workspace URL from dashboard project_id your-gcp-project-id region us-central1 environment dev敏感变量通过环境变量注入Terraform 会自动读取TF_VAR_前缀的环境变量export TF_VAR_zenml_api_keyyour-zenml-api-key export TF_VAR_gcp_service_account_key$(cat path/to/service-account-key.json)使用步骤安装所需 Provider 并初始化 Terraformterraform init安装 ZenML 所需的 GCP 集成让本机 ZenML 客户端具备 GCP 相关 flavor 的解析能力zenml integration install gcp审查将要执行的变更terraform plan应用配置Terraform 会提示确认输入yes继续terraform apply把新创建的栈设为当前激活栈zenml stack set $(terraform output -raw stack_name)验证配置zenml stack describe完成以上步骤后你的 ZenML 客户端便已指向这个由 IaC 全量管理的 GCP 栈可以直接用它运行流水线。这个完整示例涵盖了搭建 GCP 基础设施、创建带认证的服务连接器、注册栈组件、组装完整栈、变量与输出管理、敏感信息处理的全部最佳实践。扩展把模式迁移到 AWS 与 Azure同样的Phase 1 基础设施 Phase 2 Provider 注册模式可以直接迁移到其他云厂商只需替换 Provider 声明、服务连接器的type/auth_method以及各组件 flavor 与配置环节GCP本文示例AWSAzure云 Providerhashicorp/googlehashicorp/awshashicorp/azurermhashicorp/azuread服务连接器类型gcp/service-accountawsSecret Key、STS Token、IAM Role、Federation Token 等方法azureService Principal、Access Token 等方法Artifact Store flavorgcpGCS 路径s3s3://bucket/pathazureaz://container/pathContainer Registry flavorgcpArtifact Registry URIawsECR URIazureACR URIOrchestrator flavorvertexsagemakerazureml或skypilot各云厂商服务连接器的完整认证方法矩阵可查阅 docs/book/component-guide/service-connectors 下的对应文档组件 flavor 的配置细节可参考 docs/book/component-guide/artifact-stores、docs/book/component-guide/container-registries 与 docs/book/component-guide/orchestrators。如果你希望从零部署整套云栈而非登记存量资源则优先使用官方 Terraform 模块见 deploy-a-cloud-stack-with-terraform.md其中还包含各模块产出的组件清单与对应的zenml integration install命令。最佳实践与安全提示遵循最小权限原则为 ML 服务账户配置恰当的 IAM 角色与权限只授予组件实际需要的操作范围如 GCS 读写、Artifact Registry 推送、Vertex 任务提交避免使用过高权限的凭据。敏感信息不入库API Key、服务账户 JSON 等凭据一律通过TF_VAR_*环境变量或企业密钥管理系统注入.tfvars与密钥文件加入.gitignore。用 Terraform Workspace 管理多环境为 dev / staging / prod 各建一个 workspace或在配置中通过environment变量区分避免环境间资源互相覆盖。定期备份 Terraform 状态state 文件记录了资源与声明的对应关系建议存储在远程后端如 GCS 后端 版本控制并开启锁防止并发冲突与丢失。版本控制 Terraform 配置所有.tf文件都应纳入版本控制排除含敏感信息的文件使基础设施变更可评审、可回溯。谨慎对待 state 目录Terraform 会就地保存 state 文件。不要随意删除配置目录除非确认不再需要管理这些资源或已通过terraform destroy完成资源清理——官方文档同样强调这一点见 deploy-a-cloud-stack-with-terraform.md。需要拆除时运行terraform destroy该命令会销毁 Terraform 声明的云资源并删除在 ZenML 服务器上注册的对应栈。小结通过本文的两阶段方法论你已经可以把 ZenML 的栈与组件纳入公司现有的 Terraform 体系平台团队继续用自己熟悉的 IaC 管理云资源MLOps 团队用zenml-io/zenmlProvider 完成资源的 ZenML 登记两者通过服务连接器安全地衔接。整套流程声明式、可版本化、可审计且不依赖任何 ZenML 专有的部署工具——这正是 IaC 在 ML 基础设施领域的正确打开方式。【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考