Docker大型项目容器化革新

虚拟化和容器化是项目云化不可以免的两个题目。虚拟化因为是纯平台操纵，一个运转于linux操纵系统的项目险些不需要做任何革新就可以支撑虚拟化。而项目要是要支撑容器化则需要做很多详细的革新工作。容器化相关于虚拟化的优势也相当显明，运转于裸机机能高，秒级启停容器，更不用说开发、测试、布署一致的环境(DevOps理念)，以及上篇提到的微服务的能力。大家还可以找到各种文章来介绍容器化（Docker）的知识，这里我们就不一一赘述。下面我们会依据项目的现实状况，介绍下容器化革新会面对的题目和解决方案。

一个几十万行c++代码、大几十个利用程序的大型项目进行容器化。怎样对本来的代码革新最小，甚至代码都不需要修改。怎样静悄悄的，甚至不让业务程序员觉察。怎样将业务镜像的体积做到最小。怎样迅速地制作一个业务镜像。这些不断是困扰我们多时的题目。容器分类的时候，要是需要对代码组织方式和架构进行调整，关于几十万行的项目将会是一个苦难。容化革新完后，要是开发模式变化太剧烈，无可以免会面对几十个、上百个业务程序员从新学习顺应的历程，老本惊人。业务镜像的大小直接影响对现场更新容器利便与否的题目，特殊是当项目在海外，网络速度不是很快的状况下。主动化、迅速的镜像制作是能否进行灵敏开发的要害。

一、怎样开端

怎样将一个运转于linux的项目挪到容器里面去运转平常是碰到的第一个题目。网上找一个带gcc编译器和linux操纵系统的根基镜像，基于这个镜像可以先制作一个编译和CI检查（代码检查、运转单元测试等等）的构建镜像。应用构建镜像进行编译和CI检查，然后基于根基镜像制作运转镜像，将编译好的库和可施行程序拷贝进去（通过Dockerfile）。这样一个最简略镜像就制作好了。

上面要领做出来的业务镜像可以运转，但有两个题目，制作的工夫特殊长（我们项目需要一个小时）、镜像的业务层特殊大（我们项目有1个G）。两个题目不是特殊重大，但要是项目拿去商用就是一个很费事的题目。

二、容器分层

容器分层的概念是Docker的中心概念，就是支撑每个容器可以“继承”自另外一个容器。这里的继承跟面向对象里的继承应当是统一个概念。这样除了可以带来“继承”特性的益处，底层镜像变动时，不需要去更新上层的镜像，这样就可以少更新许多东西。确实很妙，面向对象的继承我都没觉得有这么好用！挨这个特性影响，我们将项目用到的第三方库独自提出来做成一层。制作的流程也响应地变成下图所示。

虽然历程多了一步，但结果也是立竿见影的，业务层的制作工夫从本来1个小时缩短为12分钟，大小也变为100M左右。

三、业务容器分类

在Docker最好实践的倡议里面，倡议一个容器最佳只跑一种程序，或者一类程序。像本来那样，一个容器跑几十个进程一定是不合适的。分类清晰的容器也便于治理和进行各种操纵。同时，在微服务的最好实践里面，倡议将项目的代码分割成一个个的微服务。每个微服务的代码由不一样的团队保护，各自独立。我们先暂时不计议这种方式的优缺陷。原先的项目是一个几十万行、几十个程序的大项目，有几十个人开发人员，有无数的公共模块，每个模块间彼此援用也很普遍，每个程序由数目不等的模块来组成。要是按上面的倡议来进行Docker的业务分类，无疑会给项目带来巨变，并且波及组织架构的大调整，险些是一个不可能的任务。那么怎样做既可以对容器进行分类，又维持原有的开发模式不变。有时候察觉不到转变才是推动一项新技术的最好方式。

要领其实也很简略，容器里面有一个叫docker-entrypoint.sh的角本，治理容器启动后要启动哪些进程。上面我们已经制作了一个项目同一的镜像，在分类的时候，我们只有依据不一样类型容器，修改不一样的docker-entrypoint.sh来启动不一样类型的进程就可以了。要配合设置不一样的环境变量，不一样的配置文件等等。当然，这一切都很容易！

总结

以上就是这篇文章的全部内容了，但愿本文的内容对大家的学习或者工作拥有一定的参考学习价值，感谢大家对脚本之家的支撑。要是你想理解更多相干内容请查看下面相干链接