先弄明白这几个关键点，再说容器化到底值不值得搞清楚

（来源：知乎专栏《技术人的思考》）

先弄明白这几个关键点,再说容器化到底值不值得搞清楚，现在到处都在说容器化、Docker、Kubernetes，好像不懂这些就落伍了，但你真的需要花时间去学吗？别急着跟风，先问问自己下面这几个问题，答案可能就清晰了。

第一个关键点,你的工作是不是经常被“环境问题”困扰？（来源：某位资深运维工程师的分享）这是什么意思呢？你在你自己的电脑上开发一个程序，跑得好好的，一点问题都没有，但是当你把这个程序交给测试的同事，测试同事却说跑不起来，不是缺了这个库，就是少了那个配置文件，然后你们俩就得花半天甚至一天的时间，在那里一点点对比环境，找原因，好不容易测试那边能跑了，部署到服务器上，运维的同事又说环境不对，又出问题了，这种“在我这儿是好的，在你那儿就不行”的情况，就是典型的环境不一致问题，如果你和你的团队经常被这种事情搞得焦头烂额，那容器化就非常值得你搞清楚，因为容器化的一个核心思想就是“一次构建，处处运行”，它把你的应用程序和它运行所需要的所有东西，比如代码、运行时环境、系统工具、系统库、设置等等，统统打包成一个独立的、轻量级的“容器镜像”，这个镜像在任何安装了容器引擎（比如Docker）的机器上，运行起来的表现都是一模一样的，这样一来，就从根儿上解决了环境不一致的噩梦，如果你几乎没有这种烦恼，那容器化对你的紧迫性可能就没那么强。

第二个关键点,你需要快速扩展或缩小你的应用规模吗？（来源：一篇关于微服务架构的博客）举个例子，你做了一个电商网站，平时访问量很平稳，服务器资源刚好够用，但到了“双十一”或者做大型促销活动的时候，访问量会瞬间暴增好几倍甚至几十倍，按照传统做法，你可能得提前好久去申请新的物理服务器，然后一台台地安装系统、配置环境、部署应用，等这些都搞完，促销活动可能都结束了，或者，你买了很多服务器来应对高峰，但平时大部分时间这些服务器都闲着，造成巨大的浪费，容器化，特别是和像Kubernetes这样的容器编排工具结合，就能很好地解决这个问题，它可以让你的应用实现快速的弹性伸缩，当流量来了，系统可以自动地、在几分钟甚至几秒钟内，启动很多个新的容器实例来分担压力；当流量过去，又可以自动关闭多余的实例，把资源释放出来，这种按需使用资源的能力，对于业务流量波动大的公司来说，能节省大量成本并保证系统稳定，如果你的应用用户量很稳定，没有这种高峰低谷的波动，那这个优势对你的吸引力可能就小一些。

第三个关键点,你们团队的开发和发布流程效率高吗？（来源：一本关于DevOps的书籍）很多公司的流程是这样的：开发人员花几周时间写完代码，然后打包扔给测试团队，测试团队测出问题再打回给开发修改，来回折腾，最后再由运维团队手动部署上线，这个过程可能长达数周，而且容易出错，容器化是推动DevOps文化落地的一个关键技术，它通过容器镜像，为开发、测试、生产环境提供了一个绝对一致的交付物，这意味着，整个团队可以从始至终都围绕着同一个容器镜像来工作，开发人员构建出镜像，测试人员直接拉取这个镜像进行测试，运维人员最终部署的也是同一个镜像，这极大地简化了流程，减少了人为错误，为实现持续集成和持续部署（CI/CD）打下了坚实基础，如果你的团队规模很小，发布不频繁，或者现有的流程已经很顺畅，那么容器化在提升流程效率方面的收益可能不那么明显，但如果你渴望实现更敏捷、更频繁、更可靠的软件交付，那这就是一个非常重要的价值点。

第四个关键点,你关心技术的未来趋势和个人成长吗？（来源：多位技术面试官的观察）这不是一个直接的技术问题，但却很现实，容器化技术已经成为云计算时代的基石之一，是很多现代应用架构（比如微服务）的默认选择，越来越多的公司，无论是互联网大厂还是正在转型的传统企业，都在采用容器技术，这意味着，掌握容器化相关知识，正在从一个“加分项”变成很多技术岗位的“必备技能”，了解容器化，不仅能让你更好地理解现代软件是如何被构建和运行的，也能为你的职业发展打开更多的门，即使你当前的工作可能用不到，但作为一种前瞻性的知识储备和投资，搞清楚它也能让你在技术视野上不落伍。

容器化到底值不值得搞清楚？没有标准答案，它取决于你的具体工作痛点、你的业务需求、你的团队协作模式以及你对个人发展的规划，如果你在上面几个关键点中找到了强烈的共鸣，那么投入时间去学习容器化，将会是一笔非常划算的投资，如果你的情况恰好相反，那或许你可以把精力优先放在其他更紧迫的技能上，别盲目，想清楚再行动。