Back to Details

google-cloud-global-frontend-configuration

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Google Cloud global external Application Load Balancer Configuration Skill

Google Cloud全球外部应用负载均衡器配置Skill

Purpose & Agent Guidance

用途与Agent指引

This skill enables the agent to guide users through a structured, 6-step discovery process to design and deploy Google Cloud global external Application Load Balancers (incorporating Cloud CDN, Cloud Armor, and Service Extensions).
Assumptions & Target Environments:
  • This skill assumes it is called from environments (such as Gemini CLI, Antigravity, etc.) where the Google Cloud CLI (
    gcloud
    ) can be executed.
  • If 
    gcloud
    is not available or accessible, the skill cannot perform automated resource discovery or managed deployment actuation. In such environments, the skill will limit its support to guiding the design and generating Terraform HCL configurations.
When executing this skill, the agent must:
  • Map user workload requirements to simplified, opinionated best-practice configurations using actual Google Cloud product names.
  • Progressively disclose details, hiding advanced complexity unless the user explicitly asks for customization.
  • Leverage the reference documents in the 
    references/
    directory to perform resource discovery, code generation, actuation, and drift detection.
本技能使Agent能够引导用户通过结构化的6步发现流程，设计并部署Google Cloud全球外部应用负载均衡器（集成Cloud CDN、Cloud Armor和Service Extensions）。
假设与目标环境：
  • 本技能假设从可执行Google Cloud CLI（
    gcloud
    ）的环境（如Gemini CLI、Antigravity等）中调用。
  • 如果
    gcloud
    不可用或无法访问，本技能无法执行自动化资源发现或托管部署操作。在此类环境中，技能将仅提供设计指导并生成Terraform HCL配置。
执行本技能时，Agent必须：
  • 使用实际Google Cloud产品名称，将用户的工作负载需求映射到简化、经过验证的最佳实践配置。
  • 逐步披露细节，除非用户明确要求自定义，否则隐藏高级复杂度。
  • 利用
    references/
    目录中的参考文档执行资源发现、代码生成、部署操作和漂移检测。

The 6-Step Configuration Flow

6步配置流程

Step 1: Basics

步骤1：基础设置

  • Project Discovery: Consult 
    references/resource-discovery.md
    to auto-detect the Google Cloud project ID. Present the discovered project ID to the user.
  • Ask the user for the foundational details of their load balancer:
    • Name & Description: What should we call this load balancer?
    • Protocol Selection: Do they need HTTP, HTTPS, or both?
    • Certificate Management: Do they want to use Google-managed certificates or bring their own existing certificates?
  • 项目发现： 查阅
    references/resource-discovery.md
    自动检测Google Cloud项目ID，并向用户展示发现的项目ID。
  • 向用户询问负载均衡器的基础信息：
    • 名称与描述： 该负载均衡器的名称是什么？请描述其用途。
    • 协议选择： 需要HTTP、HTTPS，还是两者都需要？
    • 证书管理： 是使用Google托管证书，还是自带现有证书？

Step 2: Origin Configuration

步骤2：源站配置

Help the user define their backend workloads through a strictly sequential, step-by-step loop. Do NOT ask everything at once. All steps are mandatory.
  • Sub-step A - Origin Setup: Ask if they have a single origin or need multi-origin support. Wait for response.
  • Sub-step B - Origin Types: Ask them to select the backend types from: Cloud Storage Buckets, Compute Engine Managed Instance Groups (MIGs), Google Kubernetes Engine (GKE) Clusters, Cloud Run Services, or External/Internet origins (IP/FQDN). Wait for response.
  • Sub-step C - Origin Definition Loop: Execute the following loop sequentially for EACH origin type selected in Sub-step B. Wait for the user to answer for one origin before asking about the next:
    • Resource Discovery: For Google Cloud-native origins (Cloud Storage, MIGs, GKE, Cloud Run), consult 
      references/resource-discovery.md
      to fetch resources. Present the list starting with 1. Create New, 2. NA. For External/Internet origins, just ask for the FQDN/IP.
    • Workload Type (CRITICAL): Immediately after they define the resource, ask exactly what type of workload is being served:
      1. Static Images / Objects (Static content, images, videos, styling assets)
      2. Cacheable API (Read-only, public APIs where cached data is acceptable)
      3. Uncacheable API / Transactions (Transactional endpoints, login, checkout, account changes)
      4. Dynamic Web (SSR) (Dynamic pages, server-side rendered apps, custom dynamic sessions)
  • Sub-step D - Routing Rules: Once ALL origins have been fully defined one by one, ask how traffic should be routed between them (Path-based, header-based, or query-param-based). Wait for response.
  • Sub-step E - Logging: After routing is established, ask if they want to enable Cloud CDN logging, and if so, at what sampling rate (0-100%). Wait for response.
通过严格的分步循环帮助用户定义后端工作负载。请勿一次性询问所有内容，所有步骤均为必填项。
  • 子步骤A - 源站设置： 询问用户是使用单源站还是需要多源站支持，等待用户回复。
  • 子步骤B - 源站类型： 请用户从以下后端类型中选择：Cloud Storage存储桶、Compute Engine托管实例组（MIG）、Google Kubernetes Engine（GKE）集群、Cloud Run服务，或外部/互联网源站（IP/域名），等待用户回复。
  • 子步骤C - 源站定义循环： 对子步骤B中选择的每一种源站类型依次执行以下循环，在用户答复一个源站的信息后再询问下一个：
    • 资源发现： 对于Google Cloud原生源站（Cloud Storage、MIG、GKE、Cloud Run），查阅
      references/resource-discovery.md
      获取资源列表，展示时以1. 创建新资源、2. 不适用开头。对于外部/互联网源站，直接询问其域名/IP。
    • 工作负载类型（关键项）： 用户定义资源后，立即询问该资源承载的工作负载类型：
      1. 静态图片/对象（静态内容、图片、视频、样式资源）
      2. 可缓存API（只读、公开API，允许缓存数据）
      3. 不可缓存API/交易类（交易端点、登录、结账、账户变更）
      4. 动态网页（SSR）（动态页面、服务器端渲染应用、自定义动态会话）
  • 子步骤D - 路由规则： 在所有源站逐一完成定义后，询问流量应如何在源站之间路由（基于路径、基于请求头或基于查询参数），等待用户回复。
  • 子步骤E - 日志记录： 确定路由规则后，询问是否启用Cloud CDN日志，若启用，采样率为多少（0-100%），等待用户回复。

Step 3: Traffic Management & Extensibility

步骤3：流量管理与扩展性

  • Provide a brief summary of the origins and routing rules defined in Step 2.
  • Ask if they need to enable Advanced Traffic Management settings (such as granular weighted load balancing, traffic mirroring, or Cloud Load Balancing Service Extensions for custom WASM plugins / callouts), or if they want to proceed with Google Cloud Best Practice Configuration.
  • 简要总结步骤2中定义的源站和路由规则。
  • 询问用户是否需要启用高级流量管理设置（如精细加权负载均衡、流量镜像，或用于自定义WASM插件/调用的Cloud Load Balancing Service Extensions），还是希望采用Google Cloud最佳实践配置。

Step 4: Caching (Cloud CDN)

步骤4：缓存（Cloud CDN）

Propose a "Recommended Configuration" based entirely on the Workload Type from Step 2. Do not list the advanced settings (TTL, Cache Keys, Compression) unless they reject the recommendation and want to customize.
  • If Workload = Static Images / Objects:
    • Cache Mode: Cache All Static
    • TTL: Client (1 day / 86400s), Default (30 days / 2592000s), Max (365 days / 31536000s) — balances long-term cache offload for static assets with periodic re-validation.
    • Cache Key: Protocol + Host + Path (Ignore Query Strings)
    • Compression: Enabled (Brotli & Gzip)
    • Negative Caching: Enabled
    • Serve while stale: Enabled
  • If Workload = Cacheable API:
    • Cache Mode: Use Origin Headers
    • TTL: Managed by Origin (Omitted from configuration to prevent errors)
    • Cache Key: Protocol + Host + Path + Include Query Strings
    • Compression: Enabled (Gzip)
    • Negative Caching: Enabled
    • Serve while stale: Disabled
  • If Workload = Uncacheable API / Transactions:
    • Cache Mode: Disabled (CDN Bypassed)
  • If Workload = Dynamic Web (SSR):
    • Cache Mode: Use Origin Headers
    • TTL: Managed by Origin (Omitted from configuration to prevent errors)
    • Cache Key: Protocol + Host + Path
    • Compression: Enabled (Brotli & Gzip)
    • Cache Bypass: Bypass cache if session cookies (e.g., SESSID, JWT) are present
完全基于步骤2中的工作负载类型提出「推荐配置」，除非用户拒绝推荐并要求自定义，否则不列出高级设置（TTL、缓存键、压缩）。
  • 若工作负载 = 静态图片/对象：
    • 缓存模式：缓存所有静态内容
    • TTL：客户端（1天/86400秒）、默认（30天/2592000秒）、最大值（365天/31536000秒）——在静态资源的长期缓存卸载与定期重新验证之间取得平衡。
    • 缓存键：协议 + 主机 + 路径（忽略查询字符串）
    • 压缩：启用（Brotli & Gzip）
    • 负向缓存：启用
    • stale时提供服务：启用
  • 若工作负载 = 可缓存API：
    • 缓存模式：使用源站响应头
    • TTL：由源站管理（配置中省略以避免错误）
    • 缓存键：协议 + 主机 + 路径 + 包含查询字符串
    • 压缩：启用（Gzip）
    • 负向缓存：启用
    • stale时提供服务：禁用
  • 若工作负载 = 不可缓存API/交易类：
    • 缓存模式：禁用（绕过CDN）
  • 若工作负载 = 动态网页（SSR）：
    • 缓存模式：使用源站响应头
    • TTL：由源站管理（配置中省略以避免错误）
    • 缓存键：协议 + 主机 + 路径
    • 压缩：启用（Brotli & Gzip）
    • 缓存绕过：若存在会话Cookie（如SESSID、JWT）则绕过缓存

Step 5: Security (Cloud Armor)

步骤5：安全（Cloud Armor）

Propose a "Recommended Configuration" based entirely on the Workload Type from Step 2. Keep advanced protection (Bot Management, Threat Intel, Geo-blocking) hidden unless requested.
  • If Workload = Static Images / Objects:
    • Rate Limiting: None (Standard Edge behavior; rate limiting is unsupported on Cloud Armor Edge policies for Cloud Storage buckets).
    • OWASP Protection: Disabled
  • If Workload = Cacheable API:
    • Rate Limiting: 100 requests per minute per client IP (standard baseline to prevent API abuse and DDoS while accommodating normal interactive usage).
    • OWASP Protection: Enabled (SQLi, XSS, Local File Inclusion)
  • If Workload = Uncacheable API / Transactions:
    • Rate Limiting: Strict 30 requests per minute per client IP (tight threshold to protect sensitive transactional endpoints like login/checkout from credential stuffing and brute-force attacks).
    • OWASP Protection: Enabled (SQLi, XSS, Remote Command Execution, Session Fixation)
    • Bot Management & Threat Intel: Enabled (Block malicious bots and known malicious IPs)
  • If Workload = Dynamic Web (SSR):
    • Rate Limiting: 120 requests per minute per client IP (generous threshold to accommodate burst requests for initial page loads and asset hydration in SSR web applications).
    • OWASP Protection: Enabled (SQLi, XSS, CSRF, Shellshock)
    • Geo-blocking: Optional (Restrict/allow specific country access)
完全基于步骤2中的工作负载类型提出「推荐配置」，除非用户要求，否则隐藏高级防护功能（Bot管理、威胁情报、地域封禁）。
  • 若工作负载 = 静态图片/对象：
    • 速率限制：无（标准边缘行为；Cloud Armor边缘策略不支持Cloud Storage存储桶的速率限制）。
    • OWASP防护：禁用
  • 若工作负载 = 可缓存API：
    • 速率限制：每个客户端IP每分钟100次请求（标准基准，可防止API滥用和DDoS，同时满足正常交互使用）。
    • OWASP防护：启用（SQL注入、跨站脚本、本地文件包含）
  • 若工作负载 = 不可缓存API/交易类：
    • 速率限制：每个客户端IP每分钟严格限制30次请求（严格阈值，保护登录/结账等敏感交易端点免受凭证填充和暴力攻击）。
    • OWASP防护：启用（SQL注入、跨站脚本、远程命令执行、会话固定）
    • Bot管理与威胁情报：启用（拦截恶意Bot和已知恶意IP）
  • 若工作负载 = 动态网页（SSR）：
    • 速率限制：每个客户端IP每分钟120次请求（宽松阈值，以适应SSR Web应用初始页面加载和资源 hydration 的突发请求）。
    • OWASP防护：启用（SQL注入、跨站脚本、跨站请求伪造、Shellshock）
    • 地域封禁：可选（限制/允许特定国家/地区访问）

Step 6: Review & Deploy

步骤6：审核与部署

  • Configuration Summary: Generate a complete, formatted markdown table showing all finalized settings from Steps 1 through 5, using Google Cloud product names. Follow this exact template structure:
    ComponentParameter / SettingValue & Justification
    Load BalancerName & Protocol
    <Name>
    (HTTP/HTTPS)
    OriginsBackends & Workloads
    <Backend 1>
    (
    <Workload Type>
    ), 
    <Backend 2>
    ...
    Traffic ManagementRouting Rules
    <Path / Header rules or Default>
    Cloud CDNCache Mode & TTLs
    <Cache Mode>
    , Default TTL: 
    <TTL>
    Cloud ArmorRate Limiting & OWASP
    <RPM Limit>
    , OWASP Rules: 
    <Enabled/Disabled>
    Service ExtensionsWASM / Callouts
    <Enabled/Disabled or N/A>
  • Next Action: Ask the user to choose their deployment/generation format (Terraform HCL or gcloud CLI Bash Script) and their next action:
    1. Show Code / Script (Display the HCL code or gcloud bash script. Once displayed, offer options to Download or Deploy/Execute)
    2. Download files (Save 
      main.tf
      or 
      deploy.sh
      to the local workspace)
    3. Deploy Configuration: Initiate the deployment via Infrastructure Manager or execute the gcloud script. This should be done using the deployment instructions in 
      references/managed-deployment.md
      .
  • 配置摘要： 使用Google Cloud产品名称生成完整的格式化Markdown表格，展示步骤1至步骤5中所有最终确定的设置，严格遵循以下模板结构：
    组件参数/设置值与说明
    负载均衡器名称与协议
    <名称>
    （HTTP/HTTPS）
    源站后端与工作负载
    <后端1>
    （
    <工作负载类型>
    ）, 
    <后端2>
    ...
    流量管理路由规则
    <路径/请求头规则或默认配置>
    Cloud CDN缓存模式与TTL
    <缓存模式>
    ，默认TTL：
    <TTL值>
    Cloud Armor速率限制与OWASP
    <每分钟请求限制>
    ，OWASP规则：
    <启用/禁用>
    Service ExtensionsWASM/调用
    <启用/禁用或不适用>
  • 下一步操作： 请用户选择部署/生成格式（Terraform HCL或gcloud CLI Bash脚本）以及后续操作：
    1. 查看代码/脚本（展示HCL代码或gcloud bash脚本，展示后提供下载或部署/执行选项）
    2. 下载文件（将
      main.tf
      或
      deploy.sh
      保存到本地工作区）
    3. 部署配置： 通过Infrastructure Manager启动部署或执行gcloud脚本。此操作需遵循
      references/managed-deployment.md
      中的部署说明。

Relevant Documentation & Supportive Links

相关文档与支持链接