Docker（9）
Docker基础技术：AUFS
/articles/17061.html
AUFS是一种Union File System，所谓UnionFS就是把不同物理位置的目录合并mount到同一个目录中。UnionFS的一个最主要的应用是，把一张CD/DVD和一个硬盘目录给联合 mount在一起，然后，你就可以对这个只读的CD/DVD上的文件进行修改（当然，修改的文件存于硬盘上的目录里）。
AUFS又叫Another UnionFS，后来叫Alternative UnionFS，后来可能觉得不够霸气，叫成Advance UnionFS。是个叫Junjiro Okajima（岡島順治郎）在2006年开发的，AUFS完全重写了早期的UnionFS 1.x，其主要目的是为了可靠性和性能，并且引入了一些新的功能，比如可写分支的负载均衡。AUFS在使用上全兼容UnionFS，而且比之前的UnionFS在稳定性和性能上都要好很多，后来的UnionFS 2.x开始抄AUFS中的功能。但是他居然没有进到Linux主干里，就是因为Linus不让，基本上是因为代码量比较多，而且写得烂（相对于只有3000行的union
mount和10000行的UnionFS，以及其它平均下来只有6000行代码左右的VFS，AUFS居然有30000行代码），所以，岡島不断地改进代码质量，不断地提交，不断地被Linus拒掉，所以，到今天AUFS都还进不了Linux主干（今天你可以看到AUFS的代码其实还好了，比起OpenSSL好N倍，要么就是Linus对代码的质量要求非常高，要么就是Linus就是不喜欢AUFS）。
不过，好在有很多发行版都用了AUFS，比如：Ubuntu 10.04，Debian6.0, Gentoo Live CD支持AUFS，所以，也OK了。
好了，扯完这些闲话，我们还是看一个示例吧（环境：Ubuntu 14.04）
首先，我们建上两个目录（水果和蔬菜），并在这两个目录中放上一些文件，水果中有苹果和蕃茄，蔬菜有胡萝卜和蕃茄。
├── apple
└── tomato
vegetables
&&&&├──
&&&&└──
然后，我们输入以下命令：
-t aufs -o dirs=./fruits:./vegetables
none ./mnt
tree ./mnt
我们可以看到在./mnt目录下有三个文件，苹果apple、胡萝卜carrots和蕃茄tomato。水果和蔬菜的目录被union到了./mnt目录下了。
我们来修改一下其中的文件内容：
mnt & ./mnt/apple
./mnt/apple
./fruits/apple
上面的示例，我们可以看到./mnt/apple的内容改了，./fruits/apple的内容也改了。
mnt_carrots & ./mnt/carrots
./vegetables/carrots
./fruits/carrots
mnt_carrots
上面的示例，我们可以看到，我们修改了./mnt/carrots的文件内容，./vegetables/carrots并没有变化，反而是./fruits/carrots的目录中出现了carrots文件，其内容是我们在./mnt/carrots里的内容。
也就是说，我们在mount aufs命令中，我们没有指它vegetables和fruits的目录权限，默认上来说，命令行上第一个（最左边）的目录是可读可写的，后面的全都是只读的。（一般来说，最前面的目录应该是可写的，而后面的都应该是只读的）
所以，如果我们像下面这样指定权限来mount aufs，你就会发现有不一样的效果（记得先把上面./fruits/carrots的文件删除了）：
-t aufs -o dirs=./fruits=rw:./vegetables=rw
none ./mnt
&mnt_carrots&
& ./mnt/carrots
./vegetables/carrots
mnt_carrots
./fruits/carrots
./fruits/carrots:
No such file
or directory
现在，在这情况下，如果我们要修改./mnt/tomato这个文件，那么究竟是哪个文件会被改写？
&mnt_tomato&
& ./mnt/tomato
./fruits/tomato
mnt_tomato
./vegetables/tomato
am a vegetable
可见，如果有重复的文件名，在mount命令行上，越往前的就优先级越高。
你可以用这个例子做一些各种各样的试验，我这里主要是给大家一个感性认识，就不展开试验下去了。
那么，这种UnionFS有什么用？
历史上，有一个叫，其主要用于Linux演示、光盘教学、系统急救，以及商业产品的演示，不需要硬盘安装，直接把CD/DVD上的image运行在一个可写的存储设备上（比如一个U盘上），其实，也就是把CD/DVD这个文件系统和USB这个可写的系统给联合mount起来，这样你对CD/DVD上的image做的任何改动都会在被应用在U盘上，于是乎，你可以对CD/DVD上的内容进行任意的修改，因为改动都在U盘上，所以你改不坏原来的东西。
我们可以再发挥一下想像力，你也可以把一个目录，比如你的源代码，作为一个只读的template，和另一个你的working directory给union在一起，然后你就可以做各种修改而不用害怕会把源代码改坏了。有点像一个ad hoc snapshot。
Docker把UnionFS的想像力发挥到了容器的镜像。你是否还记得我在中用mount namespace和chroot山寨了一镜像。现在当你看过了这个UnionFS的技术后，你是不是就明白了，你完全可以用UnionFS这样的技术做出分层的镜像来。
下图来自Docker的官方文档，其很好的展示了Docker用UnionFS搭建的分层镜像。
关于docker的分层镜像，除了aufs，docker还支持btrfs, devicemapper和vfs，你可以使用 -s 或 –storage-driver= 选项来指定相关的镜像存储。在Ubuntu 14.04下，docker默认Ubuntu的 aufs（在CentOS7下，用的是devicemapper，关于devicemapper，我会以以后的文章中讲解）你可以在下面的目录中查看相关的每个层的镜像：
/var/lib/docker/aufs/diff/&id&
在docker执行起来后（比如：docker run -it ubuntu /bin/bash ），你可以从/sys/fs/aufs/si_[id]目录下查看aufs的mount的情况，下面是个示例：
br2&&&&& br4&&&&& br6&&&&& brid1&&& brid3&&& brid5&&& xi_path
br3&&&&& br5&&&&& brid0&&& brid2&&& brid4&&& brid6
/var/lib/docker/aufs/diff/ed1ebd2e2df7d2fe2aafdbd7=rw
/var/lib/docker/aufs/diff/ed1ebd2e2df7d2fe2aafdbd7-init=ro+wh
/var/lib/docker/aufs/diff/df5bfffd32d2d0bb669dbc3dfc64cfc5adfdec2d07=ro+wh
/var/lib/docker/aufs/diff/9fecbaf5ab5237caa39a84b0af5c593dc7cc=ro+wh
/var/lib/docker/aufs/diff/a1a958aaa646e5afbdaf050f537=ro+wh
/var/lib/docker/aufs/diff/f3c84ac3afea4cc2ceaaf43baec22bf8d6a479e069f6d814be9b86=ro+wh
/var/lib/docker/aufs/diff/c5a64f264b78b5433614aecdd4d=ro+wh
/run/shm/aufs.xino
你会看到只有最顶上的层（branch）是rw权限，其它的都是ro+wh权限只读的。
关于docker的aufs的配置，你可以在/var/lib/docker/repositories-aufs这个文件中看到。
AUFS的一些特性
AUFS有所有Union FS的特性，把多个目录，合并成同一个目录，并可以为每个需要合并的目录指定相应的权限，实时的添加、删除、修改已经被mount好的目录。而且，他还能在多个可写的branch/dir间进行负载均衡。
上面的例子，我们已经看到AUFS的mount的示例了。下面我们来看一看被union的目录（分支）的相关权限：
权限中，我们看到了一个术语：whiteout，下面我来解释一下这个术语。
一般来说ro的分支都会有wh的属性，比如 “[dir]=ro+wh”。所谓whiteout的意思，如果在union中删除的某个文件，实际上是位于一个readonly的分支（目录）上，那么，在mount的union这个目录中你将看不到这个文件，但是read-only这个层上我们无法做任何的修改，所以，我们就需要对这个readonly目录里的文件作whiteout。AUFS的whiteout的实现是通过在上层的可写的目录下建立对应的whiteout隐藏文件来实现的。
看个例子：
假设我们有三个目录和文件如下所示（test是个空目录）：
├── apple
└── tomato
vegetables
&&&&├──
&&&&└──
我们如下mount：
carrots& tomato
现在我们在权限为rw的test目录下建个whiteout的隐藏文件.wh.apple，你就会发现./mnt/apple这个文件就消失了:
上面这个操作和 rm ./mnt/apple是一样的。
šBranch&– 就是各个要被union起来的目录（就是我在上面使用的dirs的命令行参数）
šWhiteout&和&Opaque
看到上面这些，你一定会有几个问题：
其一、你可能会问，要有文件在原来的地方被修改了会怎么样？mount的目录会一起改变吗？答案是会的，也可以是不会的。因为你可以指定一个叫udba的参数（全称：User’s Direct Branch Access），这个参数有三个取值：
其二、如果有多个rw的branch（目录）被union起来了，那么，当我创建文件的时候，aufs会创建在哪里呢？&aufs提供了一个叫create的参数可以供你来配置相当的创建策略，下面有几个例子。
create=rr | round-robin&轮询。下面的示例可以看到，新创建的文件轮流写到三个目录中
-t aufs& -o dirs=./1=rw:./2=rw:./3=rw
-o create=rr none ./mnt
create=mfs[:second] | most-free-space[:second]&选一个可用空间最好的分支。可以指定一个检查可用磁盘空间的时间。
create=mfsrr:low[:second]&选一个空间大于low的branch，如果空间小于low了，那么aufs会使用 round-robin 方式。
更多的关于AUFS的细节使用参数，大家可以直接在Ubuntu 14.04下通过来看一下其中的各种参数和命令。
AUFS的性能
AUFS的性能慢吗？也慢也不慢。因为AUFS会把所有的分支mount起来，所以，在查找文件上是比较慢了。因为它要遍历所有的branch。是个O(n)的算法（很明显，这个算法有很大的改进空间的）所以，branch越多，查找文件的性能也就越慢。但是，一旦AUFS找到了这个文件的inode，那后以后的读写和操作原文件基本上是一样的。
所以，如果你的程序跑在在AUFS下，open和stat操作会有明显的性能下降，branch越多，性能越差，但是在write/read操作上，性能没有什么变化。
IBM的研究中心对Docker的性能给了一份非常不错的性能报告（PDF）《》
我截了两张图出来，第一张是顺序读写，第二张是随机读写。基本没有什么性能损失的问题。而KVM在随机读写的情况也就有点慢了（但是，如果硬盘是SSD的呢？）
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：365127次
积分：6125
积分：6125
排名：第2676名
转载：1584篇
评论：40条
(16)(31)(40)(45)(31)(34)(99)(140)(111)(126)(77)(40)(27)(54)(40)(65)(147)(126)(121)(15)(56)(115)(7)(1)(1)(1)(2)(4)(7)(1)(1)(4)(4)(1)(1)(3)(3)(9)docker容器跨服务器的迁移方式export和save | 峰云就她了
7,439 views
& & & & 这两天把报警平台放在了docker里面跑了，但是宿主机本身性能就不好，所以导致mongodb到挂了好几次了。这次搞了一台牛逼的服务器，虽说是opentstack里面的主机，但是iops 很不错。
感谢向军同学的帮助，不然就升级uek内核就能搞死我。
& & &你的程序放在docker里面迁移起来很是方便，像是以前的话，需要重新部署环境和静态文件。 放在docker里面的话，只是需要export备份封装后，scp、rsync迁移到别的服务器就可以了。
我这边的redis和mongodb分在不同的容器里面的。 废话不多说，开始迁移。。。
查找正在运行的容器id ～
root@dev-ops:~# docker ps -a
CONTAINER ID
459e57c9a5d9
rastasheep/ubuntu-sshd:latest
About an hour ago
Up 45 minutes
compassionate_ptolemy
70c74ebbfac4
rastasheep/ubuntu-sshd:14.04
/usr/sbin/sshd -D
About an hour ago
Up About an hour
0.0.0.0:49157-&22/tcp
3ebbc244c486
rastasheep/ubuntu-sshd:latest
/usr/sbin/sshd -D
18 hours ago
Up About an hour
rastasheep/ubuntu-sshd:latest
/usr/sbin/sshd -D
19 hours ago
Up About an hour
0.0.0.0:49153-&22/tcp
redis_test
&CONTAINER ID&&&&&&&&IMAGE&&&&&&&&&&&&&&&&&&&&&&&&&& COMMAND&&&&&&&&&&&& CREATED&&&&&&&&&&&& STATUS&&&&&&&&&&&&&&PORTS&&&&&&&&&&&&&&&&&& NAMES459e57c9a5d9&&&&&&&&rastasheep/ubuntu-sshd:latest&& /bin/bash&&&&&&&&&& About an hour ago&& Up 45 minutes&&&&&& 22/tcp&&&&&&&&&&&&&&&&&&compassionate_ptolemy&& 70c74ebbfac4&&&&&&&&rastasheep/ubuntu-sshd:14.04&&&&/usr/sbin/sshd -D&& About an hour ago&& Up About an hour&&&&0.0.0.0:49157-&22/tcp&& s&&&&&&&&&&&&&&&&&&&&&& 3ebbc244c486&&&&&&&&rastasheep/ubuntu-sshd:latest&& /usr/sbin/sshd -D&& 18 hours ago&&&&&&&&Up About an hour&&&&22/tcp&&&&&&&&&&&&&&&&&&redis_t2&&&&&&&&&&&&&&&&ed&&&&&&&&rastasheep/ubuntu-sshd:latest&& /usr/sbin/sshd -D&& 19 hours ago&&&&&&&&Up About an hour&&&&0.0.0.0:49153-&22/tcp&& redis_test
root@dev-ops:~#&
root@dev-ops:~# docker export 70c74ebbfac4 &ubuntu_sshd.tar
root@dev-ops:~#&
root@dev-ops:~#&
root@dev-ops:~# du -sh ubuntu_sshd.tar
ubuntu_sshd.tar
&353M&&&&ubuntu_sshd.tar
然后把这个ubuntu_sshd.tar &传到别的服务器上。&
root@31-53:~# cat ubuntu_sshd.tar | sudo docker import - niubi:latest
8f2baf1b1cf479efaad6d2e043aac9204
root@31-53:~#
&root@31-53:~# cat ubuntu_sshd.tar | sudo docker import - niubi:latest8f2baf1b1cf479efaad6d2e043aac9204root@31-53:~#
本来只是想把程序、mongodb、redis迁移过去。 既然迁移，干脆把所有的images迁移到新的节点上来。
docer export 对应导入的命令是cat xxx | docker import – name 。我这里用的是niubi：latest ……
cat ubuntu_sshd.tar | sudo docker import - niubi:latest
&cat ubuntu_sshd.tar | sudo docker import - niubi:latest
上面的方式是用docker export。 export是当前的状态，docker save 是针对镜像images。
主要的区别是 save是可以回滚以前的配置。 export 只是当前的。
我们通过 docker images –tree 看到他的历史记录。Docker的文件系统AUFS，一种“增量文件系统”，用户所做修改以增量的方式保存，所以才能看到这些历史的增量。
咱们用save 看看备份效果。 是1.1G &，这里是包含那些记录的。刚才咱们用export测试的时候，会发现文件只有300M左右。
root@dev-ops:~# docker save rastasheep/ubuntu-sshd &ubuntu_sshd.tar
root@dev-ops:~#
root@dev-ops:~#
root@dev-ops:~# du -sh ubuntu_sshd.tar
ubuntu_sshd.tar
root@dev-ops:~#
&root@dev-ops:~# docker save rastasheep/ubuntu-sshd &ubuntu_sshd.tar root@dev-ops:~# root@dev-ops:~# root@dev-ops:~# du -sh ubuntu_sshd.tar 1.1G&&&&ubuntu_sshd.tarroot@dev-ops:~#
我估计如果有分布式文件系统 ，比如mfs，nfs。可以更好的试试用docker的数据卷来做本地文件夹和容器内的关联。 这样的话，备份更加自定义了。 毕竟环境这东西不会变，变的只是data数据，然后文件目录又在分布式文件里面，可以更好做迁移。只要那边启动一个环境，目录一关联就可以了。
sudo docker run --volumes-from dbdata -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata
http://rfyiamcool./0414
&sudo docker run --volumes-from dbdata -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdatahttp://rfyiamcool.blog./1030776/1540414
备份迁移的方式自己选，推荐用export，毕竟save太大了，对于历史也没啥用处 ！
对于数据安全关注更深的话，可以用docker volumes这样的数据映射。
如果大家觉得文章对你有些作用！ &
帮忙点击广告. 一来能刺激我写博客的欲望，二来好维护云主机的费用.
如果想赏钱，可以用微信扫描下面的二维码.
另外再次标注博客原地址 && …… &&感谢！
您可能也喜欢:
暂无相关产品后使用快捷导航没有帐号？
查看: 658|回复: 3
docker pull 下来的文件存放在什么地方?
高级会员, 积分 844, 距离下一级还需 156 积分
论坛徽章:4
google 了很多,
这里说在 /var/lib/docker/repositories 能看到一些信息,但在 mac 和 centos7 下都试了根本找不到这个文件, 可能是 docker 的版本不同, 我使用的是最新的版本1.9.
这是 mac 下 docker info 的结果:
QQ@2x.png (679.67 KB)
14:01 上传
上面那个Root dir 根本找不到, 全盘搜索 docker 的文件,也没找到.
**问题一: mac 下 pull 下来的文件到底是放在哪里的?**
在 centos7 下:
QQ@2x.png (214.8 KB)
14:08 上传
/var/lib/docker/devicemapper/devicemapper 目录很大, 所以应该就是放在这里的,但问题来了:
**问题2:这两个文件是个什么结构,怎么查看?**
QQ@2x.png (56.21 KB)
14:15 上传
高级会员, 积分 612, 距离下一级还需 388 积分
论坛徽章:3
本地的镜像文件都存放在哪里？
与 Docker 相关的本地资源都存放在/var/lib/docker/目录下，其中container目录存放容器信息，graph目录存放镜像信息，aufs目录下存放具体的内容文件。
高级会员, 积分 844, 距离下一级还需 156 积分
论坛徽章:4
没人帮忙看一下么
高级会员, 积分 644, 距离下一级还需 356 积分
论坛徽章:5
这个都是内部数据，估计看不了吧你的位置： >
> 深入浅出Docker（一）：Docker核心技术预览
原文链接：
【编者按】Docker是PaaS供应商dotCloud开源的一个基于LXC 的高级容器引擎，源代码托管在 GitHub 上,
基于Go语言开发并遵从Apache
2.0协议开源。Docker提供了一种在安全、可重复的环境中自动部署软件的方式，它的出现拉开了基于云计算平台发布产品方式的变革序幕。为了更好的促
进Docker在国内的发展以及传播，我们决定开设《》
专栏，邀请Docker相关的布道师、开发人员、技术专家来讲述Docker的各方面内容，让读者对Docker有更深入的了解，并且能够积极投入到新技
术的讨论和实践中。另外，欢迎加入InfoQ Docker技术交流群交流Docker的最佳实践，QQ群号：。
1.1. 由PaaS到Container
2013年2月，前Gluster的CEO Ben Golub和dotCloud的CEO Solomon
Hykes坐在一起聊天时，Solomon谈到想把dotCloud内部使用的Container容器技术单独拿出来开源，然后围绕这个技术开一家新公司
提供技术支持。28岁的Solomon在使用python开发dotCloud的PaaS云时发现，使用 LXC(Linux Container)
技术可以打破产品发布过程中应用开发工程师和系统工程师两者之间无法轻松协作发布产品的难题。这个Container容器技术可以把开发者从日常部署应用
的繁杂工作中解脱出来，让开发者能专心写好程序；从系统工程师的角度来看也是一样，他们迫切需要从各种混乱的部署文档中解脱出来，让系统工程师专注在应用
的水平扩展、稳定发布的解决方案上。他们越深入交谈，越觉得这是一次云技术的变革，紧接着在2013年3月Docker
0.1发布，拉开了基于云计算平台发布产品方式的变革序幕。
1.2 Docker简介
是 Docker.Inc 公司开源的一个基于 LXC技术之上构建的Container容器引擎， 托
管在 GitHub 上, 基于Go语言并遵从Apache2.0协议开源。 Docker在2014年6月召开DockerConf
2014技术大会吸引了IBM、Google、RedHat等业界知名公司的关注和技术支持，无论是从 GitHub
上的代码活跃度，还是Redhat宣布在r, 都给业界一个信号，这是一项创新型的技术解决方案。 就连 Google 公司的 Compute Engine 也, 国内“BAT”先锋企业百度Baidu App Engine(BAE)平台也是。
Docker产生的目的就是为了解决以下问题:&& & &
1) 环境管理复杂:
从各种OS到各种中间件再到各种App，一款产品能够成功发布，作为开发者需要关心的东西太多，且难于管理，这个问题在软件行业中普遍存在并需要直接面
对。Docker可以简化部署多种应用实例工作，比如Web应用、后台应用、数据库应用、大数据应用比如Hadoop集群、消息队列等等都可以打包成一个
Image部署。如图所示：
2) 云计算时代的到来: AWS的成功, 引导开发者将应用转移到云上, 解决了硬件管理的问题，然而软件配置和管理相关的问题依然存在 (AWS cloudformation是这个方向的业界标准, 样例模板可)。Docker的出现正好能帮助软件开发者开阔思路，尝试新的软件管理方法来解决这个问题。
3) 虚拟化手段的变化:
云时代采用标配硬件来降低成本，采用虚拟化手段来满足用户按需分配的资源需求以及保证可用性和隔离性。然而无论是KVM还是Xen，在 Docker
看来都在浪费资源，因为用户需要的是高效运行环境而非OS, GuestOS既浪费资源又难于管理, 更加轻量级的LXC更加灵活和快速。如图所示：
4) LXC的便携性: LXC在 Linux 2.6 的 Kernel
里就已经存在了，但是其设计之初并非为云计算考虑的，缺少标准化的描述手段和容器的可便携性，决定其构建出的环境难于分发和标准化管理(相对于KVM之类
image和snapshot的概念)。Docker就在这个问题上做出了实质性的创新方法。
1.3 Docker的Hello World
以Fedora 20作为主机为例，直接安装docker-io：
$&sudo&yum&-y&install&docker-io
启动docker后台Daemon:
$&sudo&systemctl&start&docker
跑我们第一个Hello World容器：
$&sudo&docker&run&-i&-t&fedora&/bin/echo&hello&world
Hello&world
可以看到在运行命令行后的下一行会打印出经典的Hello World字符串。
2. 核心技术预览
Docker核心是一个方法, 理解起来可能并不像VM那样直观。我们从虚拟化方法的四个方面：隔离性、可配额/可度量、便携性、安全性来详细介绍Docker的技术细节。
2.1. 隔离性: Linux Namespace(ns)
每个用户实例之间相互隔离, 互不影响。 一般的硬件虚拟化方法给出的方法是VM，而LXC给出的方法是container，更细一点讲就是kernel namespace。其中pid、net、ipc、mnt、uts、user等namespace将container的进程、网络、消息、文件系统、UTS(&UNIX Time-sharing System&)和用户空间隔离开。
1) pid namespace
不同用户的进程就是通过pid namespace隔离开的，且不同 namespace
中可以有相同pid。所有的LXC进程在docker中的父进程为docker进程，每个lxc进程具有不同的namespace。同时由于允许嵌套，因
此可以很方便的实现 Docker in Docker。
2) net namespace
有了 pid namespace, 每个namespace中的pid能够相互隔离，但是网络端口还是共享host的端口。网络隔离是通过net
namespace实现的， 每个net namespace有独立的 network devices, IP addresses, IP
routing tables, /proc/net
目录。这样每个container的网络就能隔离开来。docker默认采用veth的方式将container中的虚拟网卡同host上的一个
docker bridge: docker0连接在一起。
3) ipc namespace
container中进程交互还是采用linux常见的进程间交互方法(interprocess communication – IPC),
包括常见的信号量、消息队列和共享内存。然而同 VM 不同的是，container 的进程间交互实际上还是host上具有相同pid
namespace中的进程间交互，因此需要在IPC资源申请时加入namespace信息 – 每个IPC资源有一个唯一的 32 位 ID。
4) mnt namespace
类似chroot，将一个进程放到一个特定的目录执行。mnt namespace允许不同namespace的进程看到的文件结构不同，这样每个
中的进程所看到的文件目录就被隔离开了。同chroot不同，每个namespace中的container在/proc/mounts的信息只包含所在
namespace的mount point。
5) uts namespace
UTS(&UNIX Time-sharing System&) namespace允许每个container拥有独立的hostname和domain name, 使其在网络上可以被视作一个独立的节点而非Host上的一个进程。
6) user namespace
每个container可以有不同的 user 和 group id, 也就是说可以在container内部用container内部的用户执行程序而非Host上的用户。
2.2 可配额/可度量 – Control Groups (cgroups)
cgroups 实现了对资源的配额和度量。 cgroups 的使用非常简单，提供类似文件的接口，在
/cgroup目录下新建一个文件夹即可新建一个group，在此文件夹中新建task文件，并将pid写入该文件，即可实现对该进程的资源控制。
groups可以限制blkio、cpu、cpuacct、cpuset、devices、freezer、memory、net_cls、ns九大子系
统的资源，以下是每个子系统的详细说明：
blkio 这个子系统设置限制每个块设备的输入输出控制。例如:磁盘，光盘以及usb等等。
cpu 这个子系统使用调度程序为cgroup任务提供cpu的访问。
cpuacct 产生cgroup任务的cpu资源报告。
cpuset 如果是多核心的cpu，这个子系统会为cgroup任务分配单独的cpu和内存。
devices 允许或拒绝cgroup任务对设备的访问。
freezer 暂停和恢复cgroup任务。
memory 设置每个cgroup的内存限制以及产生内存资源报告。
net_cls 标记每个网络包以供cgroup方便使用。
ns 名称空间子系统。
以上九个子系统之间也存在着一定的关系.详情请参阅。
2.3 便携性: AUFS
AUFS (AnotherUnionFS) 是一种 Union FS, 简单来说就是支持将不同目录挂载到同一个虚拟文件系统下(unite
several directories into a single virtual filesystem)的文件系统, 更进一步的理解,
AUFS支持为每一个成员目录(类似Git Branch)设定readonly、readwrite 和 whiteout-able 权限, 同时
AUFS 里有一个类似分层的概念, 对 readonly 权限的 branch 可以逻辑上进行修改(增量地, 不影响 readonly
部分的)。通常 Union FS 有两个用途, 一方面可以实现不借助 LVM、RAID 将多个disk挂到同一个目录下,
另一个更常用的就是将一个 readonly 的 branch 和一个 writeable 的 branch 联合在一起，Live
CD正是基于此方法可以允许在 OS image 不变的基础上允许用户在其上进行一些写操作。Docker 在 AUFS 上构建的
container image 也正是如此，接下来我们从启动 container 中的 linux 为例来介绍 docker
对AUFS特性的运用。
典型的启动Linux运行需要两个FS: bootfs + rootfs:
bootfs (boot file system) 主要包含 bootloader 和 kernel,
bootloader主要是引导加载kernel, 当boot成功后 kernel 被加载到内存中后 bootfs就被umount了.
rootfs (root file system) 包含的就是典型 Linux 系统中的 /dev, /proc,/bin, /etc
等标准目录和文件。
对于不同的linux发行版, bootfs基本是一致的, 但rootfs会有差别, 因此不同的发行版可以公用bootfs 如下图:
典型的Linux在启动后，首先将 rootfs 设置为 readonly, 进行一系列检查, 然后将其切换为 &readwrite&
供用户使用。在Docker中，初始化时也是将 rootfs 以readonly方式加载并检查，然而接下来利用 union mount
的方式将一个 readwrite 文件系统挂载在 readonly 的rootfs之上，并且允许再次将下层的 FS(file system)
设定为readonly 并且向上叠加, 这样一组readonly和一个writeable的结构构成一个container的运行时态,
每一个FS被称作一个FS层。如下图:
得益于AUFS的特性, 每一个对readonly层文件/目录的修改都只会存在于上层的writeable层中。这样由于不存在竞争, 多个container可以共享readonly的FS层。 所以Docker将readonly的FS层称作 &image& – 对于container而言整个rootfs都是read-write的，但事实上所有的修改都写入最上层的writeable层中, image不保存用户状态，只用于模板、新建和复制使用。
上层的image依赖下层的image，因此Docker中把下层的image称作父image，没有父image的image称作base
image。因此想要从一个image启动一个container，Docker会先加载这个image和依赖的父images以及base
image，用户的进程运行在writeable的layer中。所有parent image中的数据信息以及
ID、网络和lxc管理的资源限制等具体container的配置，构成一个Docker概念上的container。如下图:
2.4 安全性: AppArmor, SELinux, GRSEC
安全永远是相对的，这里有三个方面可以考虑Docker的安全特性:
由kernel namespaces和cgroups实现的Linux系统固有的安全标准;
Docker Deamon的安全接口;
Linux本身的安全加固解决方案,类如AppArmor, SEL
由于安全属于非常具体的技术，这里不在赘述，请直接参阅。
3. 最新子项目介绍
我们再来看看Docker社区还有哪些子项目值得我们去好好研究和学习。基于这个目的，我把有趣的核心项目给大家罗列出来，让热心的读者能快速跟进自己感兴趣的项目:
Libswarm，是Solomon Hykes (Docker的CTO) 在DockerCon
2014峰会上向社区介绍的新“乐高积木”工具:
它是用来统一分布式系统的网络接口的API。Libswarm要解决的问题是，基于Docker构建的分布式应用已经催生了多个基于Docker的服务发
现(Serivce Discovery)项目，例如etcd, fleet, geard, mesos, shipyard,
serf等等，每一套解决方案都有自己的通讯协议和使用方法，使用其中的任意一款都会局限在某一个特定的技术范围內。所以Docker的CTO就想用
libswarm暴露出通用的API接口给分布式系统使用，打破既定的协议限制。目前项目还在早期发展阶段，值得参与。
Libchan，是一个底层的网络库，为上层 Libswarm
提供支持。相当于给Docker加上了ZeroMQ或RabbitMQ，这里自己实现网络库的好处是对Docker做了特别优化，更加轻量级。一般开发者
不会直接用到它，大家更多的还是使用Libswarm来和容器交互。喜欢底层实现的网络工程师可能对此感兴趣，不妨一看。
Libcontainer，Docker技术的核心部分，单独列出来也是因为这一块的功能相对独立，功能代码的迭代升级非常快。想了解Docker最新的支持特性应该多关注这个模块。
Docker社区一直在面对技术挑战，从容地给出自己的解决方案。云计算发展至今，有很多重要的问题没有得到妥善解决，Docker正在尝试让主流
厂商接受并应用它。至此，以上Docker技术的预览到此告一段落，笔者也希望读者能结合自己的实际情况，尝试使用Docker技术。因为只有在亲自体会
的基础之上，像Docker这样的云技术才会产生更大的价值。
5. 作者简介
肖德时, Red Hat Engineering Service/HSS 内部工具组Team
Leader，Nodejs开源项目nodejs-cantas Lead Developer。擅长企业内部工具的设计以及实现。开源课程Rails
Starter的发起人。rubygem:
lazy_high_charts的Maintainer。twitter账号：xds2000，邮箱：
6. 参考文献:
感谢对本文的审校。
转载请注明： &
与本文相关的文章