这是 LXD 2.0 系列介绍文章的第二篇。

1. LXD 入门
2. 安装与配置
3. 你的第一个 LXD 容器
4. 资源控制
5. 镜像管理
6. 远程主机及容器迁移
7. LXD 中的 Docker
8. LXD 中的 LXD
9. 实时迁移
10. LXD 和 Juju
11. LXD 和 OpenStack
12. 调试，及给 LXD 做贡献

安装篇

有很多种办法可以获得 LXD。我们推荐你配合最新版的 LXC 和 Linux 内核使用 LXD，这样就可以享受到它的全部特性。需要注意的是，我们现在也在慢慢的降低对旧版本 Linux 发布版的支持。

Ubuntu 标准版

所有新发布的 LXD 都会在发布几分钟后上传到 Ubuntu 开发版的安装源里。这个安装包然后就会作为 Ubuntu 用户的其他安装包源的种子。

如果使用 Ubuntu 16.04，可以直接安装：

sudo apt install lxd

如果运行的是 Ubuntu 14.04，则可以这样安装：

sudo apt -t trusty-backports install lxd

Ubuntu Core

使用 Ubuntu Core 稳定版的用户可以使用下面的命令安装 LXD：

sudo snappy install lxd.stgraber

Ubuntu 官方 PPA

使用其他 Ubuntu 发布版 —— 比如 Ubuntu 15.10 —— 的用户可以添加下面的 PPA（Personal Package Archive）来安装：

sudo apt-add-repository ppa:ubuntu-lxc/stable
sudo apt update
sudo apt dist-upgrade
sudo apt install lxd

Gentoo

Gentoo 已经有了最新的 LXD 包，你可以直接安装：

sudo emerge --ask lxd

使用源代码安装

如果你曾经编译过 Go 语言的项目，那么从源代码编译 LXD 并不是十分困难。然而注意，你需要 LXC 的开发头文件。为了运行 LXD， 你的发布版需也要使用比较新的内核（最起码是 3.13）、比较新的 LXC （1.1.4 或更高版本）、LXCFS 以及支持用户子 uid/gid 分配的 shadow 文件。

从源代码编译 LXD 的最新教程可以在上游 README里找到。

Ubuntu 上的网络配置

Ubuntu 的安装包会很方便的给你提供一个“lxdbr0”网桥。这个网桥默认是没有配置过的，只提供通过 HTTP 代理的 IPv6 的本地连接。

要配置这个网桥并添加 IPv4 、 IPv6 子网，你可以运行下面的命令：

sudo dpkg-reconfigure -p medium lxd

或者直接通过 LXD 初始化命令一步一步的配置：

sudo lxd init

存储后端

LXD 提供了几种存储后端。在开始使用 LXD 之前，你应该决定将要使用的后端，因为我们不支持在后端之间迁移已经生成的容器。

各个后端特性比较表可以在这里找到。

ZFS

我们的推荐是 ZFS， 因为它能支持 LXD 的全部特性，同时提供最快和最可靠的容器体验。它包括了以容器为单位的磁盘配额、即时快照和恢复、优化后的迁移（发送/接收），以及快速从镜像创建容器的能力。它同时也被认为要比 btrfs 更成熟。

要和 LXD 一起使用 ZFS ，你需要首先在你的系统上安装 ZFS。

如果你是用的是 Ubuntu 16.04 ， 你只需要简单的使用命令安装：

sudo apt install zfsutils-linux

在 Ubuntu 15.10 上你可以这样安装：

sudo apt install zfsutils-linux zfs-dkms

如果是更旧的版本，你需要从 zfsonlinux PPA 安装：

sudo apt-add-repository ppa:zfs-native/stable
sudo apt update
sudo apt install ubuntu-zfs

配置 LXD 只需要执行下面的命令：

sudo lxd init

这条命令接下来会向你提问一些 ZFS 的配置细节，然后为你配置好 ZFS。

btrfs

如果 ZFS 不可用，那么 btrfs 可以提供相同级别的集成，但不能正确地报告容器内的磁盘使用情况（虽然配额仍然可用）。

btrfs 同时拥有很好的嵌套属性，而这是 ZFS 所不具有的。也就是说如果你计划在 LXD 中再使用 LXD，那么 btrfs 就很值得你考虑。

使用 btrfs 的话，LXD 不需要进行任何的配置，你只需要保证 /var/lib/lxd 保存在 btrfs 文件系统中，然后 LXD 就会自动为你使用 btrfs 了。

LVM

如果 ZFS 和 btrfs 都不是你想要的，你还可以考虑使用 LVM 以获得部分特性。 LXD 会以自动精简配置的方式使用 LVM，为每个镜像和容器创建 LV，如果需要的话也会使用 LVM 的快照功能。

要配置 LXD 使用 LVM，需要创建一个 LVM 卷组，然后运行：

lxc config set storage.lvm_vg_name "THE-NAME-OF-YOUR-VG"

默认情况下 LXD 使用 ext4 作为全部逻辑卷的文件系统。如果你喜欢的话可以改成 XFS：

lxc config set storage.lvm_fstype xfs

简单目录

如果上面全部方案你都不打算使用，LXD 依然能在不使用任何高级特性情况下工作。它会为每个容器创建一个目录，然后在创建每个容器时解压缩镜像的压缩包，并在容器拷贝和快照时进行一次完整的文件系统拷贝。

除了磁盘配额以外的特性都是支持的，但是很浪费磁盘空间，并且非常慢。如果你没有其他选择，这还是可以工作的，但是你还是需要认真的考虑一下上面的几个替代方案。

配置篇

LXD 守护进程的完整配置项列表可以在这里找到。

网络配置

默认情况下 LXD 不会监听网络。和它通信的唯一办法是通过 /var/lib/lxd/unix.socket 使用本地 unix 套接字进行通信。

要让 LXD 监听网络，下面有两个有用的命令：

lxc config set core.https_address [::]
lxc config set core.trust_password some-secret-string

第一条命令将 LXD 绑定到 IPv6 地址 “::”，也就是监听机器的所有 IPv6 地址。你可以显式的使用一个特定的 IPv4 或者 IPv6 地址替代默认地址，如果你想绑定某个 TCP 端口（默认是 8443）的话可以在地址后面添加端口号即可。

第二条命令设置了密码，用于让远程客户端把自己添加到 LXD 可信证书中心。如果已经给主机设置了密码，当添加 LXD 主机时会提示输入密码，LXD 守护进程会保存他们的客户端证书以确保客户端是可信的，这样就不需要再次输入密码（可以随时设置和取消）。

你也可以选择不设置密码，而是人工验证每个新客户端是否可信——让每个客户端发送“client.crt”（来自于 ~/.config/lxc）文件，然后把它添加到你自己的可信证书中心：

lxc config trust add client.crt

代理配置

大多数情况下，你会想让 LXD 守护进程从远程服务器上获取镜像。

如果你处在一个必须通过 HTTP(s) 代理链接外网的环境下，你需要对 LXD 做一些配置，或保证已在守护进程的环境中设置正确的 PROXY 环境变量。

lxc config set core.proxy_http http://squid01.internal:3128
lxc config set core.proxy_https http://squid01.internal:3128
lxc config set core.proxy_ignore_hosts image-server.local

以上代码使所有 LXD 发起的数据传输都使用 squid01.internal HTTP 代理，但与在 image-server.local 的服务器的数据传输则是例外。

镜像管理

LXD 使用动态镜像缓存。当从远程镜像创建容器的时候，它会自动把镜像下载到本地镜像商店，同时标志为已缓存并记录来源。几天后（默认 10 天）如果某个镜像没有被使用过，那么它就会自动地被删除。每隔几小时（默认是 6 小时）LXD 还会检查一下这个镜像是否有新版本，然后更新镜像的本地拷贝。

所有这些都可以通过下面的配置选项进行配置：

lxc config set images.remote_cache_expiry 5
lxc config set images.auto_update_interval 24
lxc config set images.auto_update_cached false

这些命令让 LXD 修改了它的默认属性，缓存期替换为 5 天，更新间隔为 24 小时，而且只更新那些标记为自动更新（–auto-update）的镜像（lxc 镜像拷贝被标记为 –auto-update）而不是 LXD 自动缓存的镜像。

总结

到这里为止，你就应该有了一个可以工作的、最新版的 LXD，现在你可以开始用 LXD 了，或者等待我们的下一篇博文，我们会在其中介绍如何创建第一个容器以及使用 LXD 命令行工具操作容器。

额外信息

• LXD 的主站在: https://linuxcontainers.org/lxd
• LXD 的 GitHub 仓库: https://github.com/lxc/lxd
• LXD 的邮件列表: https://lists.linuxcontainers.org
• LXD 的 IRC 频道: #lxcontainers on irc.freenode.net

如果你不想或者不能在你的机器上安装 LXD ，你可以试试在线版的 LXD。

作者简介：我是 Stéphane Graber。我是 LXC 和 LXD 项目的领导者，目前在加拿大魁北克蒙特利尔的家所在的Canonical 有限公司担任 LXD 的技术主管。

via: https://www.stgraber.org/2016/03/15/lxd-2-0-installing-and-configuring-lxd-212/

作者：Stéphane Graber 译者：ezio 校对：PurlingNayuki

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

欢迎来到“Fedora 中的容器技术”系列！本文是该系列文章中的第一篇，它将说明你可以怎样使用 Fedora 中各种可用的容器技术。本文将学习 systemd-nspawn 的相关知识。

容器是什么？

一个容器就是一个用户空间实例，它能够在与托管容器的系统（叫做宿主系统）相隔离的环境中运行一个程序或者一个操作系统。这和 chroot 或 虚拟机 的思想非常类似。运行在容器中的进程是由与宿主操作系统相同的内核来管理的，但它们是与宿主文件系统以及其它进程隔离开的。

什么是 systemd-nspawn？

systemd 项目认为应当将容器技术变成桌面的基础部分，并且应当和用户的其余系统集成在一起。为此，systemd 提供了 systemd-nspawn，这款工具能够使用多种 Linux 技术创建容器。它也提供了一些容器管理工具。

systemd-nspawn 和 chroot 在许多方面都是类似的，但是前者更加强大。它虚拟化了文件系统、进程树以及客户系统中的进程间通信。它的吸引力在于它提供了很多用于管理容器的工具，例如用来管理容器的 machinectl。由 systemd-nspawn 运行的容器将会与 systemd 组件一同运行在宿主系统上。举例来说，一个容器的日志可以输出到宿主系统的日志中。

在 Fedora 24 上，systemd-nspawn 已经从 systemd 软件包分离出来了，所以你需要安装 systemd-container 软件包。一如往常，你可以使用 dnf install systemd-container 进行安装。

创建容器

使用 systemd-nspawn 创建一个容器是很容易的。假设你有一个专门为 Debian 创造的应用，并且无法在其它发行版中正常运行。那并不是一个问题，我们可以创造一个容器！为了设置容器使用最新版本的 Debian（现在是 Jessie），你需要挑选一个目录来放置你的系统。我暂时将使用目录 ~/DebianJessie。

一旦你创建完目录，你需要运行 debootstrap，你可以从 Fedora 仓库中安装它。对于 Debian Jessie，你运行下面的命令来初始化一个 Debian 文件系统。

$ debootstrap --arch=amd64 stable ~/DebianJessie

以上默认你的架构是 x86\_64。如果不是的话，你必须将架构的名称改为 amd64。你可以使用 uname -m 得知你的机器架构。

一旦设置好你的根目录，你就可以使用下面的命令来启动你的容器。

$ systemd-nspawn -bD ~/DebianJessie

容器将会在数秒后准备好并运行，当你试图登录时就会注意到：你无法使用你的系统上任何账户。这是因为 systemd-nspawn 虚拟化了用户。修复的方法很简单：将之前的命令中的 -b 移除即可。你将直接进入容器的 root 用户的 shell。此时，你只能使用 passwd 命令为 root 设置密码，或者使用 adduser 命令添加一个新用户。一旦设置好密码或添加好用户，你就可以把 -b 标志添加回去然后继续了。你会进入到熟悉的登录控制台，然后你使用设置好的认证信息登录进去。

以上对于任意你想在容器中运行的发行版都适用，但前提是你需要使用正确的包管理器创建系统。对于 Fedora，你应使用 DNF 而非 debootstrap。想要设置一个最小化的 Fedora 系统，你可以运行下面的命令，要将“/absolute/path/”替换成任何你希望容器存放的位置。

$ sudo dnf --releasever=24 --installroot=/absolute/path/ install systemd passwd dnf fedora-release

设置网络

如果你尝试启动一个服务，但它绑定了你宿主机正在使用的端口，你将会注意到这个问题：你的容器正在使用和宿主机相同的网络接口。幸运的是，systemd-nspawn 提供了几种可以将网络从宿主机分开的方法。

本地网络

第一种方法是使用 --private-network 标志，它默认仅创建一个回环设备。这对于你不需要使用网络的环境是非常理想的，例如构建系统和其它持续集成系统。

多个网络接口

如果你有多个网络接口设备，你可以使用 --network-interface 标志给容器分配一个接口。想要给我的容器分配 eno1，我会添加选项 --network-interface=eno1。当某个接口分配给一个容器后，宿主机就不能同时使用那个接口了。只有当容器彻底关闭后，宿主机才可以使用那个接口。

共享网络接口

对于我们中那些并没有额外的网络设备的人来说，还有其它方法可以访问容器。一种就是使用 --port 选项。这会将容器中的一个端口定向到宿主机。使用格式是 协议:宿主机端口:容器端口，这里的协议可以是 tcp 或者 udp，宿主机端口 是宿主机的一个合法端口，容器端口 则是容器中的一个合法端口。你可以省略协议，只指定 宿主机端口:容器端口。我通常的用法类似 --port=2222:22。

你可以使用 --network-veth 启用完全的、仅宿主机模式的网络，这会在宿主机和容器之间创建一个虚拟的网络接口。你也可以使用 --network-bridge 桥接二者的连接。

使用 systemd 组件

如果你容器中的系统含有 D-Bus，你可以使用 systemd 提供的实用工具来控制并监视你的容器。基础安装的 Debian 并不包含 dbus。如果你想在 Debian Jessie 中使用 dbus，你需要运行命令 apt install dbus。

machinectl

为了能够轻松地管理容器，systemd 提供了 machinectl 实用工具。使用 machinectl，你可以使用 machinectl login name 登录到一个容器中、使用 machinectl status name检查状态、使用 machinectl reboot name 启动容器或者使用 machinectl poweroff name 关闭容器。

其它 systemd 命令

多数 systemd 命令，例如 journalctl, systemd-analyze 和 systemctl，都支持使用 --machine 选项来指定容器。例如，如果你想查看一个名为 “foobar” 的容器的日志，你可以使用 journalctl --machine=foobar。你也可以使用 systemctl --machine=foobar status service 来查看运行在这个容器中的服务状态。

和 SELinux 一起工作

如果你要使用 SELinux 强制模式（Fedora 默认模式），你需要为你的容器设置 SELinux 环境。想要那样的话，你需要在宿主系统上运行下面两行命令。

$ semanage fcontext -a -t svirt_sandbox_file_t "/path/to/container(/.*)?"
$ restorecon -R /path/to/container/

确保使用你的容器路径替换 “/path/to/container”。对于我的容器 "DebianJessie"，我会运行下面的命令：

$ semanage fcontext -a -t svirt_sandbox_file_t "/home/johnmh/DebianJessie(/.*)?"
$ restorecon -R /home/johnmh/DebianJessie/

via: https://fedoramagazine.org/container-technologies-fedora-systemd-nspawn/

作者：John M. Harris, Jr. 译者：ChrisLeeGit 校对：wxy

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

这是 LXD 2.0 系列介绍文章的第一篇。

1. LXD 入门
2. 安装与配置
3. 你的第一个 LXD 容器
4. 资源控制
5. 镜像管理
6. 远程主机及容器迁移
7. LXD 中的 Docker
8. LXD 中的 LXD
9. 实时迁移
10. LXD 和 Juju
11. LXD 和 OpenStack
12. 调试，及给 LXD 做贡献

关于 LXD 几个常见问题

什么是 LXD ?

简单地说， LXD 就是一个提供了 REST API 的 LXC 容器管理器。

LXD 最主要的目标就是使用 Linux 容器而不是硬件虚拟化向用户提供一种接近虚拟机的使用体验。

LXD 和 Docker/Rkt 又有什么关系呢 ?

这是一个最常被问起的问题，现在就让我们直接指出其中的不同吧。

LXD 聚焦于系统容器，通常也被称为架构容器。这就是说 LXD 容器实际上如在裸机或虚拟机上运行一般运行了一个完整的 Linux 操作系统。

这些容器一般基于一个干净的发布镜像并会长时间运行。传统的配置管理工具和部署工具可以如在虚拟机、云实例和物理机器上一样与 LXD 一起使用。

相对的， Docker 关注于短期的、无状态的、最小化的容器，这些容器通常并不会升级或者重新配置，而是作为一个整体被替换掉。这就使得 Docker 及类似项目更像是一种软件发布机制，而不是一个机器管理工具。

这两种模型并不是完全互斥的。你完全可以使用 LXD 为你的用户提供一个完整的 Linux 系统，然后他们可以在 LXD 内安装 Docker 来运行他们想要的软件。

为什么要用 LXD?

我们已经持续开发并改进 LXC 好几年了。 LXC 成功的实现了它的目标，它提供了一系列很棒的用于创建和管理容器的底层工具和库。

然而这些底层工具的使用界面对用户并不是很友好。使用它们需要用户有很多的基础知识以理解它们的工作方式和目的。同时，向后兼容旧的容器和部署策略也使得 LXC 无法默认使用一些安全特性，这导致用户需要进行更多人工操作来实现本可以自动完成的工作。

我们把 LXD 作为解决这些缺陷的一个很好的机会。作为一个长时间运行的守护进程， LXD 可以绕开 LXC 的许多限制，比如动态资源限制、无法进行容器迁移和高效的在线迁移；同时，它也为创造新的默认体验提供了机会：默认开启安全特性，对用户更加友好。

LXD 的主要组件

LXD 是由几个主要组件构成的，这些组件都出现在 LXD 目录结构、命令行客户端和 API 结构体里。

容器

LXD 中的容器包括以下及部分：

• 根文件系统（rootfs）
• 配置选项列表，包括资源限制、环境、安全选项等等
• 设备：包括磁盘、unix 字符/块设备、网络接口
• 一组继承而来的容器配置文件
• 属性（容器架构、暂时的还是持久的、容器名）
• 运行时状态（当用 CRIU 来中断/恢复时）

快照

容器快照和容器是一回事，只不过快照是不可修改的，只能被重命名，销毁或者用来恢复系统，但是无论如何都不能被修改。

值得注意的是，因为我们允许用户保存容器的运行时状态，这就有效的为我们提供了“有状态”的快照的功能。这就是说我们可以使用快照回滚容器的状态，包括快照当时的 CPU 和内存状态。

镜像

LXD 是基于镜像实现的，所有的 LXD 容器都是来自于镜像。容器镜像通常是一些纯净的 Linux 发行版的镜像，类似于你们在虚拟机和云实例上使用的镜像。

所以可以「发布」一个容器：使用容器制作一个镜像并在本地或者远程 LXD 主机上使用。

镜像通常使用全部或部分 sha256 哈希码来区分。因为输入长长的哈希码对用户来说不方便，所以镜像可以使用几个自身的属性来区分，这就使得用户在镜像商店里方便搜索镜像。也可以使用别名来一对一地将一个用户好记的名字映射到某个镜像的哈希码上。

LXD 安装时已经配置好了三个远程镜像服务器（参见下面的远程一节）：

• “ubuntu”：提供稳定版的 Ubuntu 镜像
• “ubuntu-daily”：提供 Ubuntu 的每日构建镜像
• “images”： 社区维护的镜像服务器，提供一系列的其它 Linux 发布版，使用的是上游 LXC 的模板

LXD 守护进程会从镜像上次被使用开始自动缓存远程镜像一段时间（默认是 10 天），超过时限后这些镜像才会失效。

此外， LXD 还会自动更新远程镜像（除非指明不更新），所以本地的镜像会一直是最新版的。

配置

配置文件是一种在一个地方定义容器配置和容器设备，然后将其应用到一系列容器的方法。

一个容器可以被应用多个配置文件。当构建最终容器配置时（即通常的扩展配置），这些配置文件都会按照他们定义顺序被应用到容器上，当有重名的配置键或设备时，新的会覆盖掉旧的。然后本地容器设置会在这些基础上应用，覆盖所有来自配置文件的选项。

LXD 自带两种预配置的配置文件：

• “default”配置是自动应用在所有容器之上，除非用户提供了一系列替代的配置文件。目前这个配置文件只做一件事，为容器定义 eth0 网络设备。
• “docker”配置是一个允许你在容器里运行 Docker 容器的配置文件。它会要求 LXD 加载一些需要的内核模块以支持容器嵌套并创建一些设备。

远程

如我之前提到的， LXD 是一个基于网络的守护进程。附带的命令行客户端可以与多个远程 LXD 服务器、镜像服务器通信。

默认情况下，我们的命令行客户端会与下面几个预定义的远程服务器通信：

• local：默认的远程服务器，使用 UNIX socket 和本地的 LXD 守护进程通信
• ubuntu：Ubuntu 镜像服务器，提供稳定版的 Ubuntu 镜像
• ubuntu-daily：Ubuntu 镜像服务器，提供 Ubuntu 的每日构建版
• images：images.linuxcontainers.org 的镜像服务器

所有这些远程服务器的组合都可以在命令行客户端里使用。

你也可以添加任意数量的远程 LXD 主机，并配置它们监听网络。匿名的开放镜像服务器，或者通过认证可以管理远程容器的镜像服务器，都可以添加进来。

正是这种远程机制使得与远程镜像服务器交互及在主机间复制、移动容器成为可能。

安全性

我们设计 LXD 时的一个核心要求，就是在不修改现代 Linux 发行版的前提下，使容器尽可能的安全。

LXD 通过使用 LXC 库实现的主要安全特性有：

• 内核名字空间。尤其是用户名字空间，它让容器和系统剩余部分完全分离。LXD 默认使用用户名字空间（和 LXC 相反），并允许用户在需要的时候以容器为单位关闭（将容器标为“特权的”）。
• Seccomp 系统调用。用来隔离潜在危险的系统调用。
• AppArmor。对 mount、socket、ptrace 和文件访问提供额外的限制。特别是限制跨容器通信。
• Capabilities。阻止容器加载内核模块，修改主机系统时间，等等。
• CGroups。限制资源使用，防止针对主机的 DoS 攻击。

为了对用户友好，LXD 构建了一个新的配置语言把大部分的这些特性都抽象封装起来，而不是如 LXC 一般直接将这些特性暴露出来。举了例子，一个用户可以告诉 LXD 把主机设备放进容器而不需要手动检查他们的主/次设备号来手动更新 CGroup 策略。

和 LXD 本身通信是基于使用 TLS 1.2 保护的链路，只允许使用有限的几个被允许的密钥算法。当和那些经过系统证书认证之外的主机通信时， LXD 会提示用户验证主机的远程指纹（SSH 方式），然后把指纹缓存起来以供以后使用。

REST 接口

LXD 的工作都是通过 REST 接口实现的。在客户端和守护进程之间并没有其他的通讯渠道。

REST 接口可以通过本地的 unix socket 访问，这只需要经过用户组认证，或者经过 HTTP 套接字使用客户端认证进行通信。

REST 接口的结构能够和上文所说的不同的组件匹配，是一种简单、直观的使用方法。

当需要一种复杂的通信机制时， LXD 将会进行 websocket 协商完成剩余的通信工作。这主要用于交互式终端会话、容器迁移和事件通知。

LXD 2.0 附带了 1.0 版的稳定 API。虽然我们在 1.0 版 API 添加了额外的特性，但是这不会在 1.0 版 API 端点里破坏向后兼容性，因为我们会声明额外的 API 扩展使得客户端可以找到新的接口。

容器规模化

虽然 LXD 提供了一个很好的命令行客户端，但是这个客户端并不能管理多个主机上大量的容器。在这种使用情况下，我们可以使用 OpenStack 的 nova-lxd 插件，它可以使 OpenStack 像使用虚拟机一样使用 LXD 容器。

这就允许在大量的主机上部署大量的 LXD 容器，然后使用 OpenStack 的 API 来管理网络、存储以及负载均衡。

额外信息

LXD 的主站在: https://linuxcontainers.org/lxd

LXD 的 GitHub 仓库: https://github.com/lxc/lxd

LXD 的邮件列表: https://lists.linuxcontainers.org

LXD 的 IRC 频道: #lxcontainers on irc.freenode.net

如果你不想或者不能在你的机器上安装 LXD ，你可以在 web 上试试在线版的 LXD 。

作者简介：我是 Stéphane Graber。我是 LXC 和 LXD 项目的领导者，目前在加拿大魁北克蒙特利尔的家所在的Canonical 有限公司担任 LXD 的技术主管。

via: https://www.stgraber.org/2016/03/11/lxd-2-0-introduction-to-lxd-112/

作者：Stéphane Graber 译者：ezio 校对：PurlingNayuki

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

在我的上一篇文章里， 我介绍了 Linux 容器背后的技术的概念。我写了我知道的一切。容器对我来说也是比较新的概念。我写这篇文章的目的就是鼓励我真正的来学习这些东西。

我打算在使用中学习。首先实践，然后上手并记录下我是怎么走过来的。我假设这里肯定有很多像 "Hello World" 这种类型的知识帮助我快速的掌握基础。然后我能够更进一步，构建一个微服务容器或者其它东西。

我想，它应该不会有多难的。

但是我错了。

可能对某些人来说这很简单，因为他们在运维工作方面付出了大量的时间。但是对我来说实际上是很困难的，可以从我在Facebook 上的状态展示出来的挫折感就可以看出了。

但是还有一个好消息：我最终搞定了。而且它工作的还不错。所以我准备分享向你分享我如何制作我的第一个微服务容器。我的痛苦可能会节省你不少时间呢。

如果你曾经发现你也处于过这种境地，不要害怕：像我这样的人都能搞定，所以你也肯定行。

让我们开始吧。

一个缩略图微服务

我设计的微服务在理论上很简单。以 JPG 或者 PNG 格式在 HTTP 终端发布一张数字照片，然后获得一个100像素宽的缩略图。

下面是它的流程：

我决定使用 NodeJS 作为我的开发语言，使用 ImageMagick 来转换缩略图。

我的服务的第一版的逻辑如下所示：

我下载了 Docker Toolbox，用它安装了 Docker 的快速启动终端（Docker Quickstart Terminal）。Docker 快速启动终端使得创建容器更简单了。终端会启动一个装好了 Docker 的 Linux 虚拟机，它允许你在一个终端里运行 Docker 命令。

虽然在我的例子里，我的操作系统是 Mac OS X。但是 Windows 下也有相同的工具。

我准备使用 Docker 快速启动终端里为我的微服务创建一个容器镜像，然后从这个镜像运行容器。

Docker 快速启动终端就运行在你使用的普通终端里，就像这样：

第一个小问题和第一个大问题

我用 NodeJS 和 ImageMagick 瞎搞了一通，然后让我的服务在本地运行起来了。

然后我创建了 Dockerfile，这是 Docker 用来构建容器的配置脚本。（我会在后面深入介绍构建过程和 Dockerfile）

这是我运行 Docker 快速启动终端的命令：

$ docker build -t thumbnailer:0.1

获得如下回应：

docker: "build" requires 1 argument.

呃。

我估摸着过了15分钟我才反应过来：我忘记了在末尾参数输入一个点.。

正确的指令应该是这样的：

$ docker build -t thumbnailer:0.1 .

但是这不是我遇到的最后一个问题。

我让这个镜像构建好了，然后我在 Docker 快速启动终端输入了 run 命令来启动容器，名字叫 thumbnailer:0.1:

$ docker run -d -p 3001:3000 thumbnailer:0.1

参数 -p 3001:3000 让 NodeJS 微服务在 Docker 内运行在端口3000，而绑定在宿主主机上的3001。

到目前看起来都很好，对吧？

错了。事情要马上变糟了。

我通过运行 docker-machine 命令为这个 Docker 快速启动终端里创建的虚拟机指定了 ip 地址：

$ docker-machine ip default

这句话返回了默认虚拟机的 IP 地址，它运行在 Docker 快速启动终端里。在我这里，这个 ip 地址是 192.168.99.100。

我浏览网页 http://192.168.99.100:3001/ ，然后找到了我创建的上传图片的网页：

我选择了一个文件，然后点击上传图片的按钮。

但是它并没有工作。

终端告诉我他无法找到我的微服务需要的 /upload 目录。

现在，你要知道，我已经在此耗费了将近一天的时间－从浪费时间到研究问题。我此时感到了一些挫折感。

然后灵光一闪。某人记起来微服务不应该自己做任何数据持久化的工作！保存数据应该是另一个服务的工作。

所以容器找不到目录 /upload 的原因到底是什么？这个问题的根本就是我的微服务在基础设计上就有问题。

让我们看看另一幅图：

我为什么要把文件保存到磁盘？微服务按理来说是很快的。为什么不能让我的全部工作都在内存里完成？使用内存缓冲可以解决“找不到目录”这个问题，而且可以提高我的应用的性能。

这就是我现在所做的。下面是我的计划：

这是我用 NodeJS 写的在内存运行、生成缩略图的代码：

// Bind to the packages
var express = require('express');
var router = express.Router();
var path = require('path'); // used for file path
var im = require("imagemagick");

// Simple get that allows you test that you can access the thumbnail process
router.get('/', function (req, res, next) {
 res.status(200).send('Thumbnailer processor is up and running');
});

// This is the POST handler. It will take the uploaded file and make a thumbnail from the 
// submitted byte array. I know, it's not rocket science, but it serves a purpose
router.post('/', function (req, res, next) {
 req.pipe(req.busboy);
 req.busboy.on('file', function (fieldname, file, filename) {
   var ext = path.extname(filename)

   // Make sure that only png and jpg is allowed 
   if(ext.toLowerCase() != '.jpg' && ext.toLowerCase() != '.png'){
     res.status(406).send("Service accepts only jpg or png files");
   }

   var bytes = [];

   // put the bytes from the request into a byte array 
   file.on('data', function(data) {
     for (var i = 0; i < data.length; ++i) {
       bytes.push(data[i]);
     }
     console.log('File [' + fieldname + '] got bytes ' + bytes.length + ' bytes');
   });

   // Once the request is finished pushing the file bytes into the array, put the bytes in 
   // a buffer and process that buffer with the imagemagick resize function
   file.on('end', function() {
     var buffer = new Buffer(bytes,'binary');
     console.log('Bytes  got ' + bytes.length + ' bytes');

     //resize
     im.resize({
         srcData: buffer,
         height: 100
     }, function(err, stdout, stderr){
       if (err){
         throw err;
       }
       // get the extension without the period
       var typ = path.extname(filename).replace('.','');
       res.setHeader("content-type", "image/" + typ);
       res.status(200);
       // send the image back as a response
       res.send(new Buffer(stdout,'binary'));
     });
   });
 });
});

module.exports = router;

好了，一切回到了正轨，已经可以在我的本地机器正常工作了。我该去休息了。

但是，在我测试把这个微服务当作一个普通的 Node 应用运行在本地时...

它工作的很好。现在我要做的就是让它在容器里面工作。

第二天我起床后喝点咖啡，然后创建一个镜像——这次没有忘记那个"."!

$ docker build -t thumbnailer:01 .

我从缩略图项目的根目录开始构建。构建命令使用了根目录下的 Dockerfile。它是这样工作的：把 Dockerfile 放到你想构建镜像的地方，然后系统就默认使用这个 Dockerfile。

下面是我使用的Dockerfile 的内容：

FROM ubuntu:latest
MAINTAINER [email protected]

RUN apt-get update
RUN apt-get install -y nodejs nodejs-legacy npm
RUN apt-get install imagemagick libmagickcore-dev libmagickwand-dev
RUN apt-get clean

COPY ./package.json src/

RUN cd src && npm install

COPY . /src

WORKDIR src/

CMD npm start

这怎么可能出错呢？

第二个大问题

我运行了 build 命令，然后出了这个错：

Do you want to continue? [Y/n] Abort.

The command '/bin/sh -c apt-get install imagemagick libmagickcore-dev libmagickwand-dev' returned a non-zero code: 1

我猜测微服务出错了。我回到本地机器，从本机启动微服务，然后试着上传文件。

然后我从 NodeJS 获得了这个错误：

Error: spawn convert ENOENT

怎么回事？之前还是好好的啊！

我搜索了我能想到的所有的错误原因。差不多4个小时后，我想：为什么不重启一下机器呢？

重启了，你猜猜结果？错误消失了！（LCTT 译注：万能的“重启试试”）

继续。

将精灵关进瓶子里

跳回正题：我需要完成构建工作。

我使用 rm 命令删除了虚拟机里所有的容器。

$ docker rm -f $(docker ps -a -q)

-f 在这里的用处是强制删除运行中的镜像。

然后删除了全部 Docker 镜像，用的是命令 rmi:

$ docker rmi if $(docker images | tail -n +2 | awk '{print $3}')

我重新执行了重新构建镜像、安装容器、运行微服务的整个过程。然后过了一个充满自我怀疑和沮丧的一个小时，我告诉我自己：这个错误可能不是微服务的原因。

所以我重新看到了这个错误：

Do you want to continue? [Y/n] Abort.

The command '/bin/sh -c apt-get install imagemagick libmagickcore-dev libmagickwand-dev' returned a non-zero code: 1

这太打击我了：构建脚本好像需要有人从键盘输入 Y！ 但是，这是一个非交互的 Dockerfile 脚本啊。这里并没有键盘。

回到 Dockerfile，脚本原来是这样的：

RUN apt-get update
RUN apt-get install -y nodejs nodejs-legacy npm
RUN apt-get install imagemagick libmagickcore-dev libmagickwand-dev
RUN apt-get clean

第二个apt-get 忘记了-y 标志，它用于自动应答提示所需要的“yes”。这才是错误的根本原因。

我在这条命令后面添加了-y ：

RUN apt-get update
RUN apt-get install -y nodejs nodejs-legacy npm
RUN apt-get install -y imagemagick libmagickcore-dev libmagickwand-dev
RUN apt-get clean

猜一猜结果：经过将近两天的尝试和痛苦，容器终于正常工作了！整整两天啊！

我完成了构建工作：

$ docker build -t thumbnailer:0.1 .

启动了容器：

$ docker run -d -p 3001:3000 thumbnailer:0.1

获取了虚拟机的IP 地址：

$ docker-machine ip default

在我的浏览器里面输入 http://192.168.99.100:3001/ ：

上传页面打开了。

我选择了一个图片，然后得到了这个：

工作了！

在容器里面工作了，我的第一次啊！

这让我学到了什么?

很久以前，我接受了这样一个道理：当你刚开始尝试某项技术时，即使是最简单的事情也会变得很困难。因此，我不会把自己当成最聪明的那个人，然而最近几天尝试容器的过程就是一个充满自我怀疑的旅程。

但是你想知道一些其它的事情吗？这篇文章是我在凌晨2点完成的，而每一个受折磨的时刻都值得了。为什么？因为这段时间你将自己全身心投入了喜欢的工作里。这件事很难，对于所有人来说都不是很容易就获得结果的。但是不要忘记：你在学习技术，运行世界的技术。

P.S. 了解一下Hello World 容器的两段视频，这里会有 Raziel Tabib’s 的精彩工作内容。

千万被忘记第二部分...

via: https://deis.com/blog/2015/beyond-hello-world-containers-hard-stuff

作者：Bob Reselman 译者：Ezio 校对：wxy

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

Canonical 的 Stéphane Graber 宣布了一个重大新闻，支持 Ubuntu 的下一代的容器技术 LXD 发布了 2.0。

经过了最后三个月的紧锣密鼓的开发，经历了4个 Beta 版本、至少构建了9个 RC 版本，终于从上一个版本 LXD 0.27 升级到 2.0 版本。这是一个长期支持版本，可以用于产品环境中。

“经过了 LXD 团队的一年半的开发，LXD 2.0 终于发布了！LXD 2.0 是我们的第一个产品级发布，也是一个长期支持版本，直到 2021年6月1号之前，我们都会为它发布修正。”Canonical 的 LXD 技术负责人 Stéphane Graber 说道。

LXD 2.0 亮点

值得关注的 LXD 2.0 的亮点包括，支持块 I/O 限制；支持网络 I/O 限制；优化了 Btrfs 后端上的容器传输；在“lxc list”和“lxc image list”命令中可以使用正则表达式进行过滤；重新打造了 REST API；废弃了对 Go 1.5 及更老版本的支持；“lxc list”命令支持新模式“--fast”。

此外，“lxc info”命令现在可以列出容器架构；支持 Cgroup 名字空间，这样就可以在 LXD 容器中运行 Docker 镜像了；导入镜像时显示上载进度；支持递归 绑定挂载 （ bind-mounts ） ；完全移除了 lxd-images 脚本。

LXD 2.0 现在已经出现在了 Ubuntu 14.04 的软件仓库中，它也会出现在即将发布的 Ubuntu 16.04 中的 Ubuntu Core Store 中。你可以从其官网下载 LXD 2.0 的源代码，可以参考这份安装指南进行安装。更多的介绍，可以阅读这份正在连载的系列文章。

如果你不想在你的本地机器或虚拟机中安装尝试，可以在线体验一番： https://linuxcontainers.org/lxd/try-it 。

相关资源

• 官网： https://linuxcontainers.org/lxd/
• 发布公告：https://linuxcontainers.org/lxd/news/
• 代码：https://github.com/lxc/lxd
• IRC 通道：#lxcontainers on irc.freenode.net
• 邮件列表：https://lists.linuxcontainers.org

Linux 容器是一个在单一 Linux 主机上提供多个隔离的 Linux 环境的操作系统级虚拟技术。不像虚拟机（VM），容器并不需要运行专用的 访客 （ guest ） 操作系统。容器们共享 宿主机的 （ host ） 操作系统内核，并使用访客操作系统的系统库来提供所需的功能。由于不需要专用的操作系统，因此容器要比虚拟器启动快得多。

（图片来自: Docker Inc.）

容器借助 Linux 内核的 Namespaces、Apparmor、SELinux 情景模式 （ profile ） 、chroot 和 CGroup 等功能来提供类似于虚拟机的隔离环境。Linux 的安全模块可以确保正确地控制容器对宿主机和内核的访问，从而避免各种入侵活动。此外，在宿主机上可以运行不同的 Linux 发行版，只要它们运行在同样的 CPU 架构下。

简单来说，容器提供的是一种基于各种 Linux 发行版创建容器镜像的方法、一套管理容器生命周期的 API、与该 API 交互的客户端工具、保存快照的功能、在宿主机之间迁移容器实例的能力，等等。

容器历史

以下是容器简史，内容来自维基百科及其它来源：

1979 — chroot

容器的概念始于 1979 年的 UNIX chroot，它是一个 UNIX 操作系统上的系统调用，用于将一个进程及其子进程的根目录改变到文件系统中的一个新位置，让这些进程只能访问到该目录。这个功能的想法是为每个进程提供独立的磁盘空间。其后在 1982年，它被加入到了 BSD 系统中。

2000 — FreeBSD Jails

FreeBSD Jails 是最早的容器技术之一，它由 R&D Associates 公司的 Derrick T. Woolworth 在 2000 年为 FreeBSD 引入。这是一个类似 chroot 的操作系统级的系统调用，但是为文件系统、用户、网络等的隔离增加了进程沙盒功能。因此，它可以为每个 jail 指定 IP 地址、可以对软件的安装和配置进行定制，等等。

2001 — Linux VServer

Linux VServer 是另外一种 jail 机制，它用于对计算机系统上的资源（如文件系统、CPU 处理时间、网络地址和内存等）进行安全地划分。每个所划分的分区叫做一个 安全上下文 （ security context ） ，在其中的虚拟系统叫做 虚拟私有服务器 （ virtual private server，VPS ） 。

2004 — Solaris Containers

Solaris Containers 支持在 x86 和 SPARC 系统，首次出现在 2004 年 2 月发布的 Solaris 10 的 build 51 beta 上，其后完整发布在 2005 年的 Solaris 10 上。 Solaris Container 是由系统资源控制和通过 zones 提供的 边界分离 （ boundary separation ） 所组合而成的。zones 是一个单一操作系统实例中的完全隔离的虚拟服务器。

2005 — OpenVZ

OpenVZ 类似于 Solaris Containers，它通过对 Linux 内核进行补丁来提供虚拟化、隔离、资源管理和 状态检查 （ checkpointing ） 。每个 OpenVZ 容器都有一套隔离的文件系统、用户及用户组、进程树、网络、设备和 IPC 对象。

2006 — Process Containers

Process Containers 是由 Google 在 2006 年实现的，用于对一组进程进行限制、记账、隔离资源使用（CPU、内存、磁盘 I/O、网络等）。后来为了避免和 Linux 内核上下文中的“容器”一词混淆而改名为 Control Groups。它被合并到了 2.6.24 内核中。这表明 Google 很早就参与了容器技术的开发，以及它们是如何回馈到社区的。

2007 — Control Groups

如上面所述，Control Groups （即 cgroups）是由 Google 实现的，并于 2007 年加到了 Linux 内核中。

2008 — LXC

LXC 的意思是 LinuX Containers，它是第一个最完善的 Linux 容器管理器的实现方案，是通过 cgroups 和 Linux 名字空间 （ namespace ） 实现的。LXC 存在于 liblxc 库中，提供了各种编程语言的 API 实现，包括 Python3、Python2、Lua、Go、Ruby 和 Haskell。与其它容器技术不同的是， LXC 可以工作在普通的 Linux 内核上，而不需要增加补丁。现在 LXC project 是由 Canonical 公司赞助并托管的。

2011 — Warden

Warden 是由 CloudFoundry 在 2011 年开发的，开始阶段是使用的 LXC，之后替换为他们自己的实现方案。不像 LXC，Warden 并不紧密耦合到 Linux 上，而是可以工作在任何可以提供隔离环境的操作系统上。它以后台守护进程的方式运行，为容器管理提供了 API。请参考 Warden 文档和这个博客文章了解更多。

2013 — LMCTFY

lmctfy 的意思是“ 让我为你包含 （ Let Me Contain That For You ） ”。这是一个 Google 容器技术的开源版本，提供 Linux 应用容器。Google 启动这个项目旨在提供性能可保证的、高资源利用率的、资源共享的、可超售的、接近零消耗的容器（参考自：lmctfy 演讲稿.pdf)）。现在为 Kubernetes 所用的 cAdvisor 工具就是从 lmctfy 项目的成果开始的。lmctfy 首次发布于 2013 年10月，在 2015 年 Google 决定贡献核心的 lmctfy 概念，并抽象成 libcontainer，因此，lmctfy 现在已经没有活跃的开发了。

lincontainer 项目最初由 Docker 发起，现在已经被移交给了 开放容器基金会 （ Open Container Foundation ） 。

2013 — Docker

Docker) 是到现在为止最流行和使用广泛的容器管理系统。它最初是一个叫做 dotCloud 的 PaaS 服务公司的内部项目，后来该公司改名为 Docker。类似 Warden，Docker 开始阶段使用的也是 LXC ，之后采用自己开发的 libcontainer 替代了它。不像其它的容器平台，Docker 引入了一整个管理容器的生态系统，这包括高效、分层的容器镜像模型、全局和本地的容器注册库、清晰的 REST API、命令行等等。稍后的阶段， Docker 推动实现了一个叫做 Docker Swarm 的容器集群管理方案。

2014 — Rocket

Rocket 是由 CoreOS 所启动的项目，非常类似于 Docker，但是修复了一些 Docker 中发现的问题。CoreOS 说他们的目的是提供一个比 Docker 更严格的安全性和产品需求。更重要的是，它是在一个更加开放的标准 App Container 规范上实现的。在 Rocket 之外，CoreOS 也开发了其它几个可以用于 Docker 和 Kubernetes的容器相关的产品，如：CoreOS 操作系统、etcd 和 flannel。

2016 — Windows Containers

微软 2015 年也在 Windows Server 上为基于 Windows 的应用添加了容器支持，它称之为 Windows Containers。它与 Windows Server 2016 一同发布。通过该实现， Docker 可以原生地在 Windows 上运行 Docker 容器，而不需要启动一个虚拟机来运行 Docker（ Windows 上早期运行 Docker 需要使用 Linux 虚拟机）。

容器的未来

截止到今天（2016年1月），在行业内有一个显著趋势，部署软件应用从虚拟机逐渐移到了容器。其主要的原因是容器相比于虚拟机而言更加灵活和低消耗。Google 已经使用容器技术好多年了，它在 Borg 和 Omega 容器集群管理平台上可以成规模地运行 Google 应用。更重要的是，Google 为容器领域贡献了 cgroups 的实现和参与了 libcontainer 项目。Google 也在过去这些年借助容器在性能、资源利用和整体效率方面取得了巨大收益。最近，一直没有操作系统级的虚拟化技术的微软，也在 Window Server 上迅速采取动作实现了对容器的原生支持。

Docker 、Rocket 以及其它的容器平台并不能以一个单一主机运行在产品环境中，原因是这样面临着单点故障。当一组容器运行在一个单一宿主机时，如果宿主机失效，所有运行在该宿主机上的容器也会失效。要避免这个问题，应该使用容器宿主机集群。Google 借助其在 Borg 中取得的经验，开发了一个叫做 Kubernetes 的开源容器集群管理系统。Docker 也启动了一个叫做 Docker Swarm 的解决方案。目前这些解决方案还都处于相当早期的阶段，也许需要几个月或来年才实现完整的功能集合，才能变得稳定，从而广泛应用于行业内的产品环境中。

微服务 （ Microservices ） 是另一个突破性技术，在软件架构上可以将容器用于部署。微服务并不是一个新东西，只是一个相比标准的 Web 服务超快的轻量级 Web 服务。这是通过将功能单元（也许是一个单一服务或 API 方法）打包到一个服务中，并内嵌其到一个轻量级 Web 服务器软件中实现的。

通过对上面的介绍，我们可以预测接下来几年，容器也许会替代虚拟机，某些情况下也许会全部取代。去年我为一些企业在 POC 层面上实现了基于容器的解决方案。也有人想要在产品环境中尝试它们，这一天也许在容器集群管理系统进一步成熟后很快到来。