使用 ZenML GCP Cloud Run Deployer 将流水线部署为无服务器 HTTP 服务

使用 ZenML GCP Cloud Run Deployer 将流水线部署为无服务器 HTTP 服务【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml本文是 ZenML 开源仓库中 GCP Cloud Run Deployer 组件指南 的深度展开版聚焦于如何借助 ZenML 的 GCP 集成把训练/推理流水线一键部署为 Google Cloud Run 上的 HTTP 微服务。阅读完本文后你将掌握GCP Cloud Run deployer 的适用场景、本地gcloud与 GCP Service Connector 两种凭据接入方式、GCPDeployerSettings全部配置参数、基于ResourceSettings的资源与扩缩容设定以及底层实现原理部署、健康检查、日志、下线清理的完整调用链。什么是 GCP Cloud Run DeployerGCP Cloud Run 组件它作为 ZenML Stack 中的一个 deployer 组件接管流水线快照snapshot从容器镜像构建到 Cloud Run 服务创建/更新/删除的完整生命周期。⚠️使用前提该组件只应在远程 ZenML 部署环境下使用。与本地 ZenML 安装配合使用可能会导致非预期行为。从源码结构看该组件由两部分构成两者都在src/zenml/integrations/gcp/目录下配置与口味定义flavors/gcp_deployer_flavor.py 定义了GCPDeployerSettings、GCPDeployerConfig与GCPDeployerFlavor具体实现deployers/gcp_deployer.py 中的GCPDeployer类负责与 Cloud Run / Secret Manager / Cloud Logging API 交互。口味标识为gcp见 integrations/gcp/init.py并且通过service_connector_requirements声明其需要gcp-generic类型的资源用于过滤可兼容的 Service Connector见 gcp_deployer_flavor.py。什么时候使用它根据官方文档在以下情况你应该使用 GCP Cloud Run deployer你已经在使用 GCP你在寻找一个久经生产验证的 deployer你在寻找把流水线部署为 HTTP 微服务的无服务器serverless方案你想要按使用量付费pay-per-use的自动扩缩容你需要以极少的配置部署容器化应用。部署前提先有远程 ZenML再谈 Cloud Run在使用 GCP Cloud Run deployer 之前需要先完成将 ZenML 部署到云端。官方建议非必须将 ZenML 部署在与 Cloud Run 基础设施相同的 Google Cloud 项目中。在使用该 stack 组件之前必须确保你已连接到远程 ZenML 服务器。除此之外唯一需要准备的是在目标 Google Cloud 项目中启用 Cloud Run 相关 API。如果你希望跳过手工步骤、一次性部署一整套 ZenML 云栈含 GCP Cloud Run deployer可以参考仓库中 infrastructure-deployment 文档中关于 GCP Terraform 模块的说明它会自动完成组件部署与注册。使用前置条件与整体流程要实际使用 GCP Cloud Run deployer你需要安装 ZenML 的gcp集成zenml integration install gcp本机安装并运行 Docker用于构建流水线镜像Stack 中必须包含一个远程 Artifact StoreStack 中必须包含一个远程 Container Registry具备相应权限的 GCP 凭据明确想要部署流水线的 GCP 项目 IDproject ID与区域location。其中第 3、4 点也由源码中的StackValidator强制校验GCPDeployer要求栈中必须同时存在IMAGE_BUILDER与CONTAINER_REGISTRY两类组件见 gcp_deployer.py因为 ZenML 需要先构建镜像再推送到 Cloud Run。GCP 凭据与权限你有两种方式向 GCP Cloud Run deployer 提供凭据使用gcloudCLI 在本地完成 GCP 认证推荐配置一个 GCP Service Connector 存放 GCP 凭据再把 GCP Cloud Run deployer 组件与该 Service Connector 关联。无论采用哪种认证方式所用凭据在目标 GCP 项目中都需要以下权限权限 / 角色用途roles/run.admin管理 Cloud Run 服务创建、更新、删除secretmanager.secrets.create无条件仅当 deployer 配置为通过 Secret Manager 向 Cloud Run 服务传递敏感信息时必需即use_secret_managerTrue用于在目标项目中创建新 secretroles/secretmanager.admin限定 name 前缀为zenml-同上场景用于管理以zenml-为前缀的 secret该前缀可通过secret_name_prefix设置修改更简单的替代方案直接在项目级授予roles/secretmanager.admin角色且不附加任何条件。配置实践一本地gcloudCLI 用户账号该方案假设你已经通过gcloud auth login在本机完成 GCP 账号认证且该账号拥有上述权限。它是最简单的配置方式但有如下缺点配置不可移植、不可复现其他用户无法用该 deployer 部署流水线或管理你的 Deployments尽管他们仍可访问暴露的端点并发送 HTTP 请求它使用的是 Compute Engine 默认服务账号该账号默认权限过大且被许多其他 GCP 服务共用官方不推荐。注册命令如下zenml deployer register DEPLOYER_NAME \ --flavorgcp \ --projectPROJECT_ID \ --locationGCP_LOCATION \配置实践二GCP Service Connector该方案假设你已经创建了一个具备所需权限的 GCP 服务账号并已下载其密钥文件到本地例如zenml-cloud-run-deployer.json。如果你的环境支持也可以通过 GCP Workload Identity 等免密钥方式完成认证。准备好服务账号与密钥后按如下方式注册 GCP Service Connector 与 deployer 并完成关联zenml service-connector register CONNECTOR_NAME \ --type gcp \ --auth-methodservice-account \ --project_idPROJECT_ID \ --service_account_jsonzenml-cloud-run-deployer.json \ --resource-type gcp-generic zenml deployer register DEPLOYER_NAME \ --flavorgcp \ --locationGCP_LOCATION \ --connector CONNECTOR_NAME这里--resource-type gcp-generic与源码中GCPDeployerFlavor.service_connector_requirements声明的资源类型GCP_RESOURCE_TYPE gcp-generic见 gcp/init.py保持一致这样注册时 ZenML 才能自动匹配到兼容的 connector。配置 Stack 并部署流水线deployer 注册完成后将其加入活动栈并激活# 注册并激活包含新 deployer 的 stack zenml stack register STACK_NAME -D DEPLOYER_NAME ... --set提示ZenML 会构建一个名为CONTAINER_REGISTRY_URI/zenml:PIPELINE_NAME的 Docker 镜像并用它把流水线部署为 Cloud Run 服务。镜像的构建方式及自定义方法可参考仓库中关于容器化/镜像构建的文档containerization 说明。栈就绪后即可部署任意 ZenML 流水线zenml pipeline deploy --name my_deployment my_module.my_pipeline部署完成后还可以通过zenml deployment系列命令完成部署的生命周期管理命令定义见 cli/deployment.pyzenml deployment list # 列出已注册的部署 zenml deployment describe DEPLOYMENT # 查看部署详情 zenml deployment logs DEPLOYMENT # 获取部署日志支持 --tail 行数 zenml deployment refresh DEPLOYMENT # 刷新部署运行状态 zenml deployment deprovision DEPLOYMENT # 下线部署删除 Cloud Run 服务 zenml deployment delete DEPLOYMENT # 下线并删除部署记录附加配置GCPDeployerSettings 参数详解除了注册命令中的参数还可以通过zenml.integrations.gcp.flavors.gcp_deployer_flavor模块中的GCPDeployerSettings对 deployer 进行细粒度配置。该类的完整字段、默认值与取值约束定义在 gcp_deployer_flavor.py以下表格即由此整理。所有 Deployer 共有的基础设置继承自BaseDeployerSettings见 base_deployer.py参数类型/默认值说明auth_keystr/None用于部署 API 调用认证的用户自定义密钥generate_auth_keybool/False是否生成并使用随机认证密钥替代用户自定义密钥lcm_timeoutint/600等待部署生命周期管理LCM完成的最大秒数GCP Cloud Run 特有设置参数默认值说明locationeurope-west3流水线部署的 GCP 区域名。Cloud Run 仅在特定区域可用详见 GCP 官方 locations 文档service_name_prefixzenml-Cloud Run 服务名前缀用于避免命名冲突timeout_seconds300请求超时秒数取值必须介于 1 到 36001 小时之间源码中以ge1, le3600强约束ingressall服务的入站流量设置。可选值all、internal、internal-and-cloud-load-balancingvpc_connectorNone私有网络的 VPC connector格式projects/PROJECT_ID/locations/LOCATION/connectors/CONNECTOR_NAMEservice_accountNone运行 Cloud Run 服务的服务账号邮箱未指定时使用默认 Compute Engine 服务账号environment_variables{}设置在 Cloud Run 服务中的环境变量字典labels{}应用到 Cloud Run 服务的标签字典用于组织与账单归因annotations{}应用到 Cloud Run 服务的注解字典用于附加元数据execution_environmentgen2执行环境代数。可选值gen1、gen2traffic_allocation{LATEST: 100}修订版本revision间的流量分配。键为修订名或LATEST值为百分比总和必须为 100allow_unauthenticatedTrue是否允许对服务的未认证请求。设为False可部署为需要 GCP 特定认证的私有服务use_secret_managerTrue是否将敏感环境变量存入 GCP Secret Manager 而非直接写入 Cloud Run 服务配置以增强安全性secret_name_prefixzenml-使用 Secret Manager 时的 secret 名前缀避免命名冲突关于如何在代码中指定这些 settings可参考步骤与流水线配置相关文档。例如若想对本次部署禁用 GCP Secret Managerfrom zenml import step, pipeline from zenml.integrations.gcp.flavors.gcp_deployer_flavor import GCPDeployerSettings step def greet(name: str) - str: return fHello {name}! settings { deployer: GCPDeployerSettings( use_secret_managerFalse ) } pipeline(settingssettings) def greet_pipeline(name: str John): greet(namename)从源码可以进一步印证两个设计细节其一GCPDeployerConfig.is_remote恒为True见 gcp_deployer_flavor.py这正是必须在远程 ZenML 部署环境下使用这一警告的实现依据——本地数据库会拒绝该组件其二deployer 的GCPDeployerSettings与注册时的GCPDeployerConfig叠加生效GCPDeployerConfig同时继承BaseDeployerConfig、GoogleCredentialsConfigMixin与GCPDeployerSettings注册时给定的--location等参数即作为配置默认值。资源与扩缩容设置你可以在流水线级别通过ResourceSettings类指定部署的资源与扩缩容需求ResourceSettings的完整字段定义见 config/resource_settings.pyfrom zenml import step, pipeline from zenml.config import ResourceSettings resource_settings ResourceSettings( cpu_count2, memory32GB, min_replicas0, max_replicas10, max_concurrency50 ) ... pipeline(settings{resources: resource_settings}) def greet_pipeline(name: str John): greet(namename)默认资源值如果不设置任何资源参数GCP Cloud Run deployer 将使用以下默认值源码常量见 gcp_deployer.py参数默认值cpu_count1memory2GiB源码常量为2Gimin_replicas1max_replicas100max_concurrency80另有一个易被忽略的映射规则ResourceSettings.max_replicas0在 ZenML 语义中表示不限上限GCP Cloud Run 需要具体数值因此 deployer 会将其换算为平台最大值1000GCP_CLOUD_RUN_MAX_INSTANCES具体见 _convert_scaling_settings_to_gcp_format。Cloud Run 的 CPU 与内存约束及自动校正GCP Cloud Run 对 CPU 与内存的合法组合有专门规则截至 2025 年 10 月CPU 约束小数 CPU0.08 到 1.0以 0.01 为步进整数 CPU仅允许 1、2、4、6、8≥ 1.0 不允许小数。各 CPU 档位对应的最小内存CPU 配置最小内存≤ 1 CPU128 MiB2 CPU128 MiB4 CPU2 GiB6 CPU4 GiB8 CPU4 GiB关键行为指定不合法的cpu_count/memory值不会导致部署报错而是会被自动调整到满足规则的最近合法值。官方给出的示例cpu_count0.25与memory100MiB→ 调整为cpu_count0.25与memory128MiBcpu_count1.5、未指定memory→ 调整为cpu_count2与memory128MiBcpu_count6与memory1GB→ 调整为cpu_count6与memory4GiB。该校正逻辑在源码中有完整实现_convert_resource_settings_to_gcp_format 负责把cpu_count归一化到合法集合 1.0 时保留两位小数且下限 0.08≥ 1.0 时向上取整到 1/2/4/6/8 中最小满足值_validate_memory_for_cpu 则依据上表对内存做max(请求值, 最小要求)的抬升处理。内存最终以Gi或Mi为单位写入 Cloud Run 的资源 limits例如2Gi、0.5Gi参见 do_provision_deployment。底层实现原理源码级解读架构与继承关系GCPDeployer继承自ContainerizedDeployer后者又继承自BaseDeployer定义于 deployers/base_deployer.py。BaseDeployer承担三大职责保存与远程部署平台交互所需的栈配置属性实现部署的生命周期管理发现、创建、删除、更新作为 ZenML 部署注册表把每个流水线部署以数据库实体的形式经 ZenML Client 落库从而跟踪所有外部运行的部署。BaseDeployer还提供了provision_deployment/refresh_deployment/deprovision_deployment/delete_deployment/get_deployment_logs等统一入口并以内置轮询每 5 秒一次等待部署达到目标状态超时则抛出DeploymentTimeoutError见 base_deployer.py。GCPDeployer只需实现四个抽象方法见 gcp_deployer.pydo_provision_deployment基于流水线快照创建或更新 Cloud Run 服务服务已存在时走update_service否则走create_service并返回操作状态do_get_deployment_state通过get_service查询 Cloud Run 服务并映射为 ZenML 的DeploymentOperationalStatereconciling 时为 PENDING终态条件成功为 RUNNING失败为 ERRORdo_get_deployment_state_logs通过 Cloud Logging 按resource.typecloud_run_revision与service_name过滤拉取日志do_deprovision_deployment删除 Cloud Run 服务并清理与之关联的全部 Secret Manager secrets。命名规范与唯一性保证Cloud Run 服务名要求小写字母、数字、连字符且以字母或数字开头结尾。_sanitize_name见 gcp_deployer.py负责把流水线部署名清洗为合法名称_get_service_name见 gcp_deployer.py在此基础上拼接service_name_prefix与部署 ID 的前 8 位并将总长度限制在 49 个字符以内以保证唯一性——这也解释了文档中service_name_prefix设置的作用。Secret Manager 与敏感信息处理当use_secret_managerTrue时_prepare_environment_variables见 gcp_deployer.py会把敏感环境变量逐一写入 Secret Managersecret 名由secret_name_prefix与变量名拼接、同样附带部署 ID 短前缀最大 255 字符并在 Cloud Run 服务中以EnvVarSource引用versionlatest的 secret而不是把明文写进服务配置若 secret 创建失败则回退为直接注入环境变量并给出警告。下线部署时_cleanup_deployment_secrets会遍历并删除该部署关联的全部 secrets见 gcp_deployer.py。健康检查的特殊处理当服务配置了受限入站流量ingress为internal或internal-and-cloud-load-balancing或禁用了未认证访问allow_unauthenticatedFalse时基类默认的 HTTP 健康检查请求会被 Cloud Run 的 ingress 规则拦截或遭 IAM 以 403 拒绝导致部署超时。因此GCPDeployer._check_deployment_health见 gcp_deployer.py会在这些场景下跳过 HTTP 探测改以 Cloud Run API 状态作为健康依据。小结GCP Cloud Run deployer 是 ZenML GCP 集成中把流水线发布为生产级无服务器 HTTP 服务的一等公民它通过gcp口味、GCPDeployerSettings配置矩阵、ResourceSettings资源映射以及BaseDeployer统一的生命周期框架屏蔽了 Cloud Run API 的底层细节同时保留了命名规范、Secret Manager 集成、CPU/内存自动校正等工程化能力。结合本仓库的 deployers 组件文档 与 gcp 集成源码你可以在此基础上进一步定制镜像构建、网络与扩缩容策略把任意 ZenML 流水线快速变成可按需伸缩的在线服务。【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考