CoreOSFest系列之第二篇：Systemd、Go、Calico、Sysdig

本文講的是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