最近干了一件非常非常愚蠢的事情，背景是这样的：有个奇葩驻地，宿主机的安全扫描的agent扫到了容器里的Redis进程，然后就以Redis版本过低为由要求整改。版本是多少呢？是空，因为宿主机根本无法访问容器内自用的Redis，但是呢，搞安全的这些并不懂安全的可不管这么多。
于是，问题来了，需要对容器的镜像的Redis升级，容器是很早做的了，CentOS 7，Redis是3.0系的，最低要求升级到6.2.19。
换成你的话，这镜像你打算怎么处理？
当时我是这么思考的，CentOS 7早废弃不维护了，那么用CentOS Stream 10可以让镜像的系统得到最长支持时间（01 Jan 2030）。于是测试了一下，发现不少程序还没有CentOS Stream 10的源，那退而求其次换成CentOS Stream 9（31 May 2027），而Redis也给干到了8.0.3。
费了些时间，终于能完全build成功了。
你以为问题到这里就解决了？没那么容易，走测试流程一走发现全是坑点：Redis跨了这么大的版本，需要额外在启动指令扩展了两句才能拉起容器服务；tar程序版本太高，对–exclude参数的顺序要求变严格了，必须前置，这就造成如果用这个镜像，代码也要跟着改。
这还不是最恶心的。PHP版本升到8.0.30之后，发现对字符编码的Bug做了修复，然后就造成以前的代码在字符编码判定的运行结果和预期不再一致。
如果没有完备自动化测试，这些问题非常难发现。测试妹子还是很给力的。呐，从最初开始解决Redis无法拉起的问题到定位编码问题根源已经测了3天了……
这不对啊，这个问题最初不就只是要求升级个Redis吗？就算CentOS 7废弃不维护了，找个替代的yum源也不是难事啊。大跨步升级镜像带来的不可预知的问题完全没必要啊，这镜像就算做完美了也不会给我和公司带来任何更多的价值。
反思到这里，我认识到了自己的愚蠢，给测试道歉，推倒之前的方案，从头再来，在原镜像的基础上，yum卸载Redis，源码编译安装所需版本的Redis。也就一个小时，问题全部解决。自动化测试用例都通过了。
哎，对于历史的包袱，通常情况下，没有足够的利益和收益，不要轻易想着大跨步向前。稳定更重要。没有完备的测试用例和自动化的情况下，不要轻易大刀阔斧，容易砍死自己……
如本文对您有用，捐赠和留言 将是对我最好的支持~（捐赠可转为站内积分）
如愿意，请向朋友推荐本站，谢谢。
尊重他人劳动成果。转载请务必附上原文链接，我将感激不尽。