多代码库使用dispatch.yaml部署时如何避免覆盖域名映射？

问题背景 #

三个独立代码库各配有专属dispatch.yaml：

• 代码库A的dispatch.yaml：

url: website-a.com/*
  service: website-a-web-app

• 代码库B的dispatch.yaml：

url: website-b.com/*
  service: website-b-web-app

• 代码库C的dispatch.yaml：

url: website-c.com/*
  service: website-c-web-app

部署前状态：

• 网站A：website-a.com → website-a-web-app
• 网站B：website-b.com → website-b-web-app
• 网站C：website-c.com → website-c-web-app

部署网站A后，B、C的域名映射被完全清除，状态变为：

• 网站A：website-a.com → website-a-web-app
• 网站B：default-website.com → default
• 网站C：default-website.com → default

当前使用的Cloud Build部署脚本：

timeout: 1200s
steps:
- name: 'node:14.20.0'
  entrypoint: npm
  args: ['install']

- name: 'node:14.20.0'
  entrypoint: npm
  args: ['install', '-g', '@angular/cli']

- name: 'node:14.20.0'
  entrypoint: npm
  args: [ 'run', 'build:$_BUILD_COMMAND', "--prod" ]

- name: "gcr.io/cloud-builders/gcloud"
  args: ["app", "deploy"]

- name: "gcr.io/cloud-builders/gcloud"
  args: ["app", "deploy", "dispatch.yaml"]

问题原因 #

gcloud app deploy dispatch.yaml 命令执行的是全量替换逻辑，会将全局dispatch配置直接替换为当前文件内容。每个代码库的dispatch.yaml仅包含自身服务的路由规则，部署时会覆盖掉其他服务的配置，导致B、C的映射规则丢失。

解决方案 #

1. 集中管理全局dispatch.yaml（推荐） #

创建独立代码库存放包含所有服务规则的全局dispatch.yaml，统一维护路由配置：

dispatch:
  - url: website-a.com/*
    service: website-a-web-app
  - url: website-b.com/*
    service: website-b-web-app
  - url: website-c.com/*
    service: website-c-web-app

各服务部署时不再单独执行dispatch.yaml部署步骤，仅当全局路由规则变更时，从这个集中库触发dispatch配置的更新。这种方式避免了重复配置，也彻底解决了覆盖问题。

2. 部署前拉取全局配置并合并（临时过渡方案） #

如果暂时无法调整为集中管理，可以在部署脚本中新增步骤，先拉取当前全局dispatch配置，合并当前服务的规则后再部署：
修改后的Cloud Build脚本：

timeout: 1200s
steps:
- name: 'node:14.20.0'
  entrypoint: npm
  args: ['install']

- name: 'node:14.20.0'
  entrypoint: npm
  args: ['install', '-g', '@angular/cli']

- name: 'node:14.20.0'
  entrypoint: npm
  args: [ 'run', 'build:$_BUILD_COMMAND', "--prod" ]

- name: "gcr.io/cloud-builders/gcloud"
  args: ["app", "deploy"]

# 拉取当前全局dispatch配置
- name: "gcr.io/cloud-builders/gcloud"
  entrypoint: "bash"
  args: ["-c", "gcloud app dispatch describe --format yaml > current-dispatch.yaml"]

# 合并当前服务的路由规则（需编写合并脚本）
- name: 'node:14.20.0'
  entrypoint: node
  args: ['./merge-dispatch.js']

# 部署合并后的配置
- name: "gcr.io/cloud-builders/gcloud"
  args: ["app", "deploy", "merged-dispatch.yaml"]

merge-dispatch.js 核心逻辑示例：

• 读取current-dispatch.yaml中的全局路由规则
• 读取本地dispatch.yaml的规则
• 移除全局配置中与当前服务域名匹配的旧规则
• 添加本地的新规则
• 将合并结果写入merged-dispatch.yaml

3. 使用服务部署的--dispatch标志（仅适用于简单场景） #

部分简单场景下，可使用 gcloud app deploy --dispatch 自动生成基础dispatch规则，但该方式仅支持单域名对应单服务的简单映射，无法满足复杂路由需求。

总结 #

最易维护且可靠的方案是集中管理全局dispatch.yaml，既避免了配置覆盖问题，也减少了重复配置的维护成本。

内容的提问来源于stack exchange，提问作者Joe Alvini