干货分享 | 容器是 DevOps 的必由之路——标准化带来的 DevOps（下）

Posted 2022-11-29 sisiy2015

话接上回，上篇中技术总监大大讲到了 DevOps 的前世今生以及在企业中无法很好落地的原因，今天给大家分享的是容器在开发领域是怎样的流程以及容器为什么是 DevOps 的必由之路。废话不多说～

容器是 DevOps 的必由之路

——标准化带来的 DevOps

分享人：张春源

那么容器在开发领域是怎么样的流程呢。如果是银行的朋友就会知道服务目录，我们称作应用商店，开发可以从应用商店中选择所需的环境。通过编排做交付，容器编排功能决定是不是可以把非常复杂的系统编排起来，实现整体交付。前不久我们给客户做 POC 的时候，客户给了一个微服务，24 个服务整个编排仅用了 2 个小时左右，而且无需对镜像做修改，就实现了一键部署。环境部署完后，开发就可以专心写代码了，代码提交到代码仓库，触发 Jenkins 构建，构建完成后自动部署应用。对于测试来说也特别简单，可以基于版本库进行一键部署，应用模板加镜像包括了代码、运行环境、和配置信息，测试环境同样是整体交付。大家从 PPT 上可以看到基于容器建设的整个 DevOps 的流程，包括从提交代码到 Jenkins 构建镜像，再到应用部署。有容器可以不安装 Jenkins Salve 节点，只要这台机器装了 Docker 就可以作为构建机器。实践推荐可以专门找两台主机做构建，构建完后上传到镜像仓库，构建任务多的话，多配置几台服务器就行。多环境之间交付，如：测试环境、生产环境、UAT 环境，每个环境之间会有不同，不同是指配置参数的值不同，而底层环境和代码版本要一致，保证多环境之间的一致性，这也是容器的价值。

为什么说其他技术路线为什么会必然失败。刚才我提到了，之前的标准都是小标准，个别企业的标准不一定代表着行业的标准，PPT 中的这张图是一个快递的箱子，收快递的人很难判断我是应该骑个车还是开个货车去呢？很难统一做考量。另外，小标准的生命力非常弱，难推广。现在通过容器，就像集装箱，我们都知道原先的码头有好多人力在去背麻袋，在装货、卸货，但是发现这种效率是极低的，而且出问题也比较多。集装箱出现后整个运输行业做到了标准化、自动化。

DevOps 有一个很强的需求：更小、更频繁的变更。没有容器的话，应用变更很难，如：

• 构建环境不确定，比如我这一次的构建也许会用了上一次构建失败的库，所以导致这一次构建也失败；

• DSL 语言编写起来特别麻烦，在 2015 年的时候遇到一个银行的客户，问我 Puppet 如果升级的话有没有什么风险，市面上是否有 Puppet 的大牛能做技术顾问；

• 发布结果不一致，在不同的时间点，因为网络的因素或者其他因素，要么是全部失败，要么是全部成功；

• 回滚周期长。

有容器的话：

• 构建环境首先是确定的，因为容器是一个集装箱，把所有东西都包起来了；

• 可视化操作，门槛特别低；

• 发布结果一致，就好比把上海的集装箱拉到北京，只要箱子在，里面的东西就自然会在；

• 周期短、秒级回滚。

DevOps 的又一个需求：让开发人员尽可能的去控制生产环境。当然这个控制是有限度的控制，包括可视化的操作，要有操作审计功能等，任何一个人做了什么操作，实现的结果，都会有记录，最后是可视化的查询。没有容器怎么来控制，控制力度难控制，命令行操作，依赖外部系统，管理系统分散，有些其他的运维平台是只监不控，对企业来说，其实维护这么多系统也非常麻烦，同样希望能一套系统既可以监控又可以管理。使用容器的优点，细力度的授权，可以开放给开发，全都是可视化的操作，简化了开发使用的门槛。精密审计，记录了增删改等操作。高度集成，一套平台可以做到监控和管控。

以应用程序为中心，来理解基础设施。代码会依赖配置文件、依赖操作系统、依赖其他的外部系统等。依赖程序非常难管，开发人员手动修改，但是没有及时记录到文档或者是其他系统中；配置管理与代码是分离的，尤其是配置文件；依赖的修改会比较复杂，速度比较慢即使是虚拟机或 Puppet。基础设施管理复杂度比较高，经常的变更会导致系统已经不一样了，还要同时管理不同版本的操作系统。容器作为应用的基础设施，首先有一个概念“镜像”，镜像包含了应用代码以及依赖的运行环境，可通过 Dockerfile 文件进行描述，同代码一起管理。变更更快速，pull 镜像 start 容器，主机上只要运行一个容器引擎就可以了，基本上不用做变更，而且对操作系统是弱依赖的。

定义简单明了的流程。以前的方案流程复杂，不同类型应用的程序、不同项目组的项目，都会有不同的部署、升级回滚流程，这个复杂度是比较高的。开发人员对代码、架构的调整，都会导致运维人员做出很多相应配置变更的工作。这是一个博弈的过程，开发要求变化，运维追求的是稳定。

接下来分享一个基于容器实践 DevOps 的案例。总目标有 2 个，第一个如何用容器克服第三方开发商和企业 IT 管理之间的协作，系统开发涉及到开发厂商，包括北京的研发和广州的研发，不改变已有开发习惯，代码写完后提交到 GitLab 就可以。Jenkins 构建出来的镜像都 push 到中央镜像仓库，基于 cSphere平台的应用编排，将业务编排起来，实现业务的部署、升级及版本回退。基于容器建设整个 DevOps 流水线，我们已经在不同行业，不同客户的 IT 环境中实践过了，这几年以来，为什么在企业中基于容器实践 DevOps 能成功，很重要的一点就是容器是行业标准，并且结合希云 cSphere 容器平台降低了使用门槛，和推广难度。

最后我们看一下客户效果收益，标准化第三方开发商交付物，所有的人员都必须通过镜像来作为交付物，对于中英运营人员标准统一进行部署和管理。2 个月完成 2 个应用的开发、测试、上线。服务器资源提升 70%、交付时间缩短60% 以上，整体工作效率提升 80%，包括第三方开发厂商还有甲方。

我今天分享的主题是容器是 DevOps 的必由之路，根据近几年项目实践，我相信，未来容器是 DevOps 的必由之路。今天时间有限，就不与大家一一交流了，如有其它问题可以随时与我联系，谢谢大家。