這是 LXD 2.0 系列介紹文章的第一篇。
關於 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 譯者：ezio 校對：PurlingNayuki
