docker技术沙龙学习

简介：

简单的说Docker是一个构建在LXC之上的,基于进程容器(Processcontainer)的轻量级VM解决方案，Docker的初衷也就是将各种应用程序和他们所依赖的运行环境打包成标准的container/image,进而发布到不同的平台上运行。从理论上来讲，

各种虚拟机Image也起着类似的作用。但是

Docker container和普通的虚拟机Image相比, 最大的区别是它并不包含操作系统内核。所以更加的轻量化。普通虚拟机将整个操作系统运行在虚拟的硬件平台上, 进而提供完整的运行环境供应用程序运行, 而Docker则直接在宿主平台上加载运行应用程序.。相对于VM，docker在其轻量、配置复杂度以及资源利用率方面有着明显的优势。

应用场景：

1.应用打包

制作过RPM、GEM等软件包的同学可能很清楚，每一个软件包依赖于哪个库的哪个版本， 往往需要明确的写在依赖列表里。而依赖又往往分为编译时依赖和运行时依赖。

在传统的基础设施环境下，为了保证所生成的软件包在其它机器上可正常安装且运行， 一般需要在打包之前创建个干净的虚拟机，或者手工创建个chroot环境， 然后在这个干净的环境下安全各种依赖包，然后执行打包脚本。 生成软件包以后，需要再创建一个干净的环境安装、运行这个软件包，来验证是否符合预期。 这样虽然也能完成打包工作，但至少有以下缺点：

1. 耗时耗力
2. 依赖关系容易漏掉，比如：在干净的环境中经过多次调试，把缺少的依赖包一个一个的装上了，  但最后写spec文件时却忘记添加某个依赖，导致下次打包时需要重新调试或者打包后软件包无法使用等问题。

通过docker可以很好的解决打包问题。具体作法如下：

1. “干净的打包环境”很容易准备，docker官方提供的ubuntu、centos等系统镜像天生就能作为纯净无污染的打包环境使用
2. Dockerfile本身能起到文档固化的作用，只要写好Dockerfile，创建好打包镜像，以后就能无限次重复使用这个镜像进行打包
3. 
   

2.多租户资源隔离

资源隔离对于提供共享hosting服务的公司是个强需求。 如果使用VM，虽然隔离性非常彻底，但部署密度相对较低，会造成成本增加。

docker容器充分利用linux内核的namespaces提供资源隔离功能。 

结合cgroup，可以方便的设置某个容器的资源配额。 既能满足资源隔离的需求，又能方便的为不同级别的用户设置不同级别的配额限制。

但在这种应用场景下，由于容器中运行的程序对于hosting服务提供方来说是不可信的， 所以需要特殊的手段来保证用户无法从容器中操作到宿主机的资源（即：越狱，尽管这种问题发生的概率很小，但安全无小事，多一层防护肯定让人更加放心）。

3.内部开发环境

在容器技术出现之前，公司往往是通过为每个开发人员提供一台或者多台虚拟机来充当开发测试环境。

开发测试环境一般负载较低，大量的系统资源都被浪费在虚拟机本身的进程上了。

docker容器没有任何CPU和内存上的额外开销，很适合用来提供公司内部的开发测试环境。 

而且由于docker镜像可以很方便的在公司内部分享，这对开发环境的规范性也有极大的帮助。

如果要把容器作为开发机使用，需要解决的是远程登录容器和容器内进程管理问题。 虽然docker的初衷是为“微服务”架构设计的，但根据我们的实际使用经验， 在docker内运行多个程序，甚至sshd或者upstart也是可行的。

4.隔离应用

隔离应用依赖创建应用镜像并进行复制创建容易分发的即启即用的应用允许实例简单、快速地扩展测试应用并随后销毁它们 
有很多种原因会让你选择在一个机器上运行不同的应用，比如之前提到的提高开发效率的场景等。
我们经常需要考虑两点，一是因为要降低成本而进行服务器整合，二是将一个整体式的应用拆分成松耦合的单个服务（译者注：微服务架构）。

5.提高开发效率

这就带来了一些额外的好处：Docker能提升开发者的开发效率。如果你想看一个详细一点的例子，可以参考Aater在 DevOpsDays Austin 2014 大会或者是DockerCon上的演讲。

不同的开发环境中，我们都想把两件事做好。一是我们想让开发环境尽量贴近生产环境，二是我们想快速搭建开发环境。

理想状态中，要达到第一个目标，我们需要将每一个服务都跑在独立的虚拟机中以便监控生产环境中服务的运行状态。然而，我们却不想每次都需要网络连接，每次重新编译的时候远程连接上去特别麻烦。这就是Docker做的特别好的地方，开发环境的机器通常内存比较小，之前使用虚拟的时候，我们经常需要为开发环境的机器加内存，而现在Docker可以轻易的让几十个服务在Docker中跑起来


6.解决资源竞争

多个构建任务同时进行，竞争中控机的资源，影响发布速度。有一次一个应用受到同时进行的某Java类应用发布的影响，通常两分钟的发布变成了十多分钟，严重影响发布体验。如果出现事故需要回滚，就是更严重的问题了。


7.解决环境冲突

不同应用的构建依赖环境在一台发布机上，需要考虑环境冲突和隔离的问题。例如，Java 1.6/1.7共存，应用需要通过JAVA_HOME变量指定使用的Java版本，Maven 2/3也存在同样的问题。npm的global包也需要兼容多个应用的构建。


8.解决安全隐患

应用的构建脚本运行在公共发布机上，脚本的Bug可能会影响到发布机的正常运行。例如某次一个构建脚本里面的sudo service nginx reload命令，本应是在应用服务器上执行的，但开发人员错误配置到了在发布机上执行的构建脚本里面。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29754888/viewspace-1586057/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29754888/viewspace-1586057/