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-networkdsystemd-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 语言编写网络流信息的过滤器,然后把过滤得到的信息聚合在一起,进行统计分析。你可以把它视为 wiresharktcpdump 的高级版本,尤其是支持容器。

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 (翻译:柳泉波)

0 个评论

要回复文章请先登录注册