如果 这 两 个 服务 要 共享 代码 ， 它们 可能 应该 尽 可能 " 一起 " 部署 ， 以便 代码 始终 保持 同步 ; Docker 图像 是 一 个 很 好 的 工具 ， 因为 它 可以 通过 图像 哈希 对 工件 进行 完整 的 " 修订 " 。
容器 可以 通过 多种 方式 检测 它 是 作为 * service * 还是 * job * 运行 ， 然后 相应 地 调用 代码 （ 服务 器 将 侦听 并 提供 服务 ， job 将 下拉 参数 并 开始 工作 ） 。
以下 是 该 领域 的 一些 好 选择 ， 并 进行 了 简要 的 利弊 比较 ：

# # # 使用 一 个 映像 实现 的 方法

• • 1 ） 环境 变量 。 * * 您 可以 在 Cloud Run 服务 和 Cloud Run 作业 中 分配 不同 的 环境 变量 ， 以便 您 的 容器 可以 检测 它 的 运行 位置 。
• • • 优点 ： * *
• 从 python （ import os; os.environ["IS_JOB"] 等 ） 中 使用 简单 明 了
• 灵活 ， 适用 于 几乎 所有 环境 （ 例如 ， 如果 您 有 一 天 不再 使用 Cloud Run ）
• 适用 于 任何 语言 ， 而 不仅仅 是 Python
• • • 缺点 ： * *
• 难以 传达 结构 ， 未 键入
• 会 使 测试 复杂 化 ;在 一 个 充满 嘲讽 的 环境 中 很 难 做 对
• 可以 在 任何 需要 的 地方 随意 访问 ， 这 意味 着 重构 它 可能 很 困难
• • 2 ） 命令 参数 。 * * 可能 您 向 容器 传递 了 一 个 参数 ， 告诉 它 是 服务 还是 作业 ， 就 像 env var 一样 。
• • • 优点 ： * *
• 基本 上 与 env 变量 相同 。
• 但 只能 访问 您 的 二 进制 代码 ， 不能 渗透 到 其他 代码 中 。
• 在 代码 中 只有 一 个 地方 可以 访问 它 ， 这 比 env vars 更 简洁
• • • 缺点 ： * *
• 必须 在 您 的 入口 点 访问 价值 ， 并 保存 它 ， 而 不是 在 任何 需要 的 地方 随意 访问 os.environ 。
• • 3 ） 令牌 标识 。 * * 可以 为 作业 和 服务 分配 不同 的 服务 帐户 ， 这 对于 安全 卫生 来说 是 个 好 主意 。 然后 ， 容器 可以 根据 此 服务 帐户 的 标识 检测 其 运行 位置 。
• • • 优点 ： * *
• 可以 完全 从 代码 中 检测 到 ， 而 无需 任何 非 密封 输入 ， 如 环境 变量 （ 即 ， 它 可以 说 是 更 干净 和 更 好 的 抽象 ）
• 完全 类型 化 ， 由于 Google 一流 的 Python SDK 支持 ， 可能 是 最 容易 测试/模拟 的 版本
• • • 缺点 ： * *
• 将 你 的 代码 与 Cloud Run 或者 至少 是 Google Cloud 紧密 结合 起来 。 如果 你 有 一 天 想 移动 它 ， 它 会 使 你 的 重构 复杂 化 。
• 可能 是 编写 起来 最 复杂 的 （ 尽管 env 变量 是 一 个 较 低 的 标准 ）

# # # 与 多 个 图像 进行 比较

最 后 ， 不管 你 怎么 做 ， 最 好 使用 一 个 图像 。 让 我们 比较 一下 这 两 种 不同 Dockerfile 的 方法 ：

• • • 运行 成本 更 低 。 * * 如果 您 有 两 个 Docker 映像 ， 则 需要 为 存储 两 个 映像 、 提供 两 个 映像 等 付费 。 根据 您 的 开发 速度 ， 此 成本 可能 会 高 得 惊人 ， 尤其 是 在 您 使用 Cloud Artifact Registry 或 类似 产品 时 。
• • • 构建 速度 更 快 。 * * 使用 两 个 容器 ， 您 的 Docker 构建 时间 将 翻倍 。 也许 您 可以 通过 多 阶段 构建 来 节省 时间 ， 但 您 仍然 需要 存储 、 服务 和 上传/下载 两 个 映像 ， 而 不是 一 个 。
• • • 更 容易 保持 同步 。 * * 无需 确保 两 个 映像 哈希 完全 对齐 ， 或者 同时 更新 和 启动 ， 等等 。
• • • 更 容易 比较 状态 。 * * 不 需要 搜寻 以 确定 作业 和 服务 是否 为 相同 版本 。 如果 哈希 匹配 ， 就 可以 开始 了 。
• • • 更 容易 测试 。 * * 因为 您 只有 一 个 软件 输出 ， 所以 这 可能 会 让 您 更 容易 测试 服务 和 工作 如何 一起 运作 。 在 公寓 测试 中 ， 将 程式 码 放在 一起 ， 您 就 可以 同时 叫 用 工作/服务 。

这 两 个 映像 的 优势 相当 有限 ：

• • • 诊断 。 * * 如果 它们 位于 单独 的 映像 中 ， 可能 更 容易 区分 或 诊断 问题 ， 但 这 有点 难以 实现 ， 因为 您 最 大 的 问题 可能 只是 保持 两 个 映像 同步 。
• • • 单独 更新 。 * * 如果 代码 更改 只 涉及 作业 或 服务 中 的 一 个 ， 则 可以 跳过 其中 的 一些 更新 。 如果 这 是 一 个 大 问题 ， 则 它 可能 会 超过 单 映像 体系 结构 的 好处 。
• • • 图像 大小 。 * * 也许 您 可以 通过 分离 两 个 图像 的 代码 来 节省 一些 大小 ， 从而 节省 两 个 图像 的 责任 ， 但是 您 在 这里 节省 的 可能 是 兆 字节 的 数量 级 ;并且 您 可能 会 以 一 个 数量 级 或 更 高 的 数量 级 来 超过 这种 节省 ， 因为 首先 要 复制 图像 。

所以 ， 总 而言 之 ， 如果 我 是 你 ， 我 会 做 一 个 形象 ;但 答案 取决 于 您 的 应用 程序 、 您 的 需求 、 您 的 工作 流 等等 。