容器化应用

序言

七月，炎热的季节，又到了吃葡萄的季节了。。。

转眼一瞬间，一年已经过去了七个月，懵懂中，这一年又要像风一样吹过去了。。。

报错

不知道是电脑折腾我，还是我折腾电脑，动不动就蓝屏，不就创建了一个虚拟机集群么，太不抗折腾了，感觉磁盘的寿命快到了。。。以为是虚拟化的问题，从vmware换到virtualbox，依旧未解决。。蓝蓝的天空了解一下。。。

在进行使用容器的时候，使用yum进行安装，然后rpm卸载，造成了rpmdb和yumdb不同步，使用的解决方案是yum history sync，主要就是用来同步数据库，也可以无视，反正也不影响使用，只是一个waring而已。

在使用yum的时候，越来越觉得yum whatprovides xxx好用了，假如你使用的一个命令，而恰恰忘记了这个包是什么，那么可以使用这个命令来查找到这个包，从而进行安装。

在使用容器的时候，居然命令的反映时间需要几秒钟，是可忍孰不可忍。。。

一个docker ps的命令居然需要接近4秒钟，而查看一个docker info居然需要七秒钟。。。简直是一种痛苦的体验。。。查看日志，未见明显异常，查看cpu的使用情况，发现si比较高，软中断。。。这不可能，都不可能有那么多的中断请求。。。好吧，你牛逼。。。进行cpu的亲和性绑定，分配2颗cpu，一颗给系统玩，一颗给docker用。。。

在使用docker的时候，在使用docker image的时候，查看的是本地的镜像，而只有docker search查看的docker hub的镜像，而当你搭建了自己的registry的时候，search并不会主动到本地的仓库进行查找，但是依旧可以pull。

在使用docker的时候，有几个容器混淆的命令，import，export，load，save，load和import都是可以从tar文件中进行创建镜像，区别就是import可以重新指定镜像的名称和tag，而在使用export的时候，主要是将容器变成一个tar归档文档，save则是将镜像直接保存为一个tar归档文件，而commit则是将容器提交为镜像，略微有区别。。。

为什么要容器化应用

在进行容器化的时候，听起来好像很高端，但是如何说服别人进行容器化，容器化应用是否能带来价值，那么就需要根据当前环境来进行考虑。。。

1、 硬件平台是否支持容器化

到处都在吹捧一次build，到处运行，一次ship，到处浪。。。事实上是否真是这样。。。

普通的硬件都是使用x86，而一些所谓的小机，大型机，使用的是aix，并不能支持docker的运行，那么在进行容器化的时候，这部分机器如何处理？

2、 各种语言是否支持容器化

在目前存在的系统中，有各种各样的语言写的系统，有c，c++等各种老系统而且是核心系统，而新生系统则是java，那么是否c和c++等语言能进行支持。

在进行容器化的时候，使用c和c++无非就是为了追求极致的速度，如果使用容器来进行虚拟化，是否是降低了效率，是否不应该移植？

3、 操作系统是否支持容器化

在目前的系统中，大部分是linux，小部分是aix，而还有一部分是windows，那么容器化的应用是否能很好的支持windows。。。

docker-ce社区版本，并不支持，采用ee？也就支持那么几个版本。。。

4、 基础镜像是否支持容器化

在目前的系统中，假设都是java语言，而要提供基础镜像，需要提供哪些基础镜像，是否经过了调研。。。

有的是用oracle的jdk，有的是用openjdk，而有的用的是jrockitjdk，有的用的是1.6版，有的是1.8，有的是1.9，需要多少基础镜像。。。

5、 流程是否支持容器化

在目前的开发流程中，有开发，有测试，有部署，有运维，一整套的流程。。。

而使用docker的时候，编译成war包，打成image，发布运行，镜像仓库的构建，镜像仓库的隔离，多个版本并行运行并行测试，流程上如何给与配合。。。

监控，日志，故障处理，追踪链的形成，是否有成熟的体系。。。

容器化应用，说起来简单，做起来难。。。从前到后，从上到下，好像都是问题，不过还是很有意思的。。。