标签容器下的文章

系统管理员的容器时代之殇

'Erich Schubert ' 发布于 2015-04-24
另请参阅: 观点,容器, Docker, 系统管理员
4 条评论

系统管理现在处于一个癫狂的时代，一片混乱。

我并不是抱怨老式系统管理员们，他们还是知道如何让系统工作起来，知道怎么更新系统和如何升级扩容。

这篇吐槽是关于容器、预构建虚拟机镜像的，它们真是令人难以置信的混乱，它们的脑子里面就根本没有“可信”和“升级”的概念。

（题图来自 crtdot.com）

举个 Hadoop 的例子，似乎就没有人知道如何从头构建一份 Hadoop，它那令人头昏眼花的依赖关系、版本需求和构建工具让人云山雾罩。所有这些“神奇”的工具仍然是通过传统的 make 命令构建的，每个工具都是它自己带的，彼此不兼容，你得按照没有复用意义的“当日路线图”来构建。因为没有人能从头构建，所以现在大家都从一些不定是哪个的网站去下载已经编译好的二进制，基本上没有任何认证和签名。

这是 NSA 和病毒们的天堂啊！不需要搞什么破解和漏洞挖掘，只需要弄个“APP”、虚拟机或 Docker 镜像，人们就会把这些恶意代码弄到他们的网络里面去。

Debian 的 Hadoop 维基页就是一个典型的例子，基本上，从 2010 年开始人们就已经放弃了从源代码构建一个 Debian 上可用的 Hadoop 包了。

要构建 Apache Bigtop，你首先需要安装 puppet3，然后用它从互联网上下载一些魔法般数据。以 sudo 的权限启动 puppet ，顺便给 NSA 开个后门（举个例子，它会下载和安装一个过期的预编译的 JDK——因为它认为你太笨了，不会安装 Java），然后期待它能顺利构建而不是抛出200行的毫无用处的报错跟踪。

我没有开玩笑，它会试着执行像下面这样的脚本：

/bin/bash -c "wget http://www.scala-lang.org/files/archive/scala-2.10.3.deb ; dpkg -x ./scala-2.10.3.deb /"

注意，甚至这并没有正常的安装这个包，而只是将其解压缩到你的根目录下！下载时也没有检查任何签名、没有通过 SSL（脚本来自 Bigtop 的 puppet 清单）。

即便你的构建正常工作了，它也会通过 Maven 下载来自互联网的没有签名的二进制代码，并用这些来构建。

不再写一些干净的、模块化的架构，所有这些现在都牵扯在混乱的依赖里面。我上次看到， hadoop 的类路径已经有 100 多个 jar 了，现在？我打赌它肯定有 150 个了。那些 HBaseGiraphFlumeCrunchPigHiveMahoutSolrSparkElasticsearch 以及 Apache 家族的其它东东都是这样混乱。

所谓软件栈，现在的意思是“我也不知道我实际上用的是啥”。

Maven 、ivy 和 sbt 这些即用的工具其实就是让你的系统从互联网下载那些无签名的二进制数据并运行在你的计算机上。

再加上容器，哦天哪，更乱了。

是否想过给容器进行安全更新？

基本上，Docker 的思路就是下载一个未签名的二进制并运行它，然后期望它不要将任何后门放到你的公司网络里面去。

这就像是我在90年代时在 Windows 上下载的共享软件一样。什么时候会出现第一个带有 Ask 工具条的 Docker 镜像呢？第一个通过 Docker 镜像传播的互联网蠕虫呢？

回到前些年，Linux 发行版努力着提供一个安全的操作系统，带有签名的软件包、可信的网络、甚至还能完全的重新构建。

而现在呢？什么东西都已经 Windows 化了，到处是疯狂的“App”，你下载，你运行，根本不管是否安全，是否能升级到下个版本。因为你就是“过把瘾就死”！

更新：其实在 Docker 之前就有这样的作法了，Docker 只是一个新的 'curl | sudo bash' 而已。是的，这就是主流的、在你的数据中心下载并运行一个不可信软件的方法。这太糟糕了，真的。之前，系统管理员还在努力的防御安全漏洞，现在，他们自称“devops”了，然后很 happy 地把这些东西弄到他们的网络里面了！

教你在 Ubuntu 上使用 LXC 容器

Dan Nanni 发布于 2014-11-27
另请参阅: 容器与云,LXC, 容器, Docker
4 条评论

使用“容器”来保证主机环境的安全性，这个概念早在十年前就已经存在（例如 FreeBSD 的 jail 虚拟化技术），但是直到最近，随着部署云架构需求越来越多，像 LXC 和 Docker 这种 Linux 下的容器才成为被关注的焦点。当然，由于主流厂商（云服务商如亚马逊主推 AWS，微软主推 Azure；发行版如红帽、Ubuntu等）组成的强大靠山，Docker 已经被放在媒体的聚光灯下面，其实，Docker 里面所谓的“容器”技术是由 LXC 提供的。

你只是一个普通的 Linux 用户，那 Docker/LXC 能为你带来什么好处呢？容器可以将你的应用在不同的 Linux 发行版之间迁移。想像一下这个场景：你正在用的发行版是 Debian，你喜欢它的稳定性，同时你又想玩一款最新的 Ubuntu 游戏，你不需要在电脑上装双系统然后重启进入 Ubuntu，也不需要在 Debian 上跑一个耗资源的 Ubuntu 虚拟机，你只需要简单地生成一个 Ubuntu 容器就够了。

抛开 Docker 的好处不谈，让我们聊一下 LXC 容器的好处：我可以使用 libvirt 提供的接口来管理 LXC，这些接口和 Docker 没有任何关系。如果你有使用基于 libvirt 库的管理工具（例如 virt-manager 和 virsh），你就可以使用它们来管理 LXC 容器。

在这篇教程中，我只介绍标准 LXC 容器管理工具的命令行操作，来教你如何在 Ubuntu 下创建和管理 LXC 容器。

Ubuntu 下安装 LXC

使用下面的命令安装 LXC 在用户态的工具：

$ sudo apt-get install lxc

然后检查当前内核是否支持 LXC。如果所有结果都是“enable”，说明内核支持：

$ lxc-checkconfig

安装完 LXC 工具后，就能看到 LXC 自动创建了一块桥接网卡（lxcbr0，可以在 /etc/lxc/default.conf 中设置）。

当你创建了 LXC 容器后，它的网口会自动链接到这个桥接网卡上，然后这个容器就能和外部世界通信了。

创建 LXC 容器

为了在指定环境下（比如 Debian Wheezy 64位）创建 LXC 容器，你需要一个相应的 LXC 模板。幸运的是 LXC 提供的工具集成了一整套现成的 LXC 模板，你可以在 /usr/share/lxc/templates 目录下找到它们。

 $ ls /usr/share/lxc/templates

一个 LXC 模板实质上就是一个脚本，用于创建指定环境下的容器。当你创建 LXC 容器时，你需要用到它们。

比如你要新建 Ubuntu 容器，使用下面的命令即可：

$ sudo lxc-create -n <container-name> -t ubuntu

默认情况下，这个命令会创建一个最小的 Ubuntu 环境，版本号与你的宿主机一致，我这边是“活泼的蝾螈”（版本号是13.10），64位。

当然你也可以创建任何你喜欢的版本，只要在命令里面加一个版本参数即可。举个例子，创建 Ubuntu 14.10 的容器：

$ sudo lxc-create -n <container-name> -t ubuntu -- --release utopic

这个命令就会下载安装指定环境下的软件包，创建新容器。整个过程需要几分钟时间，与容器的类型有关，所以，你可能需要耐心等待。

下载安装完所有软件包后，LXC 容器镜像就创建完成了，你可以看到默认的登录界面。容器被放到 /var/lib/lxc/<容器名> 这个目录下，容器的根文件系统放在 /var/lib/lxc/<容器名>/rootfs 目录下。

创建过程中下载的软件包保存在 /var/cache/lxc 目录下面，当你想另外建一个一样的容器时，可以省去很多下载时间。

用下面的命令看看主机上所有的 LXC 容器：

$ sudo lxc-ls --fancy

NAME  STATE    IPV4  IPV6  AUTOSTART  
------------------------------------
test-lxc   STOPPED  -     -     NO

使用下面的命令启动容器。参数“-d”将容器作为后台进程打开。如果没有指定这个参数，你可以在控制台界面上直接把容器的运行程序关闭（LCTT译注：Ctrl+C组合键）。

$ sudo lxc-start -n <container-name> -d

打开容器后，看看状态：

$ sudo lxc-ls --fancy

NAME  STATE    IPV4       IPV6  AUTOSTART  
-----------------------------------------
lxc   RUNNING  10.0.3.55  -     NO

容器状态是“运行中”，容器 IP 是10.0.3.55。

你也可以看到容器的网络接口（比如我这里是 vethJ06SFL）自动与 LXC 内部网桥（lxcbr0）连上了：

$ brctl show lxcbr0

管理 LXC 容器

我们已经学习了怎么创建和启动 LXC 容器，现在来看看怎么玩一个正在运行着的容器。

第一步：打开容器控制台：

$ sudo lxc-console -n <container-name>

使用“Crtl+a q”组合键退出控制台。

停止、删除容器：

$ sudo lxc-stop -n <container-name>
$ sudo lxc-destroy -n <container-name>

复制容器，用下面的命令：

$ sudo lxc-stop -n <container-name>
$ sudo lxc-clone -o <container-name> -n <new-container-name>

常见问题

这个小节主要介绍你们在使用 LXC 过程中碰到过的问题。

创建 LXC 容器时遇到下面的错误：

$ sudo lxc-create -n test-lxc -t ubuntu

lxc-create: symbol lookup error: /usr/lib/x86_64-linux-gnu/liblxc.so.1: undefined symbol: cgmanager_get_pid_cgroup_abs_sync

错误的原因是你运行了最新的 LXC，但是它所依赖的 libcgmanager 版本较老，两者不兼容。升级下 libcmanager 即可解决问题：

$ sudo apt-get install libcgmanager0

via: http://xmodulo.com/lxc-containers-ubuntu.html

作者：Dan Nanni 译者：bazz2 校对：wxy

本文由 LCTT 原创翻译，Linux中国荣誉推出

开源项目Docker，Red Hat新的虚拟化选择

linux中国_ 发布于 2013-10-06
另请参阅: 观点,redhat, Fedora, 容器, Docker, hypervisors
评论

Red Hat与开源项目Docker容器技术开发人员组成合作团队，提供一个虚拟机管理器技术(hypervisors)的替代方案。

Linux发行商Red Hat正与虚拟技术公司dotCloud合作，为Fedora社区Linux项目开发一种新型开源容器技术，名为"Docker"。

当今Linux上的虚拟技术主要包括两类，一类是管理器技术(hypervisors)，例如KVM、Xen，另一类为容器技术(container)，例如 Linux LXC项目(LinuX Containers)。Fedora项目领袖Robyn Bergeron向eWeek介绍说，Red Hat已经将容器技术作为OpenShift PaaS解决方案的一部分，为用户提供应用分离解决方案。

Bergeron补充说尽管Docker与容器类型类似，但是Docker并非Red Hat目前正在使用的容器技术。他说，dotCloud和Red Hat两家都希望Docker能在Red Hat家族的Linux系统中运行。双方的合作目前集中在将Docker作为Fedora协同开源开发环境的一部分。

dotCloud创始人同时也是Docker项目发起人Solomon Hykes说，Docker并不是为了用来替代LXC。

“Docker底层使用了LXC，并整合了其它技术”，Hykes说，“Docker是现有的低层面技术的一个集合，但并非只是简单的将它们叠加在一起。”

Hykes介绍，他们的目标是为DevOps世界带来一种开发者和运维人员都能明白并使用的技术。一个Docker容器包含了运行一个特定进程所必需的所有的二进制文件、库文件和配置文件。

他还说，“我们希望将容器用于应用程序部署，而不只是将其看做微型服务器。”

容器技术 vs. 管理器技术

在企业级服务领域，许多系统管理员如今都熟悉虚拟机管理器技术，例如VMware ESX、Xen和KVM。Hykes认为容器技术正成为管理器技术的互补。

“管理器技术一直以来的处境是，它确实是一门伟大的技术，但是行业内却把它当做一把大斧头并试图用它来完成所有的木匠活”，Hykes认为虚拟机管理器作为一种服务类型，相当于提供了一台裸机的硬件，而与之相对的，容器的工作就是为这台主机提供一系列软件。

Red Hat与Docker

作为Red Hat的开发合作伙伴，Hykes说他们的首要任务是确保Docker能够在Red Hat家族的Linux系统上流畅运行。他承认目前Docker 0.6版在包括Fedora之内的Red Hat家族的Linux系统上运行时还有一些问题。下一个发布版本0.7版将针对这些问题重点改进，确保Red Hat家族Linux系统成为Docker部署环境的“一等公民”。

迄今为止，dotCloud已经为它的Docker项目筹集到了1000万美元风投资金。Hykes补充说Docker目前还并没有一款成形的商用产品，他们的首要目标是建立Docker社区生态环境与基础用户群。

“dotCloud的第一阶段是确保Docker足够的普及程度，同时取得IT界大客户的青睐，”Hykes说，“能够与Red Hat合作对我们来说是一个巨大阶段性胜利。”

via: http://www.eweek.com/developer/red-hat-expands-virtualization-options-with-open-source-docker.html

本文由 LCTT 原创翻译，Linux中国荣誉推出

译者：Mr小眼儿校对：wxy

lmctfy：让我用集装箱为你的程式打包

linux中国_ 发布于 2013-10-04
另请参阅: 技术,lmctfy, LXC, 容器
评论

lmctfy (Let Me Contain That For you，发音是lem-kut-fee)是谷歌Google开发的容器栈，可以为Linux应用提供容器（container）。这些容器可以让一台机器上的不同应用使用相互隔离的资源，以独占的方式运行在同一台机器上。这些应用也可以拥有容器，因此能够创建和管理属于他们自己的子容器。

这项项目旨在提供一组以用户的意图为原点的高级API，来实现对容器概念的抽象化。这些创建的容器自身也通过继承也可以拥有了自己的容器、也能够被其他的用户程序所管理。

Lmctfy是为某些特定的场景（配置环境）设计、实现的，所以可能不能在所有场景（配置环境）中正常运作。我们的目标是为更多的场景（配置环境）提供更多的支持，所以你可以为这项项目贡献你的补丁或是在邮件列表中发送邮件，这样我们可以朝着既定的路线图前进。

lmctfy 内包含一个C++库和一个CLI（命令行界面程序）

从此开始

这一节描述如何编译你的CLI，运行所有的UI测试，和初始化机器的细节。 CLI这节提供了一些CLI操作的例子，C++ 库描述了这个库的使用详情。

依赖

编译本程序需要使用make和g++4.7。 lmcfy使用了C++11，所以需要支持这项功能的编译器。我们在 Ubuntu 12.04+ 上测试过编译。如果有为其他环境的编译提供支持的补丁，我们很高兴而且希望这越多越好。

lmctfy 依赖下列几个库，需要这些库存在于你的计算机系统里。

编译CLI

编译lmctfy的CLI：

make -j <线程数> lmctfy

CLI程序会生成在 bin/lmctfy/cli/lmctfy

编译C++库

编译lmctfy的库：

make -j <线程数> liblmctfy.a

库文件会生成在 bin/liblmctfy.a.

运行测试

编译和运行所有的UI测试：

make -j <线程数> check

初始化

lmctfy已经在 Ubuntu 12.04+ 上的 3.3 和 3.8 内核上测试过。 lmctfy在一台机器的所有容器都是运行它的时候运转得最好，所以不建议让她运行在LXC或者其他container系统上（尽管在某些特殊得配置下这能够跑起来）。

为了运行lmctfy，我们必须首先初始化计算机。这只需要运行一次就可以，而且一般是在计算机第一次启动时候就完成了。当cgroup的hierarchies已经挂载了，接下来通常一个空的配置会可以让lmctfy自动监测到目前的挂载。

lmctfy init ""

如果cgroup的hierarchies没有被挂载，那么必须指明这些资源，这样lmctfy才可以挂载他们。目前版本需要以下cgroup的hierarchies资源cpu，cpuset，cpuacct，memory和freezer。 cpu和cpuacct 是目前唯一可以被共享挂载的，其他的必须被单独地挂载。具体配置说明可以查看lmctfy.proto中的InitSpec节。以下的例子是一个挂载了/dev/cgroup中的所有hierarachies的配置文件：

lmctfy init "
  cgroup_mount:{
    mount_path:'/dev/cgroup/cpu'
    hierarchy:CGROUP_CPU hierarchy:CGROUP_CPUACCT
  }
  cgroup_mount:{
    mount_path:'/dev/cgroup/cpuset' hierarchy:CGROUP_CPUSET
  }
  cgroup_mount:{
    mount_path:'/dev/cgroup/freezer' hierarchy:CGROUP_FREEZER
  }
  cgroup_mount:{
    mount_path:'/dev/cgroup/memory' hierarchy:CGROUP_MEMORY
  }"

这样，机器就可以被lmctfy使用、进行容器的操作。

容器的命名

容器的命名系统简化了文件系统的路径，因为以后只需要一系列容器的继承（容器的容器、子容器、子子容器）就可以了♪───Ｏ（≧∇≦）Ｏ──── ♪。

容器名称允许的字符集：

英文字母＋阿拉伯数字 ([a-zA-Z0-9]+)
下划线 (\_)
横县 (-)
英文句号 (.)

绝对路径是从容器（比如是/sys/subcont）的根目录(/)开始计算的。容器的名字也可以是相对的（比如subcont）。一般地（除非特殊情况说明），都是沿用一般的文件路径方式。

例子

    /         : 容器的根目录
    /sys         : "sys" 容器
    /sys/sub    : "sub" 容器，"sys"容器的子容器
    .         : 当前的容器
    ./         : 当前的容器
    ..         : 当前的容器的父容器
    sub         : 当前的容器的"sub" 子容器
    ./sub     : 当前的容器的"sub" 子容器
    /sub         : "sub" 容器
    ../sibling    : 当前的父容器的“sibling”子容器

CLI

创建

创建一个容器：

lmctfy create <名称> <参数>

更完整的细节参见lmctfy.proto

例子 (创建一个内存限制在100MB的容器)：

lmctfy create memory\_only "memory:{limit:100000000}"

销毁

销毁一个容器：

lmctfy destroy<名称>

列表

从根目录递归显示当前机器的所有容器：

lmctfy list containers -r /

你也可以只列出当前的子容器：

lmctfy list containers

运行

在一台容器中运行命令：

lmctfy run <名称> <命令行>

例子：

lmctfy run test "echo hello world"

lmctfy run /test/sub bash

lmctfy run -n /test "echo hello from a daemon"

其他

键入lmctfy help查看全部的命令和文档

C++ Library

此库包含了::containers::lmctfy::ContainerApi 用来创建、获取、销毁、监测::containers::lmctfy::Container类型的对象，并且被独立的容器相互交流。具体的lmctfy C++库的文档可以查看头文件lmctfy.h（你是认真的吗(￣▽￣)）。

路线图

lmctfy项目通过两个层（CL1、CL2）来实现一个容器栈。CL1围绕着驱动进程，并执行CL2制定的容器策略。CL1会为更高层创建和维护容器的抽象。她应当是唯一直接和内核交流以维护容器的层。 CL2发展和设定容器策略，她使用CL1来执行策略和操控容器。比如，CL2（后台进程）实现了一个策略：所有容器的CPU和内存使用总和不可以超过现提供的CPU和内存资源（以防止对内存资源的过度使用）。为了执行这条策略，她（CL2）会使用CL1（library／CLI）来创建带这条内存限制规则的容器。另一条对应的策略可能包括了允许过度使用X％的机器资源或者对不同资源的多重层次控制。

lmcfty项目现在提供了CL1组件，CL2还没有实现。

CL1

现在只提供高性能CPU和内存隔离。在我们的路线图中我们还需要实现以下几项：

磁盘IO隔离: 这部分几乎完成了，但是我们还缺少控制器和资源处理器。
网络隔离: 这部分和cgroup实现还在计划中。
命名空间支援: 给所有命名空间支援并且整合到相关的资源中。
根文件系统支援: 识别并建立根文件系统。
磁盘镜像: 可以导入和导出容器的根文件系统的镜像。
支持暂停／继续: 使用继承的freezer。
还原点恢复: 可以建立还原点并恢复到不同机器的容器中。

CL2

最基础的CL2 应当有一个容器策略来保证在机器不允许超载运行情况下的资源合理分配。我们的目标是CL2最终实现提供不同层次的服务。在这个框架下一些层次可以比其他的获得更多好的服务。

监控和统计支持。
管理功能和功能检查。
服务的质量保证和执行。

内核支持

lmctfy 最初的设计和实现是在一个自定义的内核上（一个原生linux内核外加一些列自选的补丁）上。由此，一些特性在这些内核补丁上跑得最理想。但是lmctfy应该在没有他们得情况下正常运行。她应当监测可用得内核支援并且与之适应。我们已经在原生的 Ubuntu 的 3.3 和 3.8 系列内核上测试过。如果你发现在其他版本内核下的问题，请汇报。

一些相关的内核补丁：

CPU 延时: 这个补丁为cpu hierarchy增加了cpu.lat的cgroup 文件。她限制了cgroup能预测的CPU唤醒延时时间。
CPU 柱状图统计: 这个补丁为cpuacct hierarchy增加了cpuacct.histogram cgroup 文件。她为CPU计划行为提供了多种柱状图方案。
OOM 管理: 一系列的补丁，用于在内存用尽的情况下执行优先权。

贡献

对项目感到兴趣了？看看我们的路线图，看你是不是由很多想贡献的方向呢？从此开始，你应该可以运行我们的程序。如果无法运行，请让我们知道，这样我们可以改进这份指南。

邮件列表

本项目的邮件列表是[email protected]。本邮件列表用来发布、讨论、一般性支持。

原文: https://github.com/google/lmctfy/

本文由LCTT 原创翻译，Linux中国荣誉推出

译者：Chilledheart 校对：wxy