选择容器的原因以及一路走来的经验教训

最新推荐文章于 2022-03-09 15:09:27 发布

Docker_

最新推荐文章于 2022-03-09 15:09:27 发布

阅读量524

点赞数

过去十多年间，我的主要工作是负责搭建、部署和运行后台系统。刚开始是搭建PHP web服务，紧接着，谢天谢地，有了Ruby on Rails。几年后，我投入到用Ember.js创建单页web应用，但不久，又做回后端及服务相关的工作。

由于之前所在公司在Docker 1.0版之后不久就全部使用Docker，所以团队和我本人经历了Docker的整个发展过程。我在那家公司做的最后一个项目是，用Kubernetes替换所有手动部署的Docker编排系统。这充满了挑战，但也学到了很多宝贵的经验。现在，我想通过我的故事跟大家分享一些关于生产环境下使用、开发和运行容器的经验。

当初选择使用容器，主要基于两点。第一是内部重组和自底向上重新设计产品；第二是Docker出了1.0版。我们决定使用Docker，不仅是因为Docker支持我们的多语言系统，同时还具备标准的操作工具。九个月后，新系统在生产环境上线。由于没有可用的编排系统，部署基础设施部分的创建工作成为了当时的难点。那期间，Docker社区主要关注的是如何改善开发流程上，还没有涉及到生产环境。虽然我们的配置存在很多问题，但我们学会了变通。头两年，这套系统一直运转良好，直到事情出现了变化。

class="video_iframe" data-vidtype="2" allowfullscreen="" frameborder="0" data-ratio="1.7647058823529411" data-w="480" data-src="http://v.qq.com/iframe/player.html?vid=k0612xbb4sg&width=651&height=366.1875&auto=0" style="display: block; width: 651px !important; height: 366.1875px !important;" width="651" height="366.1875" data-vh="366.1875" data-vw="651" src="http://v.qq.com/iframe/player.html?vid=k0612xbb4sg&width=651&height=366.1875&auto=0"/>

这个变化就是对更低价的系统的需求。然而，团队里谁也没有足够的信心去修改我们定义好的这套系统。幸运的是，这时我们有了更多的选择。生产环境下已经可以使用Kubernetes、Docker Swarm和Mesos这样的容器编排技术。我们集中主要的精力在Kubernetes上搭建了一个Helm chart build pipeline[1]。六个月之后，我们的系统在生产环境上线。系统的更新换代让我们充满了成就感，但这并不意味着零失误。

我的这个故事里都是经验教训。事实上，它包含了大量的失误、工程的妥协、成功以及彻底的失败。当然，那时的某些决策还是很明智的，这也是系统还在生产环境运行的原因。我没想说服谁，只想分享一个真实的故事，从Docker 1.0开始使用容器，一路走来的风雨历程。接下来，我将分三部分说明：使用、开发流程和生产运营。

使用

事后证明，我们当初选择Docker是正确的，但是时间点有问题。之后，选择迁移到Kubernetes时，我们又重蹈覆辙。无论是选Docker还是选Kubernetes，事先都没有对所支持的工具进行充分的调查。虽然Docker和Kubernetes都运行的很好，但是我们没有考虑到整个上流和下游的技术，它们在这个过程中的相互影响。这点，对于早期的使用者来说，必须慎之又慎。

我就是那个早期的使用者，所以有一些心得体会。在采用Rails和Ember.js时，选择Docker吧。Rails意味着用新方法开启CRUD应用程序世界；Ember.js则需用新方法实现新的单页web应用，那更麻烦。选择Docker需要一个新的策略，因为它创造了一个新的典范。

我不会再做傻事，像之前迁移到Kubernetes之类的事，下次我会提前调查清楚。在那种情形下，我认为最好的方式是等待，直到围绕核心技术开始出现相应的支持工具。想想现在有那么多现成的工具，诸如Docker Compose、Docker Machine、Kubernetes、Helm之类。如果你是一个早期的使用者，那你需要自己创建和测试这些工具。扪心自问：你是否真的愿意付出那些额外的努力？还有，真的有这个必要吗？

开发流程

容器的使用改变了我的开发流程。对此，起初难免有些惊讶，事后想想也能理解。自从所有的开发工作都放进了容器里，我的心理也发生了转变。这也是必须的，因为不同的服务使用不同的语言和工具。

集成开发流程[2]极大推动了整个开发流程的改进。我可以在任何一个项目/框架/语言下，进行TDD和影响重大的冒烟测试，也可以对项目进行一连串全新的测试。现在我可以在一个容器里启动一个服务器端，在另一个容器里启动一个测试用客户端。当我的注意力从测试代码转移到测试流程，生产环境的回归测试也大量减少。

之所以发生这一转变，是因为在过去的一年里，我一直在使用容器，并将它应用到越来越多的领域。如果一个团队只是在工作流的最后创建了镜像，决不会发生这种转变。所以，如果你刚开始接触容器，最好全心投入，努力创建一个完全容器化的工作流。你可以问一下自己：怎样才能把一个东西容器化？这个问题可以帮你梳理出相应的软件和工作流程。总之记住，一定要容器化！容器化！容器化！重要的事情说三遍~

生产运营

根据我的经验，容器已经实现了它的核心价值。与以往相比，容器让无数不同的应用、语言和框架以极其简单的方式，毫不费力地部署到生产环境。它是如此成功，我都无法想象如果没有容器，生产环境该如何运转。Kubetnetes将成为分布式应用的标准平台。现如今，3家大的云供应商提供了各具特色的编排工具。大家的注意力开始从解决预生产环境的工作流程问题，转移到解决生产环境问题，这点令人欣慰。事情正在一天天变好。

同时，这也说明，生产环境上使用这些工具运行容器，还处于起步阶段——还得几年吧。比较一下容器和JVM，你会明白我在说什么。我的建议是先假设这些技术可以为你所用，然后找原型和小规模项目，对假设进行验证。不论你喜欢与否，生产环境上用编排技术运行容器，需要理解和适应分布式系统。在开始前，确保你已经做好准备接受转变。

展望

选择使用容器，绝对是我职业生涯中最重要的决定。我很开心因为我学到了一种非常有用的新技术，与此同时，也为研究、选择和实施下一个的新兴技术做好了充分的准备。在面对下个新技术的时候，我一定会保守行事。不是因为技术，而是我猜我还有别的工作要做。如果你有大把大把的时间玩新技术，感觉还是蛮不错的，但如果有人拿枪指着你，感觉就大打折扣了。

我看到了地平线上的曙光。部署和管道管理工具，诸如Helm和Spinnaker是下一波浪潮。我希望在我跳进去之前，它们已经被摆平了。我不再着急，随着时间的流逝，这些新技术和我，都会迎来自己的时刻，我们都将变得更好。我相信随着它们日趋成熟，新一代的团队在经历持续部署和多语言环境时会更加轻松自如。这势必会推动更多的团队朝着DevOps方向发展，从而形成一股DevOps价值流，这才是它真正的价值所在。它们带给我的，同样也能带给你启发和帮助。祝好运！