对于我们来说，拥有一个 Jenkins Docker 镜像用于 4 个不同的 Jenkins 主服务器且具有不同的 Jenkins 配置，这有点不舒服。
我们使用一个环境变量来加载正确的 Jenkins xml 配置文件，但是我们所做的每个配置更改都必须手动烘焙回 Docker 镜像中，否则下次容器重启时更改将会丢失，等等。
Jenkins 显然不是完美的云原生 Docker 镜像候选者，但我们别无选择。处理这个问题的正确方法是什么？如果已经存在 1 个 Jenkins 配置文件，是否完全排除覆盖？
答案1
我觉得你的问题缺少很多必要的背景信息来给出有意义的答案，但如果没有更多的信息，我会谨慎地回答“是的，你应该将你的 Jenkins 配置与你的 Docker 镜像打包在一起”。
作为参考，这里有一篇博客文章详细介绍了一位管理员如何通过 Docker + Kubernetes + Helm 部署 Jenkins。该项目明确提出的目标之一是部署和版本控制整个 Docker 映像，包括配置、插件等（参见第 2 点）：
形状
经过大量研究，目标的总体框架很快就成型了。稍后我们会详细讨论每个目标，但首先让我们将其分解为要点：
- 部署在 Kubernetes 上，因为这是我们尝试移动一切的方式。
- 构建一个包含 Jenkins、所有插件和配置的容器镜像。
- 使用 Helm 来管理部署（并在需要时回滚）。
- 尽可能通过 Jenkins groovy 管理配置。
- 使用 Jenkins 中的“组织文件夹”系统自动检测项目。
- 使用共享管道库来保持每个存储库的配置较低。
- 为食谱测试环境构建一个容器镜像，其中已预先安装所有需要的 gem。
- 设计一种在 Kubernetes pod 上测试菜谱的方法。
您拥有 4 个不同的 Jenkins 实例这一事实实际上并没有改变任何事情，这仅意味着您有 4 个不同的服务需要独立管理和部署。如果您想减少一点重复，您可以让所有这些镜像都从基本 Jenkins 镜像继承。