大咖分享 —— 选择容器的原因以及一路走来的经验教训


【编者的话】本文来自Saltside的技术专家Adam Hawkins,主要分享了他本人自Docker 1.0开始,使用容器和改进开发流程等的个人经历。时至今日,围绕Docker出现了众多编排利器。作者以一个过来人的身份,提醒大家在新技术层出不穷的今天,我们需要注意哪些问题,如何权衡得失利弊。

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

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

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

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

我的这个故事里都是经验教训。事实上,它包含了大量的失误、工程的妥协、成功以及彻底的失败。当然,那时的某些决策还是很明智的,这也是系统还在生产环境运行的原因。我没想说服谁,只想分享一个真实的故事,从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之类。如果你是一个早期的使用者,那你需要自己创建和测试这些工具。扪心自问:你是否真的愿意付出那些额外的努力?还有,真的有这个必要吗?

开发流程

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

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

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

生产运营

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

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

展望

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

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

原文链接:Why I Went All-in with Containers…and the Fails Along the Way (翻译:Tiny Guo)

0 个评论

要回复文章请先登录注册