一种网格间部署流水线

# 一个网格间部署流水线 Source: https://blog.zm.is/an-inter-mesh-deployment-pipeline/ 我处理大规模环境漂移时的经验，以及我为了尝试补救这些问题而发明的东西。 ## 一个网格间部署流水线 我有大约 72 个不同的应用，以及两个环境：暂存环境和生产环境。通常的思路是先部署到暂存环境，测试一下，然后再提升到生产环境。但实际上，没有任何工具强制要求这样做，所以这个步骤经常被跳过。随着时间推移，环境逐渐漂移，暂存环境很快就被遗忘，不再作为测试场所。我决定改变这一现状，于是创建了一个连接器，作为两个网格之间的桥，允许生产环境要求暂存环境构建、测试然后交付任何组件。其中一个主要挑战是：要检查两个环境是否配置完全相同，就必须确切知道“应该是什么样”，这让我首先想到用这种方法来部署*新的*应用。毕竟，如果它知道如何成功部署一个新应用，为什么没有这种能力呢？一旦部署完成，就可以从生产环境点击“Pull from staging”来发起更新，这会产生一份完全可审计的日志，随后发生以下事件： 部署可以通过 API/MCP 触发，从而增加一个步骤（如图）。黑色箭头是出站方向，红色箭头是返回路径。 `proc-mesh` 是一个特殊组件，它以非特权方式运行，没有网络，只有一个 Unix 套接字。我决定不编写任何持续以 `root` 身份运行的程序，而是在需要时使用 `doas` 进行经过仔细审计的权限提升，由 `proc-mesh` 调用。其他组件都设置了 `NoNewPrivileges=yes`，所以即使它们想用 `doas`，也无法使用。必须采用分层的安全方法：获得特权的同时会失去网络访问能力。 ``` permit nopass xfproc as root cmd /usr/local/sbin/xf-restart-plug permit nopass xfproc as root cmd /usr/local/sbin/xf-trustbase-verify # Install a staged artifact: . The bridge owns the # allowlist and derives both the artifact path and the destination itself. permit nopass xfproc as root cmd /usr/local/sbin/xf-install-binary ``` 日志中显示：工件以二进制形式通过 NATS 桥拉取。没有 Git 发布。并且在每个阶段都完全可审计： 既然它知道如何检查现有应用的设置并创建新应用，那么执行批量任务（如让环境重新同步）就变得容易了。每个应用都先暂存、测试，然后再交付到生产环境。 #### 接下来是什么？ 你可能已经发现了一个问题：`plug-mesh` 无法部署自身，仍然使用我旧的 Gitea runner 部署路径。我最初针对它自身部署的解决方案是，将一个新的 `plug-mesh` 连接到隔离的网格间 NATS 桥（这不同于主桥——主桥连接一个网格内的所有组件），并在那里使用现有的 `plug-mesh` 组件对其进行测试，然后让新的实例杀死旧的实例，并无缝过渡到主 NATS 网络。理论上，这行得通，但在实践中，我发现自己并不经常修改这个组件，因此觉得没有必要让它能够部署自身。如果我确实要实现这一点，这很可能是更智能部署路径的副作用：该路径采用更严格的测试，在不停止旧组件的情况下暂存新组件，并且需要隔离的 NATS。目前，我们接受暂存环境可能会出问题，而这正是其意义所在。如果暂存一个应用失败了，嗯，至少它不在生产环境上！