如何用 Terraform 在 GCP Cloud Run 部署 LiteLLM Proxy 并解决 GHCR 镜像拉取问题【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellmLiteLLM 仓库自带一套 Terraform 模块terraform/litellm/gcp可以把组件化的 LiteLLM Proxy 一次性部署到 GCPCloud Run v2 上跑gateway端口 4000、backend4001、ui3000三个服务外加 Cloud SQL for PostgreSQL写入实例 跨区只读副本、Memorystore Redis缓存与限流、GCS 桶、Secret Manager 条目以及一个外部全局 HTTP(S) 负载均衡器。数据库迁移通过一个一次性 Cloud Run Joblitellm-migrations执行prisma migrate deploy完成。这条路径中有一个必须先解决的前置问题四个镜像litellm-gateway、litellm-backend、litellm-ui、litellm-migrations发布在 GHCR 上而 Cloud Run 只接受 Artifact Registry、[region.]gcr.io或docker.io的镜像会在 apply 阶段直接拒绝ghcr.ioURI。下面的步骤就是围绕打通这一点展开的。准备条件一个已开启 billing 的 GCP 项目。这套栈会创建付费资源Cloud SQL、Memorystore、LB anycast IP。gcloud已完成认证gcloud auth login。目标项目中启用以下 9 个 API可直接执行gcloud services enable \ run.googleapis.com \ sqladmin.googleapis.com \ redis.googleapis.com \ secretmanager.googleapis.com \ vpcaccess.googleapis.com \ compute.googleapis.com \ servicenetworking.googleapis.com \ storage.googleapis.com \ artifactregistry.googleapis.com解决 GHCR 镜像拉取创建 Artifact Registry 直通仓库在目标项目中创建指向 GHCR 的 remote 仓库每个项目只需做一次gcloud artifacts repositories create litellm \ --repository-formatdocker \ --locationus-central1 \ --moderemote-repository \ --remote-repo-config-descGitHub Container Registry passthrough \ --remote-docker-repohttps://ghcr.io如果仓库已存在该命令会退出并报错此时直接继续即可。之后 Cloud Run 拉镜像会走这个 remote 仓库由 GCP 侧透传到 GHCR。仓库文档同时说明了两个容易踩的细节栈创建的运行时 service account不需要roles/artifactregistry.reader权限——Cloud Run 拉镜像用的是项目级 serverless agentservice-project-numserverless-robot-prod.iam.gserviceaccount.com不是运行时 SA。如果环境完全离线可以不走 remote 仓库改为把镜像docker pull/docker tag/docker push到一个普通 AR 仓库然后把image_registry设为不带/berriai后缀的路径镜像布局里没有 org 段。配置 terraform.tfvars 并执行部署examples/default/是一个薄入口配置google/google-betaprovider 并调用上层模块入口一键部署路径如下cd terraform/litellm/gcp/examples/default cp terraform.tfvars.example terraform.tfvars terraform init terraform applyterraform.tfvars中需要编辑的关键项完整字段见 terraform.tfvars.example 的注释project_id my-gcp-project # 替换为你的 GCP 项目 ID region us-central1 tenant acme # 所有资源名的前缀${tenant}-litellm-${env} env stage # 必须设置指向上面创建的 Artifact Registry remote 仓库 image_registry us-central1-docker.pkg.dev/my-gcp-project/litellm/berriai image_tag v1.86.0-devimage_registry不能保留默认值ghcr.io/berriai——默认值只是为了让本地terraform plan能跑通真实部署时 Cloud Run 会在 apply 时拒绝它。四个litellm-component:${image_tag}镜像 URI 就是由image_registryimage_tag拼出来的升级 LiteLLM 时两个变量要一起升。只有需要单独固定某个组件镜像时才在examples/default/main.tf的module litellm块里直接设置gateway_image/backend_image/ui_image/migrations_image覆盖示例层没有把这些暴露成变量。密钥类输入建议用环境变量而不是写进 tfvars因为写进 tfvars 的值会进入terraform.tfstateexport TF_VAR_litellm_master_keysk-... # 可选省略时栈自动生成随机 sk-… 值 export TF_VAR_litellm_licenselic-... # 可选省略则 OSS-only 运行 export TF_VAR_ui_password... # 可选省略时 UI 登录回落到 master key首次terraform apply大约需要 20–25 分钟其中大部分时间花在 Cloud SQL 创建上。顺序是依赖资源就绪 → 迁移 Job 自动执行prisma migrate deploy→ 之后 gateway / backend / ui 才开始对外服务。apply 返回时栈已可接流量。可选的 1-click 路径GCP Cloud Shell 内置了 DeployStack 安装器回答项目、区域、tenant、env、image tag、image_registry、TLS 等提示后由它执行terraform apply提示定义见 deploystack.json。验证部署结果terraform output lb_urllb_url是 Proxy 的对外地址dashboard 在/API 在/v1/*。HTTP-only 试用部署下它是http://lb-ip形式。UI 登录账号是admin密码是 master key。如果部署时自动生成了 master key用下面命令从 Secret Manager 读出来gcloud secrets versions access latest \ --secret$(terraform output -raw master_key_secret_id)其他常用输出lb_ipLB anycast IP、gateway_service_url/backend_service_url/ui_service_url绕过 LB 的 Cloud Run 直连地址、migration_run_command迁移 Job 的 break-glass 手动重跑命令。从 HTTP 切到 TLS默认情况下terraform plan会拒绝只建 HTTP 的 LB——TLS 才是受支持的状态。两种走法试用 / 开发HTTP-only显式设置allow_plaintext_lb true且保持lb_domains []。不加这个 flag 而lb_domains为空时plan 会报指向 precondition 的明确错误。生产 / 预发Google 托管证书先用allow_plaintext_lb trueapply 一次读出 anycast IPterraform output -raw lb_ip把要使用的 DNS 域名 A 记录指向该 IP设置lb_domains [proxy.example.com]移除allow_plaintext_lb重新 apply。结果是 443 forwarding rule 挂上覆盖每个域名的托管证书80 端口改写为 301 到 HTTPS。首次 apply 后托管证书会处于PROVISIONING状态约 15–60 分钟等 DNS 传播可以用gcloud compute ssl-certificates describe tenant-litellm-env-cert查看状态。后续添加模型 provider 的 API keyprovider 密钥OpenAI、Anthropic 等放 Secret Manager而不是 tfvars。先建 secretecho -n sk-proj-... | gcloud secrets create openai-api-key --data-file-然后在terraform.tfvars中引用它的资源 IDCloud Run 运行时 SA 会自动获得该 secret 的roles/secretmanager.secretAccessor并在proxy_config里通过环境变量名引用它gateway_extra_secrets { OPENAI_API_KEY projects/my-gcp-project/secrets/openai-api-key } proxy_config { model_list [ { model_name gpt-4o litellm_params { model openai/gpt-4o api_key os.environ/OPENAI_API_KEY } }, ] }注意 secret 只传裸资源 IDprojects/.../secrets/openai-api-key不能带/versions/3这样的版本后缀——secret_key_ref绑定和 IAM 授权都会拒绝版本恒定为latest。改完重新terraform apply。proxy_config会被编码成 YAML 上传到专用 GCS 桶并以 gcsfuse 只读挂载到 gateway 和 backend 的/etc/litellm配置内容的 hash 作为环境变量随行保证编辑配置就触发新 revision。限制与清理数据保留保护cloudsql_deletion_protection默认为truedestroy 时拒绝删库gcs_force_destroy默认为false拒绝销毁非空桶。只有临时 / CI 栈才应把它们翻转且意味着接受数据丢失。数据库认证方式栈使用密码认证随机密码存 Secret Manager容器 entrypoint 在启动 uvicorn 前拼装DATABASE_URL密码不出现在服务 spec 和日志里而不是 GCP IAM 认证。如需 IAM 认证文档给出的方向是在 Cloud Run v2 的多容器能力下加cloud-sql-proxysidecar 走 Unix socket并替换密码式 URL。多租户(tenant, env)对不同的栈可以在同一项目内并存例如acme-litellm-stage-gateway与globex-litellm-dev-license但模块未声明configuration_aliasesfor_each只能在一个项目内扇出多租户跨项目/区域需要每项目一个 root。完整输入变量参考 variables.tf模块各.tf文件分工见 terraform/litellm/gcp/README.md 的 Files 表格分步教程见 TUTORIAL.md。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考