现在公司多多少少都会用一些开源的软件，我在工作中也部署和维护了很多开源软件。这篇文章就讲讲维护这些软件的一些经验。我主要想说的，是那些需要部署的服务，比如 Jenkins，Prometheus 这些。命令行工具，和库之类的，不在讨论的范围内（但是有一些经验是同样适用的）。

技术选型

如果能解决问题的方案有很多的话，选择哪一种来使用呢？

对开源软件技术选型的时候，可以参考的因素有：

口碑，被接受程度。如果软件的用户越多，那么存在的问题暴露的概率就越大，网上的资料也越多。需要去踩的坑也就越少。

已经存在的时间。同上，久经考验的软件相对可靠一些。

API 和 开放性。这一点容易被忽略。如果有 API 支持的话，在结合公司内部其他系统的时候就会简单很多。也可以做更多定制化的功能。存储使用的格式是什么？如果是公开的标准的话，比如 VictoriaMetrics 有针对 Prometheus 很方便的导入和导出，之后迁移会简单很多，就算以后不用这个软件了，也能很容易地换到其他的方案上。

做决策的支持一部分是知识，一部分是信息。信息就主要来自于项目文档。项目的 issue 页面，和社区讨论也值得参考。

项目文档建议仔细阅读一遍，能得到不少 insights。我经常在解决一个问题的时候，苦于不知道这个工具是否提供了某种方案可以解决这个问题。如果度过一遍文档的时候，遇到问题，你至少能想起某一个关键字。

读文档看似是挺花费时间的，但其实是节省时间。它至少可以加深你对软件的了解。（我发现我花时间最多的，就是用一个工具干不适合它干的事情……）

从 0 到 1 搭建

新部署一个开源软件，主要需要解决两个方面的问题。

第一个问题是如何将它部署到自家公司的基础设施中。常见的部署方法有：

• 直接在机器上安装 Docker，然后一个 Docker 命令启动；
• 写 ansible playbook 部署
• 使用 k8s （一般公司内部都会有定制化）

对于合适的软件选择合适的部署方法非常重要。不要小看一行命令 Docker 部署这种方式，对于有些软件来说非常合适，比如 Jenkins，它的 Java 依赖比较难处理，又有很多系统依赖，但是本质是一个非常独立的单体应用，依赖的内容存储在一个单一的文件夹中，这种就非常适合用 Docker 部署了，升级和重启都是一行命令。虽然是手动操作，但这种方式几乎是效率最高的。

WordPress 是一个特殊的例子，这个软件有一些神奇的功能，比如在后台点一下，它可以去更新自己的代码，升级插件代码，甚至能升级自己本身。所以我将 wordpress 的运行环境整个都放在一个 Git 中，追踪代码的变化。

第二个问题是解决依赖，软件一般都有对其他服务的依赖，最常见的是存储。这部分选型的时候也可以考虑，一般依赖越少越好。比如 Jenkins，这个东西很神奇，基本上只依赖一个 $HOME_DIR， 给它一个文件夹，其他什么都不需要了，对升级和备份特别友好。其他依赖比如网关怎么接入，用户怎么登陆，后端的存储怎么维护，等等。

定制功能

官方的版本没有办法满足所有人的需求，我们经常需要对软件进行定制化。

需要强调的是，最好使用软件支持的一些插件的格式来做，比如 Jenkins, CoreDNS, K8s 等等，都支持插件。还有一些像是 Prometheus，可以通过写外部服务的方式做定制化的功能。

下下策就是直接 fork 修改软件的代码，这样就脱离主干了，后面很难跟进官方的升级。（不过要是能直接给官方提交 PR，是一个不错的方式）

升级

这其实是一个很重要的问题，就是要跟进官方的更新。

为什么说很重要呢？我见过很多故事，都是安装上一个软件版本，之后就再也不更新了，因为跑的好好的，没有人想去动（大部分软件都是这样，你通过它的版本就可以发现它是什么时候引入公司的，笑）。或者是因为 fork 修改了代码，升级升不动。然后从这个版本开始，存在的问题，可能你都要自己解决一遍。可能官方已经发布修复或者优化了，但是因为没有升级，就没办法享受到。甚至你都不知道这个更新。

所以建议订阅官方的发布记录，一般都会有提供 RSS 的订阅方式。

要阅读每一个版本的 changelog。

最好不要进行跨版本升级，因为有些不兼容修改可能会导致问题（还是以官方的升级指引为准）。

还可以订阅一些核心开发者的消息动态，看看大家都在关心什么问题，解决什么问题。

支持

最后，使用软件的过程中一定会遇到各种问题。如果当前没有解决方案，但是又有很多人有同样的问题，那么可以尝试自己去解决一下。（回馈社区！）

报告问题，在某种程度上也是一种支持。但是要把问题说清楚，提交可以复现的 Case。

如果没精力，那么捐点钱也是很大的支持。

---