您好,登录后才能下订单哦!
虚拟化和容器化是项目云化不可避免的两个问题。虚拟化由于是纯平台操作,一个运行于linux操作系统的项目几乎不需要做任何改造就可以支持虚拟化。而项目如果要支持容器化则需要做许多细致的改造工作。容器化相对于虚拟化的优势也相当明显,运行于裸机性能高,秒级启停容器,更不用说开发、测试、布署一致的环境(DevOps理念),以及上篇提到的微服务的能力。大家还可以找到各种文章来介绍容器化(Docker)的知识,这里我们就不一一赘述。下面我们会根据项目的实际情况,介绍下容器化改造会面临的问题和解决方案。
一个几十万行c++代码、大几十个应用程序的大型项目进行容器化。如何对原来的代码改造最小,甚至代码都不需要修改。如何静悄悄的,甚至不让业务程序员发觉。如何将业务镜像的体积做到最小。如何快速地制作一个业务镜像。这些一直是困扰我们多时的问题。容器分类的时候,如果需要对代码组织方式和架构进行调整,对于几十万行的项目将会是一个灾难。容化改造完后,如果开发模式变化太剧烈,无可避免会面临几十个、上百个业务程序员重新学习适应的过程,成本惊人。业务镜像的大小直接影响对现场更新容器方便与否的问题,特别是当项目在海外,网络速度不是很快的情况下。自动化、快速的镜像制作是能否进行敏捷开发的关键。
一、如何开始
如何将一个运行于linux的项目挪到容器里面去运行通常是遇到的第一个问题。网上找一个带gcc编译器和linux操作系统的基础镜像,基于这个镜像可以先制作一个编译和CI检查(代码检查、运行单元测试等等)的构建镜像。利用构建镜像进行编译和CI检查,然后基于基础镜像制作运行镜像,将编译好的库和可执行程序拷贝进去(通过Dockerfile)。这样一个最简单镜像就制作好了。
上面方法做出来的业务镜像可以运行,但有两个问题,制作的时间特别长(我们项目需要一个小时)、镜像的业务层特别大(我们项目有1个G)。两个问题不是特别严重,但如果项目拿去商用就是一个很麻烦的问题。
二、容器分层
容器分层的概念是Docker的核心概念,就是支持每个容器可以“继承”自另外一个容器。这里的继承跟面向对象里的继承应该是同一个概念。这样除了可以带来“继承”特性的好处,底层镜像变动时,不需要去更新上层的镜像,这样就可以少更新很多东西。的确很妙,面向对象的继承我都没觉得有这么好用!受这个特性影响,我们将项目用到的第三方库单独提出来做成一层。制作的流程也相应地变成下图所示。
虽然过程多了一步,但效果也是立竿见影的,业务层的制作时间从原来1个小时缩短为12分钟,大小也变为100M左右。
三、业务容器分类
在Docker最佳实践的建议里面,建议一个容器最好只跑一种程序,或者一类程序。像原来那样,一个容器跑几十个进程一定是不合适的。分类清晰的容器也便于管理和进行各种操作。同时,在微服务的最佳实践里面,建议将项目的代码分割成一个个的微服务。每个微服务的代码由不同的团队维护,各自独立。我们先暂时不讨论这种方式的优缺点。原先的项目是一个几十万行、几十个程序的大项目,有几十个人开发人员,有无数的公共模块,每个模块间相互引用也很普遍,每个程序由数量不等的模块来组成。如果按上面的建议来进行Docker的业务分类,无疑会给项目带来巨变,并且涉及组织架构的大调整,几乎是一个不可能的任务。那么如何做既可以对容器进行分类,又保持原有的开发模式不变。有时候察觉不到改变才是推进一项新技术的最佳方式。
方法其实也很简单,容器里面有一个叫docker-entrypoint.sh的角本,管理容器启动后要启动哪些进程。上面我们已经制作了一个项目统一的镜像,在分类的时候,我们只要根据不同类型容器,修改不同的docker-entrypoint.sh来启动不同类型的进程就可以了。要配合设置不同的环境变量,不同的配置文件等等。当然,这一切都很容易!
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对亿速云的支持。如果你想了解更多相关内容请查看下面相关链接
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。