炒个冷饭LXC,试问Docker你凭啥这么火?
每次扫到Docker融资数据,脑子里就会冒出来一个问题:Docker咋就这火呢!那谁,爹都不要了,咋还这么火?9500万美金的D轮,到底值不值?
事情是这样的,这两年我们不断听到container、“容器”、Container、Docker...... “容器”大火,但大多数人知道“容器”,估计不是从linux,不是从LXC, 都是因为Docker才知道的吧?不得不说,这就是Docker的厉害之处。
先说说LXC~~LXC中文就是Linux容器工具,linux原生支持的容器,可以追溯到2009年,源于cgroup和namespaces在Linux内核方面的发展,是一种轻量级的容器虚拟化技术,最大效率隔离进程和资源。它可以把传统虚拟技术以及后来的Xen、KVM的VM进程像HOST进程一样运行管理, 所以创建和销毁都非常轻。
2013年,Docker横空出世,Docker是啥呢?就是一个基于LXC 的高级容器引擎。Docker做了件什么事呢?打包!你可以在一个容器里写完之后,装箱打包成一个镜像,然后轻松部署在不同的运行环境里。Docker解决了运行环境依赖问题,不再有“为啥明明刚才在我那里可以跑起来到你这里就不行”的问题。如果说LXC着眼点在于提供轻量级的虚拟技术,扎根在虚拟机,那Docker则定位于应用。Docker所为人称道的portability、application-centric、versioning等等超越传统虚拟技术的优点都跟它的封装性密不可分。开发和测试装个docker, pull下image,再也不用受困于不同的开发环境、系统依赖和配置文件。。。是不是瞬间天亮了?
Docker这个发明magic package的故事,就完了吗?当然不是,问题来了~~ 为什么呢?有人就问了,那我log怎么办呢?挂在数据卷里!ssh怎么搞呢?用docker exec! 呃,那如果我要跑cron呢?抱歉,没法子哦。。。说了那么多,Docker的底层镜像操作系统的设计,仅仅是把一个个进程打包封装在一个个盒子里,相互隔离,运来运去,别的事情,它一概就不管了。。。。Docker不管多进程应用程序、不管设计、也不管其他服务,而且还stateless... 你是不是要崩溃了??
真相了,是不是?有一个比喻说的很好,Docker不是万灵药,它本身也不是一个app或者app的一个部件,而是OS/ubuntu的一个最小单位的砖头块,尽管这是史上最牛X的黄金砖。。。然而在生产环境下,实际上更具有挑战性的问题是,如何能让成千上万个Docker封装的executable magic package有机协同工作,谁来安排谁来管?那就需要一个强大高能的编排系统来运作,Caicloud就是这个高能者~~~(顿时形象高大起来^ ^)
之前Docker的libcontainer,到最近Docker最新版本1.10里移除了对LXC的support,Docker和LXC的分家有很多原因,也势在必行,但不管未来咋样,也无法抹杀Docker和LXC之间的传承。呃,我不是LXC派来的卧底,今天炒的这碗冷饭是说,LXC虽然已经不被Docker支持,但并没有过时,依然是经典的容器技术;儿子不要爹了,可爹还是那个爹。。。。。。有兴趣就来一起玩一玩Docker的老爹吧~~~ 只要你有比较新版本的linux kernel, 就可以建立一个LXC虚机系统来生成运行容器,LXC容器也可以嵌套,可以用cgroup来限定资源。。。
下面参考的这是一篇翻译自Stephane Graber主页的文章,LXC系统目前由一个两人的团队领导:来自Ubuntu的Stephane Graber和Serge Hallyn, LXC是由Ubuntu支持的。
那么什么是LXC?
你们之中大部分人很应该已经知道什么是LXC了,但是在这里,我们这样定义:
“LXC是一个为Linux内核包含特征的用户接口。通过强大的API和简单的工具,它可以让Linux用户轻松的创建和托管系统或者应用程序容器。”
我和Serge Hallyn是LXC的两个上游维护者之一。每个月,项目都有着里程碑式的积极发展,并且在二月份会发布一个稳定版本。到目前为止,它已经被67个来自不同背景和公司的贡献者开发。
LXC1.0
那么1.0版本到底发布了什么呢?
好的,简单的说,它将是第一个真正稳定的LXC版本,也是第一个我们将
支持5年的bug修正版本。它也是包括在Ubuntu14.04LTS里面的一个,将和Ubuntu在2014年4月一起发布。
与之一起的是,稳定的API,一组绑定,很多有趣的新特点。这些新的特点会在下一期的帖子里详细阐述,并且支持大范围的主机和客机分布(包括Andriod)。
如何使用它?
我猜你们之中大部分人都将会一直使用Ubuntu。在接下来的少数帖子中,我会一直在Ubuntu14.04上使用目前上游的每日构建,我们维护每日构建的时间分别是:12.04,12.10,13.04,13.10,以及14.04,所以如果想要最新的上游代码,可以使用我们的PPA。
另外,LXC也是在Ubuntu中直接使用的,在Ubuntu12.04LTS之后也十分有用。你可以选择这样一个版本,就是无论你在发布哪个,它都会跟着这个版本,或者你可以使用我们维护的那个布丁版本。
如果想要自己创建,可以这么做(但是如果你在你的linux发行版上面可以是直接使用软件包,我们不推荐这个方法):
git clone git://github.com/lxc/lxc
cd lxc
sh autogen.sh
You will probably want to run theconfigure script with --help and then set the paths
./configure
make
sudo make install
关于第一个容器
对了, 容器才是我们这篇帖子真正的目标对吧?
好的,那既然你已经安装了LXC,满怀希望地使用Ubuntu打包,那么事情就简单了:
Create a "p1" container usingthe "ubuntu" template and the same version of Ubuntu
and architecture as the host. Pass"-- --help" to list all available options.
sudo lxc-create -t ubuntu -n p1
Start the container (in the background)
sudo lxc-start -n p1 -d
Enter the container in one of thoseways## Attach to the container's console (ctrl-a + q to detach)
sudo lxc-console -n p1
Spawn bash directly in the container(bypassing the console login), requires a >= 3.8 kernel
sudo lxc-attach -n p1
SSH into it
sudo lxc-info -n p1
ssh ubuntu@<ip from lxc-info>
Stop the container in one of those ways
Stop it from within
sudo poweroff
Stop it cleanly from the outside
sudo lxc-stop -n p1
Kill it from the outside
sudo lxc-stop -n p1 -k
好了!这就是你的第一个容器了。你会注意到,所有东西都是在Ubuntu上面运行的。我们的内核支持所有LXC可能使用到的特点,我们的packages构建了桥梁和DHCP服务器,这样容器在默认情况下就会使用。
LXC2.0 你的第二个容器
更多模版
现在呢,你应该已经有一个在运行的Ubuntu容器了,叫做“p1”,是使用默认模版简洁“ubuntu”创建的。
但是LXC支持的比标准Ubuntu多很多。事实上,在目前的上游git(以及日常PPA),我们支持AlpineLinux,Alt Linux,Arch Linux,busybox,CentOS,Cirros,Debian,Fedora,OpenMandriva,OpenSUSE,Oracle,Plamo,sshd,Ubuntu云端以及Ubuntu。
以上那些都可以在/usr/share/lxc/templates里面找到。他们通常还有额外的高级选项,可以通过在“lxc-create”呼叫之后输入“—help”来实现(“--”可以从模版里分裂出“lxc-create”选项)。
再写一个额外的模版也不是很困难的事情,他们基本上都是可执行文件(都是shell脚本,但是这不是必须的),采取了一整套标准参数,预计会在路径中生成一个工作的根文件系统传递给他们。
需要注意的一点就是,由于工具丢失,所以不是所有的发行版都可以在发行版上自我启动的。通常还是要试一试。我们总是喜欢将这些工作运行在更多的发行版上面,即使这么做意味着使用一些小技俩也在所不惜(比如,在fedora模版里,我们就是这么做的)。所以,如果你现下有不能运行的特定组合,欢迎使用补丁~
不管怎样,先谈现下,让我们继续往下说,现在我们来创建一个Oracle Linux容器,将其强制为32bit。
sudo lxc-create -t oracle -n p2 -- -a i386
在很多系统上,它一开始就会运行失败,并告诉你要安装“rpm”包才可以,bootstrap也有需要这样的安装的理由。所以安装“rpm”,然后再次尝试。
在下载完RPMs之后一段时间,容器就会被创建了,然后再:
sudo lxc-start -n p2
你会被Oracle Linux登陆提示欢迎使用(root/root)
那么现在,既然你已经开启容器了,没有将“-d”传递给“lxc-start”,那么你就不得不将其关闭,再将shell弄回来(你不能将一个在背景情境下没有初始化开的的容器分离)。
那现在如果你很好奇为什么Ubuntu有两个版本。目前我正在使用的Ubuntu模版用“deboostrap”基本上从头创建您的容器,但是Ubuntu云端模版(ubuntucloud)下载了一个预生成云镜像(与你在EC2或者其他云端服务上得到的完全一样),并开启。这个镜像包括初始化云,还支持标准云元数据。
这完全是个人选择问题,个人喜欢哪个就可以选哪个。我个人建议是拥有一个本地镜像,这样的话“ubuntu”模版对我来说就快多了,我知道所有东西都已经在我之前从档案文件那里下载,并且已经在本地组装了,因此我更加信任它。
关于模版的最后一个注解。大多数都使用本地缓存,所以最初的容器引导程序进程缓慢,对于一种架构,容器的首次启动会比较缓慢,之后的启动会比较快,因为有本地缓存。
自动启动
那么,如果你想要在开机时序自动开启容器会怎么样呢?
其实,上述情况在Ubuntu上和其他的通过使用一些初始脚本和符号连接的发行版上面早就已经是支持的了,但是最近(两天前),这就已经在上游实施了,干劲利落。
所以这就是自动启动容器如何的:
可能就像你所知道的,每个容器通常在/var/lib/lxc/<container name>/config下面都有一个配置文件。
那个文件就是key=value,在lxc.conf(5),有效keys清单会被详细列出来。
可用的启动相关值有:
§ lxc.start.auto = 0 (disabled) or 1(enabled)
§ lxc.start.delay = 0 (delay in second towait after starting the container)
§ lxc.start.order = 0 (priority of thecontainer, higher value means starts earlier)
§ lxc.group = group1,group2,group3,… (groupsthe container is a member of)
当你的机器启动的时候,初始脚本就会要求“lxc-autostart”来以正确顺序开启所有已经给定的组的容器(默认情况下,是所有容器而不是任意一个),并且等待这些容器之间的特定时间。
要阐述清楚,编辑/var/lib/lxc/p1/config 并且贴这几行到文件里:
lxc.start.auto = 1
lxc.group = Ubuntu
以及 /var/lib/lxc/p2/config,并贴上这几行:
lxc.start.auto = 1
lxc.start.delay = 5
lxc.start.order = 100
那么做意味着,只有p2容器会在开机时间启动(因为这些如果没有一个组的话就是系统默认情况),顺序值是没有关系的,因为它是独立的,初始脚本在你继续之前会停留5秒。
通过“lxc-ls”可以检查什么容器是自动启动的:
stgraber@castiana:~$ sudo lxc-ls --fancy
NAME STATE IPV4 IPV6 AUTOSTART
p1 RUNNING 10.0.3.128 2607:f2c0:f00f:2751:216:3eff:feb1:4c7f YES (ubuntu)
p2 RUNNING 10.0.3.165 2607:f2c0:f00f:2751:216:3eff:fe3a:f1c1 YES
你也可以通过“lxc-autostart“命令手动启动那些容器,这个命令可以让你启动/停止/中止/重新启动任意用lxc.start.auto=1标记的容器。
比如,你可以这么做:
sudo lxc-autostart –a
这个命令会开启任意有lxc.start.auto=1(忽略lxc.group值),这在我们的情况下意味着它将第一开启p2(由于order=100),然后等待5秒(因为delay=5),然后开启p1,并且之后马上调回来。
如果在那时你想要中止ubuntu里面的所有容器,你可以这么做:
sudo lxc-autostart -r -g Ubuntu
你也可以通过这些命令中的任意一个来输入“-L”,这些命令仅仅只是影响打印哪个容器,以及会造成怎样的延迟,但是事实上并不会有影响(对于与其它脚本集成还是有好处的)。
冻结你的容器
有时候容器可能正在运行守护进程,这个进程需要时间来关闭或者重启,但是你不要想去运行容器,因为你在那个时间点不是主动使用它的。
在这些情况下,可以使用“sudo lxc-freeze -n <container name>” 。这个仅仅冻结了容器里所有的进程所以他们不会得到任何时间分配的调度器。然而进程还是会存在,而且会继续使用他们之前所使用的存储。
一旦你再次需要服务,只要调用 “sudo lxc-unfreeze -n <container name>” ,所有进程就会重新启动。
连网
你可能已经注意到在配置文件里,当你正在设置自动启动设置的时候,LXC有一个相对灵活的网络配置。
系统默认设置下,在Ubuntu里,我们每个容器指定一个“veth”设备,这个在主机上桥接成一个“lxcbr0”桥,在这个上面,我们跑一个最小 dnsmasq DHCP 服务器。
对于大多数人,那都是很好的。你可能想要一些东西略微再复杂一点,比如容器里的多网络接口,或者通过物理的网络接口,等等。这些的细节都列在lxc.conf(5)里面了,所以我在这里就不再赘述,但是这里有个简单的例子可以做:
lxc.network.type = veth
lxc.network.hwaddr = 00:16:3e:3a:f1:c1
lxc.network.flags = up
lxc.network.link = lxcbr0
lxc.network.name = eth0
lxc.network.type = veth
lxc.network.link = virbr0
lxc.network.name = virt0
lxc.network.type = phys
lxc.network.link = eth2
lxc.network.name = eth1
有了这个设置,我的容器就会有3个接口,虚拟接口0在lxcbro桥都是寻常VETH设备,虚拟接口1是主机的,虚拟接口2是移动到容器里面(它会在容器正运行的时候从主机上面消失),virt0则是虚拟网桥的两个接口。
那两个接口都没有mac地址或者网络信号设置,所以他们会在启动时间获得一个随机的mac地址(非永久),而且,它将由容器决定连接。
附接
如果你正在运行一个最近的内核,也就是3.8以及3.8版本以上,你可能会用到“lxc-attach”工具。它最基本的特点就是在运行的容器里面给你一个标准的shell:
sudo lxc-attach -n p1
你可能也会从脚本使用它在容器里运行动作,比如:
sudo lxc-attach -n p1 -- restart ssh
但是,它的效率远大于上述,举个例子,比如:
sudo lxc-attach -n p1 -e -s'NETWORK|UTSNAME'
在上述情况下,你会得到一个shell,就是 “root@p1” (thanks toUTSNAME),正在运行“ifconfig -a” ,从这里可以列出一个容器的网络接口清单。输入“e“也意味着cgroup,apparmor,… 从那个shell开启的任意进程都不会被限制。
这有时候对于繁衍一个位于主机上并且在容器里面或者pid域名里面的软件是很有帮助的。
通过设备到一个运行的容器上面
能够按照意愿进入或者脱离一个容器当然是很好的,但是如果能够在你的主机上通过一些随机设备进入,那会是怎么样的?
系统默认设置,LXC将会避免任意的,比如通过运用设备cgroup当成过滤机制作为通道进入。你也可以编辑容器配置来允许额外设备,然后重启容器。
但是有一个只提一次的事情,就是这里也有一个非常方便的工具叫“lxc-device”,有了它,你就只需要做:
sudo lxc-device add -n p1 /dev/ttyUSB0/dev/ttyS0
这个命令会添加 (mknod) /dev/ttyS0,以及同类型的/major/minor as /dev/ttyUSB0 到容器里,然后添加相匹配的cgroup入口来允许从容器进入。
同样,这个容器也允许从主机移动网络设备到容器里面。