谁是容器中的“战斗机”？Docker与Chef、LXC等容器对比

问题导读
1、你是如何学习Docker的？
2、为什么要用 Docker 来替代 LXC/Ansible ?
2、你如何理解docker和Vagrant技术结合带来的优势？





Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。Docker可以自动化打包和部署任何应用、创建一个轻量级私有PaaS云、搭建开发测试环境、部署可扩展的Web应用等。
在本文中，我们对比了Docker与目前流行的几个容器如Chef、LXC、Vagrant、Ansible的各方面性能，我们一起来看看到底谁才是容器中的“战斗机”。

Docker VS Chef




从来没有人说：“我喜欢通过手动开启服务来浪费时间”。长期以来，系统管理员和开发人员在等待新服务被创建时只能无聊地摆弄指头来打发时间，这体验非常糟糕却也让人无奈。尽管虚拟化和云计算以及大规模运算已经取得快速发展，但新服务的创建效率却未与时俱进。

使用 Docker和 Chef吧。这些轻量级的工具非常易于使用，而且能给你的多服务器环境带来结构性改善。不过 Docker 和 Chef 的实现方法大不相同。接下来会一一介绍。

它们是什么

Docker 发端于一个名为 dotcloud 的开源项目；随着编写者不断挖掘它的潜力，它迅速变成了一个炙手可热的项目。它由 GO 语言编写的，并且只支持 Linux。它基于 Linux 容器（LxC）来创建一个虚拟环境。请注意：虚拟环境 VE ( Virtual Environment ) 和 虚拟机（ VM ）很不一样。虚拟机是由虚拟工具或者模拟器（ HyperV 、 VMWare 等）创建的，是一个全镜像的主机源，其中包括操作系统、硬盘调整、网络和虚拟进程。过于臃肿的结构吃掉了大量的硬盘空间同时拖慢了运行和开机速度。

译者注： LXC是一个 Linux 提供的收容功能接口，通过 LXC 提供的 API 和简单的工具，使得 Linux 用户可以简单的创建和管理系统或者应用的空间。
Docker 通过自己与操作系统内核相分离的特点很好的解决了这个问题。它会首先创建一个与机器内核相分离的 “等级0” 包裹。任何之后的改变都被保存为 namespace 的快照，并且像虚拟系统那样在单独的容器内运行。“快照”只捕捉“基本模版”的改动，而不是整个机器上面的设置（不像是VM的快照功能）。从这一点我们可以看出 namespace 能够储存并在部署了 Docker 的主机中创建完整环境。

Chef 是一个 CM 工具。它和 Puppet并列为 CM 工具系列中最常用组件。它最初在2009年发布，能够非常简便地对改变进行回滚、配置新机器，因此管理员和开发者使用它来管理机器环境。 Chef 完全支持 Windows 和 Linux 以及 Unix， 并且也有值得夸奖的 GUI （虽然不像 Puppet 的那么平滑）。不过也有人抱怨说 Chef 对于新手来说并不好理解，同时文档让使用者、特别是新手非常头疼。

译者注：前文指的 CM 指的是Configuration management，本意指是一个建立和保持生产连续性的生产模型；笔者认为此处是指 Comparison of open-source configuration management software---一系列开源的 Congratulation management 组件。

它们是如何工作的
DOCKER

Docker 不会通过建立独有的操作系统、进程和对硬件进行模拟来创建属于自己的虚拟机。一台 VE 就像是轻量级的 VM ；它在已有的内核关于底层硬件的镜像上建立一个可以用来运行应用的‘容器’。它也可以用来创建操作系统，因为所谓的操作系统也不过是一个跑在内核上的应用而已。可以把 Docker 想象成 LxC 的一个强化版，只是了以下 LxC 所不具有的特性：

强大的可移植性：你可以使用 Docker 创造一个绑定了你所有你所需要的应用的对象。这个对象可以被转移并被安装在任何一个安装了 Docker 的 Linux 主机上。

版本控制： Docker 自带 git 功能，能够跟踪一个容器的成功版本并记录下来，并且可以对不同的版本进行检测，提交新版本，回滚到任意的一个版本等功能等等。

组件的可重用性： Docker 允许创建或是套用一个已经存在的包。举个例子，如果你有许多台机器都需要安装 Apache 和 MySQL 数据库，你可以创建一个包含了这两个组件的‘基础镜像’。然后在创建新机器的时候使用这个镜像进行安装就行了。

可分享的类库：已经有上千个可用的容器被上传并被分享到一个共有仓库中（ http://index.docker.io/） 。考虑到 AWS 对于不同环境下的调试和发布，这一做法是十分聪明的。

如果希望更加详细地了解 Docker 的功能，请点击这里。

CHEF

Chef 是使用“主机-代理”结构，通过中心的主机服务器对于其他的数台安装在其他服务器节点上的代理进行协调和发送指令。这个代理（ agent ）可以通过使用轻量级工具和 SSH 在服务器端进行简易的部署。通过使用基于 Ruby 的 DSL ，所有的管理可通过 GUI 或 CLI 实现。这个 GUI 非常有用，但是当你遇到很复杂的任务的时不可避免的需要学习 Ruby 。Chef 和其它的 CM 工具一样，使用 结构-等于-代码 的模式进行工作。这也就意味着所以的基础节点的管理必须通过 Ruby 代码来实现。首先定义你需要的修改，之后选定将这些修改应用在哪些机器上，剩下的事情交给 Chef 的服务器做就好了。举个例子，如果你需要将所有 Windows 2008 服务器中的 .Net 2.0 升级到 .Net 3.0 ，你就可以把这个修改定义到你的 Chef 服务器上，之后 Chef 服务器将会进行回滚。有一点需要注意： Chef 对于主机到代理的推送的实现还是属于比较初级的阶段，因此建议你周期性的进行检查看看主机节点是否在代理节点上实施了更改。毫无疑问，这个缺点一直困扰着 Chef 开发者，并且悬而未决。

Chef 的配置被打包在 JSON 文件中并被称作“ cookbook ”。这个软件运行在“客户端-服务器”模式时叫做 Chef-server ，而当它运行在单一模式的时候被称作“ Chef-solo ”。 Chef 的部分吸引力来自于大量的 cookbook 已经被创建并且被免费分享在网络上。

结论

那么 Docker 和 Chef 到底哪个更好呢？面对这种复杂的选项，答案是“看情况”——根据你所想要得到的效果和对工具的信任程度进行选择。当 Chef 这个项目经历了长期测试和考验的时候， Docker 只是一个新兴项目，并且创始人还在犹豫是将其应用于生产环境中的时候。但是 Docker 和 Chef 可以相互补充，Docker 的优势在于快速配置新服务器，而 Chef 则能恢复一些机器上已经存在的改变，后者是 Docker 无法做到的。另外，Docker 是创造新的只读服务器实例时的完美选择，这其中包括创建一个全新的服务器的。






Docker vs LXC
我关注 docker 有一段时间了，最近开始讨论在公司使用，因为小伙伴们想使用 LXC ，也就是 docker 背后的那个技术。 以下是我研究 docker 和 LXC 后总结的一些区别。

标准的配置方法
每个 LXC "容器" 之间或许不兼容，但是 docker 采用了一种标准的配置方法使得由不同 docker 创建出的 LXC 能够完全兼容。

基于应用
LXC 的定位是作为一种虚拟机的替代方案。虽然所有的软件都可以安装在由 LXC 或者 docker 管理的容器中，但是 docker 更倾向于在一个容器中运行一个应用。

自动构建
Docker 的容器是根据 dockerfile 构建的，你可以在构建 image 的过程根据需要中运行任何命令和程序。

这意味着你不用调整现有的 image 构建方式，如果你使用 puppet，你可以在生成容器的时候执行 puppet 命令。

版本控制
Docker 实现了类似 git 的容器版本管理方法，并且能够进行增量更新。

组件复用
可以创建 base image 并将其保存在远程仓库 (repository) 中以便复用，其他容器可以在其基础上进行修改并保存为新的 image。

远程仓库
Docker 管理着一个公开的 image 库方便用户分享 image，同时公司也可以构造自己私有的 image 库。

生态系统
因为 docker 越来越流行，有大量的方法能够将其轻易地集成到开发过程中，比如可以采用统一的方法来构造用于持续集成的环境和开发环境的容器。

目前有不少反对者声称 docker 还是一个非常年轻的项目，并不能用于生产环境。但 docker 只是将一些已有的技术进行封装和组合并增加其业务逻辑，来避免大家直接使用 LXC 需要面对的一些麻烦。我相信如果直接使用 LXC ，会最终做出和 docker 功能类似的工具，然而不会得到已经转向 docker 的开发者社区的青睐。





Docker vs Vagrant


在阅读过现有的一些关于“Docker vs Vagrant”的博客（比如这篇和这篇）后，我决定写一篇文章来阐明这两种技术并非彼此竞争而是相互补充。

首先我会参照这两项技术在各自主页上的介绍，进行简单的总结。然后，我会简略地介绍如何将这两种技术同时应用到生产环境中。

Vagrant

Vagrant 基于行业技术标准提供了易于配置、可量产、并且可移植的工作环境，并且由一个统一的工作流程进行控制，从而使你和团队的工作效率和灵活性得以最大化。
为了实现这些特性， Vagrant 站在巨人的肩膀上，诸如 VirtualBox 、 VMware 、 AWS 等顶级供应商以及其他供应商。同时业界标准的供应工具，诸如 shell scripts 、 Chef 或者 Puppet 也都能在机器上自动安装和配置软件。
简言之， vagrant 能够将一个文件（ vagrantfile ）安装进操作系统中（任意操作系统，一般来说是用来运行服务和云终端的系统），同时也能将最终应用中运行程序和处理进程所需要用到的库和软件一起装上。换句话来说， vagrant 能够安装操作系统和 Docker 应用，然后 Docker 容器就可以在你电脑和服务器上运行。

所有的这些特性允许你创造相近的环境（不是完全相同而是指他们相互之间十分接近）用来测试你的应用。

因此，可以这样认为：

Vagrant 技术能够让你以一种方便简单的方式安装开发应用所需的一切。

Docker

Docker 是一个能让你在任何应用中都能轻松创建轻量级、可移植、自足容器的开源项目。一个在笔记本上编译和调试的容易能够大规模应用在虚拟机、 bare metal 、 OpenStack 集群、公有云等不同的生产环境中。

译者注：译者认为此处的bare metal又称为bare machine ， 是指没有安装任何操作系统的计算机。
简单来说，Docker 技术允许你在容器中运行你的应用（这有点类似于虚拟机，但是事实上还是有很大的区别），从而确保该应用所需要的所有库和包能够在任何情况下都有效运行，而不管你将他们跑在什么样的机器上。这就意味着你给 Memcache 和 Redis 分别定制的容器，在任何一个 Linux 的发行版上（包括你电脑和服务器上那些安装了 Vagrant 的系统），它们都会有相同的运行效果。

译者注：这里的 Memcache是指一种分布式缓存系统；而 Redis是指键值型数据存储数据库，一般也可指数据服务器。这两项技术的共同点都是使用键值存储的方式存储数据。

总结：Docker 技术可以允许你通过将应用程序运行在一个容器中的方式来消除对于各种依赖和库的担忧。

如何将这两种技术同时应用到你的生产环境中

如果此刻你还不能相信可以同时将两种技术整合到一起，那么让我给你举个例子：

在你的电脑上安装与服务器有相同操作系统的 Vagrant 虚拟机（一般来说是 Ubuntu Linux 12.04 LTS 64 位版）。这意味着你可以在任何你想要的操作系统上编程，并且期待这些程序也可以在服务器上运行。

通过在你虚拟机上安装 Docker 从而为 Vagrant 创造一个 Docker 容器。如果你能通过脚本来实现安装的话会更好。

在你的容器中安装应用程序（ Nginx 、 Memcached 、 MongoDB 等 ）

配置一个 shell 脚本、 Puppet 或者 Chef 脚本并安装 Docker 。每次 Vagrant 启动时运行 Docker 容器。

在你安装了 Vagrant 的虚拟机上测试你的容器。

现在你只需要怀着对提供者感激的心情使用同一个文件（你的 Vagrant 文件）并且敲下

vagrant up -provider = “ provider ”
复制代码

（此处的 provider 是指你的镜像源），之后 Vagrant 会帮你完成一切的。比如你选择 AWS 作为你的镜像源，之后 Vagrant 将会连接到你的 AWS 中的 AMI，安装一个和你电脑上使用的操作系统相同的系统，安装上 Docker 容器并启动它，之后给你返回一个 ssh 会话。
测试你在 AWS 中的容器并且观察他们是否得到你预想的运行效果。

译者注：上面提到的 AWS 是指 Amazon Web Services ，是一个 Amazon 提供的云主机服务

你可以看出， Vagrant 和 Docker 并不是相互竞争，而是互补的关系。因此，如果你不知道应该学哪一个的话，我的建议是两个都学，这样的话你可以同时从两个技术中受益。





Docker vs LXC/Ansible





为什么提出这问题？

在最近一次的 DevOPS 交流会上， @GrzegorzNosek问了这样一个好问题：为什么要用 Docker 来替代 LXC/Ansible ?

老实说我也一直尝试回答此问题，并且回答了部分（参见我在那次交流会上的 演讲。演讲主题是关于 Docker 让开发者运行开发环境十分简单。

就我本人而言，为什么会用 docker 呢? 作为系统管理员，我喜欢更底层的东西，用 LXC 自然是理所当然。

脸还是屁股？有何区别?

（如果你觉得这个标题令人尴尬或者心生厌恶，不妨回想一下 18 年前的 毁灭公爵维基词条）

你们都知道我在为 FedoraProject 做贡献，最近捣鼓一个项目 Fedora-Dockerfiles project。鼓捣这个项目一方面出于好玩，同时我也想对 Dokcer 了解更多。 当我和朋友们开始一些开源项目时，必须找到一种简单的方式去管理我们的开发环境。在这种情况下，答案就是 Docker 。

目前我在用 Docker 为哪些对 DevOPS/SysOPping 一无所知的人们准备开发环境，而编写 Dockerfiles 充满乐趣（不过偶尔也会有大坑）。 :)) LXC 表现如何呢？通过搭配 Ansible 使用，我能管理多个服务器资源（比如 VPN 、 DNS 、一些网页服务等）。有趣、速度快，并且非常稳定，让工作和生活简单多了。

谁是赢家？

不过对于我这种宁可用 fdisk 也不用 gparted （用 virsh 而不用 virt-manager ）的人来说，Docker 并不是一个管理服务的好例子。老实来讲，我依然在找寻这个 问题的答案。经过对 Dokcer 几周的研究（和数月对 LXC 的研究)，我可以告诉你一件明显的事，LXC 相比 Docker 还是简单些（例如在 spartan-like 这样的 Docker 镜像里运行 daemon 非常艰难，特别在某些库或者依赖缺失的情况下。）然而创建和运行 Dockerfile 却十分容易，就像创建 Ansible playbook 一样。

我觉得自己要做一件几年前已经做过的事情，那时我将 XEN 和KVM 共同运行在 FOSS full-virt race （免费开源项目全虚拟化竞赛）里。现在我打算同时使用 Docker 和 LXC 以观后效。 Docker 非常容易和完美地管理应用（因此使用 Docker 进行持续开发会是一个杀手级功能），而在一些基础服务（ Gitlab 、 DNS 、 VPN 等）中我会使用 LXC/Ansible 。不过为了好玩，我会让它们并行工作，比如我在 LXC 下部署 Gitlab 的时候也会顺便创建一个对应的 Dockerfile 。

借助这种开发方式，我想自己可能会在后面几周里找到这个问题的最佳答案，这也将会是非常棒的演讲话题。

谢谢楼主分享。