本文讲的是CoreOS Fest 系列之第二篇： Systemd、Go、Calico、Sysdig， 【编者的话】在 CoreOS Fest 第二天的会议中，演讲者展示了多个开源项目和工具，包括 Systemd 和 CoreOS 、 Go 语言和容器、 Calico 项目、 Sysdig 等。

在  CoreOS Fest  的 第一天会议 中，陆续介绍了 CoreOS 的架构、规划和规范。第二天的会议，演讲者展示了多个开源项目和工具，包括 systemd-nspawn 、 Calico 项目和 Sysdig 等。上述项目大多数已经开发了一年有余，但是大部分 CoreOS Fest 的与会者是第一次了解这些项目。

不仅是会议的内容吸引人，更引人注意的是，在过去的一年多时间内，社区开发了大量支持 Linux 容器的新工具。在 Linux 领域，如此快的发展速度，前所未见。在以容器为核心的新型基础设中， systemd 是一个基础组件，它是 Linux 的新型初始化系统，支持容器的开箱即用。

Systemd 和 CoreOS

Red Hat 的 Lennart Poettering 就  Systemd  和 CoreOS 做了演讲，他介绍了集成容器管理功能的 systemd 工具。与其它的初始化系统相比，用 systemd 构建容器更有优势。 systemd 提供了在单机上管理不同容器所需的所有工具。

他首先指出，这次并不是代表 Red Hat 官方的报告。然后，他花了很多时间介绍 Red Hat 的 systemd 团队。这个团队并不是一个产品团队，他说：「我们自认为是一个研究部门，而不是一个产品团队」。

这种表态解释了 systemd 选择某些技术的原因，例如，选择 Btrfs 作为 systemd-nspawn 模板和容器的主要文件系统。「人们都说 btrfs 是一个不稳定的文件系统。但是， btrfs 项目团队正在努力解决该文件系统存在的基础性问题」，他说。而且，在一个不稳定的文件系统上运行容器，这是可以接受的，因为数据被保存在外部的卷上，而不是在容器内（译者注：即没有保存在这个不稳定的文件系统上）。

systemd 包含多个支持容器的守护进程，即  systemd-machined ,  systemd-networkd  和  systemd-resolved  。总的来说，所有的 systemd 进程都兼容容器，因为「更多时候，我们是在容器中而不是裸机上测试 systemd 」。这么做的好处是，不用重启开发用的笔记本电脑，就可以测试 systemd 进程。Poettering 认为集成容器是 Linux 的一项重要特性，他说：「容器应该默认集成到 Linux 操作系统中，就像  Zones  已经成为 Solaris 操作系统的一部分」。

systemd 团队的目标是保持 systemd 中立，不仅支持 rkt 容器，还支持 docker,  libvirt-lxc ,  OpenVZ  等。 systemd 提供了很多与容器相关的功能，它是一个偏底层的工具，不提供复杂的用户界面。像 CoreOS 和 kubernetes  等项目可以调用 systemd 的功能，完成对容器的基本操作。

在 systemd 中，管理容器的主要工具是 systemd-machined 及其命令行工具 machinectl 。有了它，用户能够列出所有的容器，启动和关停容器，甚至交互登录到容器中。 systemd-machined 实际上是容器的注册中心，任何容器都可以注册。 systemd-machined 配合 systemd ，执行  systemd-run -M  ，就能在容器中执行任何命令。 systemd-machined 运行的容器，会出现在  ps  命令的列表或者 GNOME 的系统监控器中。

systemd-nspawn  是一个轻量的容器执行器，它是一个 像 docker 那样能够启动和关停容器的工具 。 为 systemd-nspawn 指定任何包含主引导记录（ MBR ）或者 GUID 分区表的文件系统或者块设备，它就能启动一个容器。如果用户只需要具备基本功能、免配置的容器， systemd-nspawn 是一个很有吸引力的选择。 rkt 底层也是调用 systemd-nspawn 运行容器。

systemd-networkd 是管理网络的 systemd 守护进程，而 systemd-resolved 是解析主机名字的 systemd 守护进程，它们都支持容器。 systemd-networkd 自动启动容器的网络，利用 DHCP 为容器分配内部的网络地址。 systemd-resolved 使用 本地链路多播名字解析（ link-local multicast name resolution, LLMNR ） 系统，为容器提供主机名。 LLMNR 是 Microsoft 发明的自动名字发现系统，初衷是用在客户端应用和移动设备中，但是它也可以用于网络环境中容器之间的彼此发现。

根据 Poettering 的演讲，看起来 systemd 是 Docker 公司的  libcontainer  以及其它容器初始化和管理工具的强力替代。由于大部分 Linux 发行版的最新版都会集成 systemd ，大多数用户将能够立即使用 systemd 。这也能解释为什么容器领域的大多数公司都选择编排作为主攻点，因为 systemd 本身不提供容器编排功能。

Go 语言和容器

CoreOS 公司 CEO Alex Polvi 做主题演讲时宣布 CoreOS 公司将赞助第二届  Gophercon  ——  Go 语言 开发者大会。 有 6 家 Gophercon 赞助商都是容器公司，约占赞助商总数的 1/4 。这是有原因的，无论 CoreOS 公司还是 Docker 公司，它们使用的主要编程语言都是 go 。 Polvi 如此说道：「只有使用 go 语言才能开发出 Etcd 」。

我听的每一个演讲，我到的每一个会议室，人们都在谈论 go 语言，用它写代码。  Etcd ,  fleet ,  Swarm , Kubernetes,  Kurma  等容器工具应用或者服务都是用 Go 语言编写的。 Linux 容器平台的崛起，同样是 Go 语言的崛起。

Go 语言始于 2007 年 Google 公司的一个内部项目，共有 3 个开发者。现在， go 语言项目的贡献者已经超过 500 人。 Go 是一个使用 BSD 许可的开源项目，但是仍然由 Google 公司把持，所有的贡献者都需要与 Google 公司签署贡献者许可协议（ Contributor License Agreement, CLA ）。 Go 逐渐成为实现可扩展基础设施的「自动化语言」。之前， 人们已经普遍使用 go 语言实现网络代理、云服务器管理工具、分布式搜索引擎和冗余数据存储。很自然地，人们继续选择 go 实现容器工具应用。

由于 CoreOS 与 go 的紧密联系， Brad Fitzpatrick 的报告主题是 go 语言的持续构建基础设施。他是 LiveJournal, memcached 和 OpenID 的开发者，现在是 Google 公司 go 语言团队的一员。他展示了在很多平台上测试 go 语言的自动构建平台。构建平台刚开始时是一个 Google 应用引擎（ Google Application Engine ）应用，加上桌子上一排的移动设备，然后发展成今天这个样子。他还讲述了持续构建基础设施的历史和工作机制。

Go 是一种编译型而不是解释型编程语言。编译得到的二进制程序，能够在多种平台上执行。每个版本的 go 语言在发布之前，首先要在 Google 公司机器实验室拥有的几百种平台上成功地构建。只有在各种 Linux 平台构建 go 语言时才会用到容器，其它很多平台并不支持容器，像 MAC OS X 和 Android 平台就必须使用专用的硬件，因此容器在自动构建平台中的作用比较小。你可以在 这里  看到 go 语言在各个平台的构建结果，哪些成功了，哪些失败了。

Calico 项目

其实  Calico 项目  已经开源差不多一年了。当核心开发者 Spike Curtis 报告时，大多数与会者是第一次听说这个项目。 Calico 是一个多主机路由软件，还包含一个分布式防火墙。 Calico 是专门为容器和虚拟机尤其是 docker 和 OpenStack 环境设计的。  Metaswitch Networks  公司用 python 语言开发 Calico ，它也是唯一提供 Calico 商业化支持的公司。看起来， calico 有望成为这样一种解决方案：用户能够在生产环境部署容器，同时保证严格的安全。

「还记得三层架构吗？」 Curtis 抱怨说，「管理员现在还是这样管理网络。第一层是外部网络，中间是 web 资源所在的隔离区（ demilitarized zone, DMZ），最后是数据层，要求保证最严格的安全」。

编排好网络中的容器，运行微服务，这种模式打破了三层模型。首先，微服务是根据服务的提供者而不是服务的安全特征划分的；其次，编排框架假设数据中心网络是无区分的，也不支持安全分层的概念；最重要的是，你得为几百个微服务定义安全策略和区域，这不像以前，网络管理员只要设定几十个策略和区域就行了。 Curtis 说，「这就像是一个动物园，所有围墙都被推到了」。

然而，就安全而言，微服务也为带来了机会。每个微服务只做一件事情，它的安全需求也相对简单。因此，可以更细致地划分服务，又不增加整体的复杂性， calico 就是这么做的。

Calico 为每个容器或者虚拟机分配一个独立的 IP 地址，然后在每台物理主机上定义包含这些 IP 地址的 iptables 规则，实现了防火墙功能。 Calico 用保存在 etcd 的标签定义每个服务，用一个 JSON 格式的配置文件定义允许访问当前服务的其它服务，以及这个服务是否可通过 Internet 访问。

只要编排框架支持为每个服务分配一个 IP 地址，就可以集成使用 calico 。Curtis 演示了 calico 与 kubernetes 的集成，包括用扩展的 pod 定义来设定每个容器的安全设置。  Apache Mesos  正在实现为每个服务分配一个 IP 地址的功能，暂时还不能集成 calico 。

Sysdig

最后一个「新」项目是  Sysdig  ，就像 calico 项目一样， 它也是一年多以前就发布了，但是大部分与会者都是第一次听说这个项目。站在 sysdig 背后的公司是  Sysdig Cloud  ，它为 sysdig 的用户提供商业化支持。 Sysdig Cloud 公司 CEO Loris Degioanni 展示了这款工具。

Sysdig 是一个网络流监控系统，部分功能实现为一个  Linux 内核模块 。这个模块捕捉了所有的网络流，特别是容器之间的网络包。用户还可以用 Lua 语言编写网络流信息的过滤器，然后把过滤得到的信息聚合在一起，进行统计分析。你可以把它视为  wireshark  和  tcpdump  的高级版本，尤其是支持容器。

Degioanni 说，sysdig 比 Google 的  cAdvisor  项目高明，因为 cAdvisor 只报告容器占用的全部 CPU 、内存和网络，而 sysdig 还能够提供网络流的发送方、接收方和内容。例如，用户可以找出对某个数据库的查询，搞清楚为什么两个 IP 地址之间的网络通信延误得厉害。

Degioanni 还展示了即将发布的 sysdig 的文本用户界面，这是一个基于  curses  的开源项目。有了它，系统管理员能够用 ssh 登录到系统，执行交互的监控任务。他演示了如何深入检查和汇总容器之间的网络通信，还演示了如何调查网络延迟。在 Sysdig Cloud 公司的展台，工作人员演示了商业化产品—— sysdig 的图形界面，用户只需点击多层嵌套的服务器、 pod 和容器，就可以查看对应的网络流。

小结

我从 CoreOS Fest 大会了解了这么多的新项目、新工具、标准草案和新架构，这充分说明 Linux 容器领域发展之快。要知道，在一年前，当我 报道首届 DockerCon  时，这些新技术和新工具，大部分才刚刚发布，有的甚至还不存在。等再过一年，我们看看是不是还发展得这么快。

我们还没有涉及一个主要的话题：如何在容器中持久保存数据。前文曾经提及，目前普遍的看法是容器应该是无状态的，不保存数据。不坚持这一点，容器管理和编排会遇到一系列亟需解决的问题，例如，外部卷的管理、容器迁移和有状态服务的负载均衡等。下个星期，我们将讨论与持久话数据和容器相关的多个话题，内容来自于 CoreOS Fest 和  Container Camp  。

原文链接： New projects from day two of CoreOS Fest （翻译：柳泉波）

原文发布时间为： 2015-06-19

本文作者：bnuhero 

本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。

原文标题：CoreOS Fest 系列之第二篇： Systemd、Go、Calico、Sysdig