google-cloud-global-frontend-configuration 技能实战：Google Cloud 全局外部应用负载均衡器 Terraform 代码生成指南-北京尧图网络

google-cloud-global-frontend-configuration 技能实战Google Cloud 全局外部应用负载均衡器 Terraform 代码生成指南【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills本指南基于 skills29/skills 仓库中 google-cloud-global-frontend-configuration 技能的 terraform-generation.md 参考文档展开完整阐述如何依据设计规格书Design Spec生成语法正确、生产级、可部署的 Google Cloud 全局外部应用负载均衡器Global external Application Load BalancerTerraform HCL 代码并深度整合 Cloud CDN 与 Cloud Armor WAF 配置。读者读完本文后将掌握HCL 生成的行为守则、Google Cloud API 的 Terraform 约束规避方法、以工作负载画像映射表为事实源的配置决策机制以及从代码生成到 Infrastructure Manager 部署交接的完整链路。一、文档定位技能体系中的 HCL 生成环节在 skills29/skills 仓库中google-cloud-global-frontend-configuration技能通过一个 6 步发现式流程见 SKILL.md引导 Agent 设计并部署全局外部应用负载均衡器Basics项目发现、名称与协议选择、证书管理Origin Configuration逐个定义后端Cloud Storage / MIG / GKE / Cloud Run / 外部 IP-FQDN及其工作负载类型Traffic Management路由规则与 Service ExtensionsCachingCloud CDN按工作负载类型给出推荐缓存配置SecurityCloud Armor按工作负载类型给出推荐安全配置Review Deploy汇总配置表让用户选择Terraform HCL或 gcloud CLI 脚本作为交付格式。terraform-generation.md正是第 6 步中HCL 生成环节的权威依据它规定了当用户选择 Terraform 格式时Agent 必须如何把前 5 步收集到的设计决策架构名称、项目、区域、协议、各 Origin 的工作负载类型、路由规则机械地翻译为 HCL 代码。它不负责讲解 Terraform 基础语法而是聚焦生成正确性——这正是生产环境中最容易踩坑的地方。技能目录下与本文档协同工作的姊妹文档还包括terraform-module.md基于官方lb-http/cloud-armor模块的生成路线gcloud-generation.mdgcloud CLI 脚本生成路线及其依赖执行顺序managed-deployment.md生成后的部署交接IAM 预检 Infrastructure Manager / 脚本执行resource-discovery.md后端资源发现drift-detection.md部署后的配置漂移检测。二、生成前的输入Design Spec 的结构要求terraform-generation.md明确要求 Agent 在生成代码前先解析一份结构化的Design Spec其必需字段包括字段说明Architecture Name架构名称将作为所有资源命名的动态前缀Project目标 Google Cloud 项目 IDRegion区域影响 Serverless NEG、后端服务等资源的归属ProtocolsHTTP / HTTPS / 两者兼有Origins含 Workload Types每个后端Bucket、MIG、GKE、Cloud Run、外部 IP/FQDN及其工作负载类型Routing Rules基于路径 / 请求头 / 查询参数的流量路由规则设计规格的采集过程由 SKILL.md 的 Step 2 完成Agent 必须严格串行、逐个 Origin地询问并立即为每个 Origin 打上四类工作负载类型标签之一——Static Images / Objects、Cacheable API、Uncacheable API / Transactions、Dynamic Web (SSR)。这个标签是后续一切 CDN 与 WAF 配置决策的唯一输入源因此它是整个生成流程的信息基石。三、核心指令HCL 生成的行为守则terraform-generation.md开篇给出 6 条不可违背的行为守则它们是保证输出代码确定性与可部署性的顶层约束确定性输出Deterministic Output必须严格遵循下文工作负载画像映射表。用户选定工作负载类型后必须套用表中对应的 HCL 属性禁止自由发挥。这是为了防止 Agent 每次生成风格漂移、破坏代码可审计性。Schema 强制Schema Enforcement生成代码前必须等待并解析完整的 Design Spec含上文六类字段缺一不可。没有架构信息就生成的代码必然出现硬编码与命名冲突。跨资源引用Cross-Resource Linking所有 Terraform 资源之间必须使用引用语法关联而非硬编码名称。例如将安全策略挂到后端服务时应写security_policy google_compute_security_policy.example.id后端服务挂到 URL map 时应写default_service google_compute_backend_service.example.id。引用语法让 Terraform 自动推导资源依赖顺序避免资源未创建就先被引用的部署失败也便于后续使用terraform state管理。目录隔离Directory Isolation生成的 HCL 必须放在以架构名称命名的独立子目录中即/gfe/deployments/{architecture_name}/。隔离目录可以防止本地.terraform状态污染与资源名冲突是一个架构一套独立代码与状态的最佳实践前提。资源前缀化Resource Prefixing所有 Google Cloud 资源名必须以架构名称动态前缀通过输入变量或字符串插值实现如name ${var.architecture_name}-api-backend以保证全局唯一性避免 409 资源冲突错误。全小写命名Lowercase Naming OnlyInfrastructure Manager 与 Google Cloud API 对资源命名严格架构名、部署 ID 及所有生成资源名必须严格小写且匹配正则^a-z?$该正则的含义是以一个小写字母开头后续为 061 个小写字母 / 数字 / 连字符连字符不允许出现在末尾整体长度 163 个字符。这正对应 Google Cloud 计算资源命名的通用规则。如果用户提供了包含大写字母的名称必须在写入配置前自动转换为小写——这是最容易在gcloud infra-manager deployments apply阶段暴露的问题。四、Terraform 语法与 Google Cloud API 约束本部分是该文档的技术价值核心。它为四类高频配置陷阱给出了硬性规避规则任何一条违反都会导致terraform validate或部署阶段直接报错。结合仓库中的 terraform-module.md 官方模块示例可以一一印证。4.1 Cloud Armorgoogle_compute_security_policy默认动作必须用 rule 块显式声明不要在资源顶层使用default_rule_action ...这种写法必须显式定义一个priority 2147483647即最高优先级数值、最低优先级含义且action allow或deny的rule块作为默认兜底。限流动作使用throttle而非rate-based-banrate-based-ban在不同 API/provider 版本间行为不稳定action throttle超出阈值后短暂限流而非封禁兼容性更好。terraform-module.md 的官方模块示例中同样使用action throttle配合rate_limit_optionsexceed_action deny(403)、rate_limit_threshold { count 100, interval_sec 60 }可视为同一约束在模块写法下的印证。Cloud Armor Edge 策略禁用限流type CLOUD_ARMOR_EDGE策略后端为 Backend Bucket 时必需不支持rate_limit_options只能使用标准allow/deny规则。因此为 Backend Bucket 生成配置时绝不生成任何限流配置对应Static Images / Objects工作负载在映射表中 WAF 列为 None 的原因。4.2 Backend Bucketsgoogle_compute_backend_bucket不要包含cache_key_policy块不要尝试写cache_key_policy { include_query_string false }之类的参数。Backend Bucket 不支持这些参数在使用CACHE_ALL_STATIC模式时查询字符串默认即被忽略。TTL 上限约束cdn_policy.default_ttl不能大于max_ttl。若将default_ttl设为大于默认值864001 天的数值例如静态对象推荐的2592000即 30 天则必须显式将max_ttl设置为不小于default_ttl的值例如31536000即 365 天否则校验失败。4.3 Backend Servicesgoogle_compute_backend_serviceUSE_ORIGIN_HEADERS 模式下省略 TTL若使用cache_mode USE_ORIGIN_HEADERS由源站响应头决定缓存时长必须从cdn_policy块中省略default_ttl和client_ttl——显式指定会导致校验错误。这正是映射表中Cacheable API与Dynamic Web (SSR)两行 TTL 列标记为Omitted (Managed by Origin)的原因。谨慎使用request_coalescing除非确认当前激活的 provider 版本支持否则避免在 backend service 的cdn_policy中使用request_coalescing true。4.4 Provider 版本约束必须配置required_providers块并锁定 Google provider~ 5.0或更新版本以确保限流rate limiting特性得到正确支持。terraform-module.md 的示例亦遵循该版本约束terraform { required_version 1.0 required_providers { google { source hashicorp/google version ~ 5.0 } } }4.5 约束落地示例将上述约束翻译为资源级 HCL与官方模块写法、provider schema 一致# Cloud Armor默认动作显式声明 throttle 限流Cacheable API 场景 resource google_compute_security_policy waf_api { name ${var.architecture_name}-waf-api project var.project_id # 默认规则priority 2147483647 allow rule { action allow priority 2147483647 match { versioned_expr SRC_IPS_V1 config { src_ip_ranges [*] } } } # 限流规则action throttle100 RPM rule { action throttle priority 1000 match { versioned_expr SRC_IPS_V1 config { src_ip_ranges [*] } } rate_limit_options { conform_action allow exceed_action deny(403) rate_limit_threshold { count 100 interval_sec 60 } } } } # Backend BucketCACHE_ALL_STATIC无 cache_key_policydefault_ttl max_ttl resource google_compute_backend_bucket static { name ${var.architecture_name}-static-backend bucket_name var.static_bucket_name enable_cdn true cdn_policy { cache_mode CACHE_ALL_STATIC default_ttl 2592000 max_ttl 31536000 } } # Backend ServiceUSE_ORIGIN_HEADERS 模式下省略 default_ttl / client_ttl resource google_compute_backend_service api { name ${var.architecture_name}-api-backend protocol HTTP enable_cdn true security_policy google_compute_security_policy.waf_api.id cdn_policy { cache_mode USE_ORIGIN_HEADERS } }五、工作负载画像映射表事实源The Source of Truth这是全文档的事实源表格也是确定性输出指令所依据的唯一权威映射。Agent 生成任何 Origin 的 HCL 时都必须以其工作负载类型查表取参数不得自行调整Workload Typeenable_cdncdn_policy.cache_modedefault_ttlmax_ttlCache Key PolicyWAF Protection (Cloud Armor)Static Images / ObjectstrueCACHE_ALL_STATIC2592000(30d)31536000(365d)Host Protocol Path (Ignore Query Strings)None (Rate Limiting unsupported on CLOUD_ARMOR_EDGE)Cacheable APItrueUSE_ORIGIN_HEADERSOmitted (Managed by Origin)OmittedInclude Query StringsOWASP (SQLi/XSS/LFI) Rate Limit (100 RPM)Uncacheable API / TransactionsfalseN/AN/AN/AN/AOWASP (SQLi/XSS/RCE/Session Fixation) Strict Rate Limit (30 RPM) Bot ManagementDynamic Web (SSR)trueUSE_ORIGIN_HEADERSOmitted (Managed by Origin)OmittedHost Protocol Path (Bypass on session cookie)OWASP (SQLi/XSS/CSRF/Shellshock) Rate Limit (120 RPM)逐行解读Static Images / Objects静态资源全静态缓存默认 TTL 30 天、最大 TTL 365 天缓存键只取协议主机路径忽略查询字符串Backend Bucket 天然忽略查询串无需也不能配置cache_key_policy因后端通常是 Backend Bucket强制走 CLOUD_ARMOR_EDGE故WAF 限流置为 None。Cacheable API可缓存 API开启 CDN 但 TTL 交给源站响应头管理因此default_ttl/max_ttl均省略与静态资源相反缓存键必须包含查询字符串API 的 query 参数通常是响应内容的一部分WAF 侧启用 OWASP SQLi/XSS/LFI 三件套并以 100 RPM 的每客户端 IP 限流作为防滥用与防 DDoS 基线。Uncacheable API / Transactions不可缓存 API / 事务型登录、结算、账户变更等场景关闭 CDNenable_cdn false全链路直通源站WAF 侧启用 OWASP SQLi/XSS/RCE/Session Fixation叠加严格限流 30 RPM抵御凭证填充与暴力破解并启用Bot Management / Threat Intel拦截已知恶意机器人与恶意 IP。Dynamic Web (SSR)服务端渲染动态站点开启 CDN 且 TTL 交给源站缓存键取协议主机路径但存在会话 Cookie如 SESSID、JWT时旁路缓存避免把个性化页面错发给其他用户WAF 侧启用 OWASP SQLi/XSS/CSRF/Shellshock限流放宽到 120 RPM 以容纳首屏加载与资源水合hydration的突发请求。5.1 与 SKILL.md 推荐配置的对应关系该映射表并非孤立存在它是 SKILL.md Step 4Caching与 Step 5Security推荐配置的 HCL 化翻译SKILL.md Step 4 对静态资源给出的Cache All Static TTL(1d/30d/365d) ProtocolHostPath Brotli/Gzip 压缩负缓存 Serve while stale对应表中的 Static 行Step 5 对 Cacheable API 给出的100 RPM与 OWASP 三件套、对事务型 API 给出的30 RPM Bot Management、对 SSR 给出的120 RPM OWASP 四件套与表中 WAF 列完全一致。也就是说先由 SKILL.md 的交互流程确定工作负载标签再由 terraform-generation.md 的映射表机械翻译成 HCL两层文档形成闭环保证对话结论与产出代码零偏差。5.2 与 gcloud CLI 映射的对应关系同一套工作负载标签在 gcloud-generation.md 中对应为 CLI 参数版映射表如--cache-modeCACHE_ALL_STATIC --default-ttl2592000 --client-ttl86400 --max-ttl31536000、--actiondeny-403 --expressionevaluatePreconfiguredExpr(sqli-v33-stable) || ...。两条生成路线共享同一事实源只是输出载体不同——HCL 用cdn_policy/rule块CLI 用--cache-mode/--expression参数。选择哪条路线取决于用户在 Step 6 的选择。六、生成工作流从 Spec 到三文件产物terraform-generation.md定义了 5 步生成流程Agent 必须严格按序执行Consume Spec仔细阅读并解析提供的 Design Spec架构名称、项目、区域、协议、Origins 与工作负载类型、路由规则。Prepare Directory Structure创建专属子目录/gfe/deployments/{architecture_name}/目录隔离指令的具体落实。Assemble HCL生成variables.tf与terraform.tfvars定义architecture_name、project_id、region等输入变量将蓝图参数化在main.tf中生成terraform与provider块含~ 5.0版本约束对每个 Origin 创建对应的后端资源backend_bucket/backend_service/region_network_endpoint_groupname字段用架构名称动态前缀并按工作负载画像映射表注入属性为每个后端创建google_compute_security_policy资源依据映射表的 WAF 规则动态前缀命名依据路径与请求头路由规则创建google_compute_url_map创建前端资源target_http_proxy/target_https_proxy挂ssl_certificates以及global_forwarding_rule全部动态前缀。Output Code向用户交付完整、定稿的main.tf、variables.tf、terraform.tfvars三个文件不夹杂多余对话聚焦代码技术完整性。Hand-off代码输出后明确下一步动作Download Files或Deploy Configuration并引导用户转向 managed-deployment.md 的 Phase 2 Option A 完成部署预检与执行。6.1 产物文件示例variables.tf应将命名规则内建为变量校验从入口杜绝非法命名variable architecture_name { type string description 负载均衡架构名称作为全部资源的命名前缀 validation { condition can(regex(^a-z?$, var.architecture_name)) error_message architecture_name 必须为小写且匹配 ^a-z?$。 } } variable project_id { type string description 目标 Google Cloud 项目 ID } variable region { type string description 部署区域 default us-central1 }terraform.tfvars则承载具体值由 Design Spec 映射而来architecture_name my-storefront project_id my-gcp-project region us-central1main.tf依第 4、5 节所述的约束与映射表组装资源并通过引用语法google_compute_backend_service.example.id、module.security_policy_api.policy_id完成跨资源关联。七、与官方 Terraform 模块路线的协同对于复杂、生产级配置仓库中的 terraform-module.md 提供了另一条更省心的生成路线直接使用 Google 官方维护的模块负载均衡terraform-google-lb-http版本锁定~ 10.0Cloud Armor WAFterraform-google-cloud-armor版本锁定~ 2.0。该路线与本文档的关键衔接点是同一事实源模块路线的backendsmap 中每个后端同样必须配置protocol、enable_cdn、cdn_policy与security_policy参数取值仍遵循工作负载画像映射表同一约束模块示例中的rate_limiting_rules使用action throttlerate_limit_optionsOWASP 预配置规则通过evaluatePreconfiguredExpr(sqli-v33-stable)等表达式启用与手写资源级代码的约束完全一致版本纪律两条路线都必须锁定 provider~ 5.0与模块大版本防止破坏性变更。因此实际使用中可以把本文档视为约束与事实源把 terraform-module.md 视为官方模块封装写法两条路线按用户的熟悉程度二选一或互为校验。八、部署交接Hand-off 到 managed-deployment.md生成代码只是前半程。按文档第 5 步约定代码交付后必须引导用户进入 managed-deployment.md 完成落地其关键动作包括Phase 1强制 IAM 预检用gcloud config get-value account确认当前身份并校验目标项目上的resourcemanager.projects.get、compute.admin走 TerraformInfrastructure Manager路线还需config.admin与iam.serviceAccounts.actAs。若未提供自定义服务账号需确认默认服务账号service-{project_number}gcp-sa-inframanager.iam.gserviceaccount.com存在且具备editor/owner或compute.admin、storage.admin等授权。跳过预检的后果是基础设施部署一半、留下孤儿资源。Phase 2 Option AInfrastructure Manager 部署先清理本地.terraform目录Infrastructure Manager 对残留状态敏感再执行gcloud infra-manager deployments apply projects/{project_id}/locations/us-central1/deployments/{deployment_id} \ --local-source{local_source_dir} \ --service-account{service_account_email} \ --import-existing-resources必须显式指定--service-account否则校验报错且务必带上--import-existing-resources标志。随后用gcloud infra-manager deployments describe轮询状态直至ACTIVE需要清理时提供gcloud infra-manager deployments delete精确命令。部署完成后若后续发现控制台手工改动与代码状态不一致可继续使用 drift-detection.md 描述的gcloud infra-manager previews createresource-drifts list流程检测漂移并在回滚到代码Option A与把控制台改动回写进代码Option B之间二选一。九、生成质量自检清单将本文全部约束汇总为一份可执行的终检清单供生成 HCL 后逐项核对命名architecture_name与全部资源名小写、匹配^a-z?$且以架构名动态前缀目录代码位于/gfe/deployments/{architecture_name}/隔离目录Providerrequired_providers锁定google ~ 5.0Cloud Armor无顶层default_rule_action默认规则为priority 2147483647的rule块限流一律action throttleCLOUD_ARMOR_EDGE 策略Backend Bucket绝不带rate_limit_optionsBackend Bucket无cache_key_policydefault_ttl max_ttldefault_ttl 86400时显式设置max_ttlBackend ServiceUSE_ORIGIN_HEADERS时省略default_ttl/client_ttl无未经验证的request_coalescing映射一致性每个 Origin 的 CDN 与 WAF 参数与工作负载画像映射表逐列比对无误引用语法资源间全部使用引用而非硬编码名交接交付main.tf/variables.tf/terraform.tfvars三文件并给出 Download / Deploy 两个下一步动作与部署预检指引。至此从 Design Spec 到生产级 Terraform HCL再到 Infrastructure Manager 落地部署的完整链路即告打通。该文档的全部规则皆以消除部署错误、保证可复现性为最终目标任何一步的省略都可能转化为terraform validate报错、409 资源冲突或半部署事故——这也是本技能将这份生成指南设为独立参考文档的价值所在。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

google-cloud-global-frontend-configuration 技能实战：Google Cloud 全局外部应用负载均衡器 Terraform 代码生成指南

相关推荐

IoT-For-Beginners：将 Raspberry Pi 与虚拟设备接入 Azure IoT Edge 上的水果图像分类器

从扫雷项目掌握JavaScript数据结构与算法实战

3 步在 Minecraft 里生成真实城市：Arnis 世界生成实操指南

更多资讯

响应式中英双语建材展销网站模板的部署与改造实践

AI智能体生产环境生存能力评测：上下文韧性与工具链鲁棒性

mold 项目内嵌 TBB Flow Graph 的 sender 模板类：消息发送方接口与弃用迁移指南

手机购物商城HTML源码解析：从静态页面到可联调的前端原型

U-Net语义分割实战：从零构建像素级图像理解系统

KubeSphere 内置 zap v1.27.0 演进全解：从 CHANGELOG 看结构化日志库的 API 迭代与实战要点

今日更新

51单片机开环控制磁阻传感器的硬件匹配与代码实现

AI Agent安全操作数据库：SQL注入防御与参数化查询实战

Android逆向实战：还原激励类App签到接口的签名算法

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？