2019年10月17日容器化技术选型问答
问：我们那套系统要不要上 Docker？听说上了之后部署方便。
答：先别急着定。我问三个数，答完再聊。
问：哪三个？
答：一，现在部署一次，从打包到页面能打开，多久？二，一年发几次版？三，部署失败的时候，半夜谁爬起来处理？
客户那边算了算：20 分钟，一年 6 次，一个运维，偶尔是他自己。
那次的结论是没上
不是 Docker 不好。是那三个数摆出来，痛点不在部署。20 分钟乘以 6 次，一年也就两小时。真要省，先把那 20 分钟里最容易出错的两步挪走更划算：一是有人手工改配置文件，二是回滚靠翻上次的备份目录。
我们做了两件小事。部署脚本收进 Git，服务器上的那份只读，跟之前 crontab 一个道理；再补一个 rollback 脚本，传版本号就能退回上一版，Nginx 权重都不用手动调。加起来一天半。
问：那什么时候该上？
答：几个信号。部署频率从一年 6 次变成一周两次；同一套代码要跑在三台以上机器，且配置各不相同；有人开始为「我本地是好的」这句话吵架；或者要同时跑两个版本的 PHP。出现两个以上，容器化省下来的就不只是部署时间了，是环境一致这件事。
问：是不是越早越好，免得以后迁不动？
答：反过来。系统还在改结构的时候上，等于一边换地基一边装修。我们见过一个项目，容器是上了，但数据库还在容器里、上传目录挂在本地盘，发一次版要手动倒数据，比没上之前还绕。
问：半年后呢？
答：半年后客户自己又提了一次。那会儿他们加了两台机器，招了第二个运维，发版改成两周一次。三个数全变了，我们就一起做了，先只迁无状态的那层，数据库留在外面。这回没人犹豫。
一句实在话
技术选型聊不拢，多半不是谁不懂，是没先把「现在到底哪儿疼」说清楚。那次聊了 40 分钟，有 30 分钟在数那三个数。
