Systemd的Unit檔案

在 Systemd 的生態圈中（除了 CoreOS 外，目前的主流 Linux 系統，如 Arch、SUSE、Fedora、RedHat/CentOS 也都已經使用了 Systemd，此外 Ubuntu 也將最快於15.04版本啟用 Systemd 作為預設的系統管理工具），Unit 檔案統一了過去各種不同的系統資源配置格式，例如服務的啟/停、定時任務、裝置自動掛載、網路配置、裝置配置、虛擬記憶體配置等。而 Systemd 通過不同的通過檔案的字尾名來區分這些配置檔案，之前我們寫的 .service 檔案便是其中的一種。下面是 Systemd 所支援的12種 Unit 檔案型別。

字尾名	作用
.automount	用於控制自動掛載檔案系統。自動掛載即當某一目錄被訪問時系統自動掛載該目錄，這類 unit 取代了傳統 Linux 系統的 autofs 相應功能
.device	對應 /dev 目錄下裝置，主要用於定義裝置之間的依賴關係
.mount	定義系統結構層次中的一個掛載點，可以替代過去的 /etc/fstab 配置檔案
.path	用於監控指定目錄變化，並觸發其他 unit 執行
.scope	這類 unit 檔案不是使用者建立的，而是 Systemd 執行時自己產生的，描述一些系統服務的分組資訊
.service	封裝守護程序的啟動、停止、重啟和過載操作，是最常見的一種 unit 型別
.slice	用於描述 cgroup 的一些資訊，極少使用到，一般使用者就忽略它吧
.snapshot	這種 unit 其實是 systemctl snapshot 命令建立的一個描述 Systemd unit 執行狀態的快照
.socket	監控系統或網際網路中的 socket 訊息，用於實現基於網路資料自動觸發服務啟動
.swap	定義一個用於做虛擬記憶體的交換分割槽
.target	用於對 unit 進行邏輯分組，引導其他 unit 的執行。它替代了 SysV 中執行級別的作用，並提供更靈活的基於特定裝置事件的啟動方式。例如 multi-user.target 相當於過去的執行級別5，而 bluetooth.target 在有藍芽裝置接入時就會被觸發
.timer	封裝由system的裡面由時間觸發的動作, 替代了 crontab 的功能

這些琳琅滿目的種類，幾乎囊括了系統管理的大部分的日常工作內容，一致的配置格式和操作方法使得即便普通的 Linux 系統使用者和軟體開發者也能夠很快的上手修改系統的配置，媽媽再也不用擔心我們把系統弄掛了。其實這些配置檔案型別中，真正經常需要修改的並不多，並且這篇文章只打算對其中最常用的，也是之前一直在寫的 .service 型別展開說明。主要出於篇幅考慮，不過，既然格式都統一了，只要將一種配置型別用熟了，其他的配置學習來還不是分分鐘的事啦 :D

需要再次強調的是，Unit 檔案按照 Systemd 約定，應該被放置在指定的3個系統目錄之一。這3個目錄是有優先順序的，依照下面表格，越靠上的優先順序越高，因此在幾個目錄中有同名檔案的時候，只有優先順序最高的目錄裡的那個會被使用。

路徑	說明
/etc/systemd/system	系統或使用者提供的配置檔案
/run/systemd/system	軟體執行時生成的配置檔案
/usr/lib/systemd/system	系統或第三方軟體安裝時新增的配置檔案

由於這裡的最後一個目錄在 CoreOS 中是屬於系統的只讀分割槽，因此在 CoreOS 中，第三方軟體如果安裝時可能需要特別處理，將配置的 Unit 檔案放到 /run/systemd/system目錄中。索性 CoreOS 本來也不推薦直接在系統上安裝軟體，人家特意把系統分割槽做成只讀這個意思就已經很明確了。一些確實需要安裝在 CoreOS 上的軟體比如 Deis，它的 .service 服務配置都是放到 /run/systemd/system目錄裡面的。

Service檔案

開門見山，直接來看兩個實際的服務配置檔案吧。

第一個配置是 CoreOS 系統中 Docker 服務的 Unit 檔案，路徑是 /usr/lib/systemd/system/docker.service，可以看到其中的內容相當精簡易讀。

[Unit]
Description=Docker Application Container Engine
Documentation=http://docs.docker.com
After=docker.socket early-docker.target network.target
Requires=docker.socket early-docker.target
[Service]
Environment=TMPDIR=/var/tmp
Environment=DOCKER_OPTS='--insecure-registry="0.0.0.0/0"'
EnvironmentFile=-/run/docker_opts.env
LimitNOFILE=1048576
LimitNPROC=1048576
ExecStart=/usr/lib/coreos/dockerd --daemon --host=fd:// $DOCKER_OPTS
[Install]
WantedBy=multi-user.target

第二個配置的寫法風格與前一個有所差異，但同樣的內容清晰，條理明確。這個配置來自 CoreOS 的一篇文件，作用是啟動一個 Apache 服務容器然後將服務的執行資訊註冊到 Etcd 中。

（注意，這篇文件原文中的示例中似乎有一個錯誤，在啟動 docker 時，ExecStart 中的命令引數 -p 80:80 應當為 -p 8081:80，下面程式碼已修正）

[Unit]
Description=My Advanced Service
After=etcd.service
After=docker.service
[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill apache1
ExecStartPre=-/usr/bin/docker rm apache1
ExecStartPre=/usr/bin/docker pull coreos/apache
ExecStart=/usr/bin/docker run --name apache1 -p 8081:80 coreos/apache /usr/sbin/apache2ctl -D FOREGROUND
ExecStartPost=/usr/bin/etcdctl set /domains/example.com/10.10.10.123:8081 running
ExecStop=/usr/bin/docker stop apache1
ExecStopPost=/usr/bin/etcdctl rm /domains/example.com/10.10.10.123:8081
[Install]
WantedBy=multi-user.target

仔細觀察著兩個服務配置，其中有一些很明顯的共同點。我們接下來就以這兩個 Unit 檔案為例，一步步的分析一下 Systemd 服務配置的寫法。

Service 的 Unit 檔案可以分為3個配置區段，其中 Unit 和 Install 段是所有 Unit 檔案通用的，用於配置服務（或其他系統資源）的描述、依賴和隨系統啟動方式。而 Service 段則是服務型別的 Unit 檔案（字尾.service）特有的，用於定義服務的具體管理和操作方法。其他的每種配置檔案也都會有一個特有的配置段，這就是幾種不同 Unit 配置檔案最明顯的區別。

來看看每個配置段常用的引數有哪些。

一、Unit 段

• Description

一段描述這個 Unit 檔案的文字，通常只是簡短的一句話。

• Documentation

指定服務的文件，可以是一個或多個文件的URL路徑。

• Requires

依賴的其他 Unit 列表，列在其中的 Unit 模組會在這個服務啟動的同時被啟動，並且如果其中有任意一個服務啟動失敗，這個服務也會被終止。

• Wants

與 Requires 相似，但只是在被配置的這個 Unit 啟動時，觸發啟動列出的每個 Unit 模組，而不去考慮這些模組啟動是否成功。

• After

與 Requires 相似，但會在後面列出的所有模組全部啟動完成以後，才會啟動當前的服務。

• Before

與 After 相反，在啟動指定的任一個模組之前，都會首先確保當前服務已經執行。

• BindsTo

與 Requires 相似，但是一種更強的關聯。啟動這個服務時會同時啟動列出的所有模組，當有模組啟動失敗時終止當前服務。反之，只要列出的模組全部啟動以後，也會自動啟動當前服務。並且這些模組中有任意一個出現意外結束或重啟，這個服務會跟著終止或重啟。

• PartOf

這是一個 BindTo 作用的子集，僅在列出的任何模組失敗或重啟時，終止或重啟當前服務，而不會隨列出模組的啟動而啟動。

• OnFailure

當這個模組啟動失敗時，就自動啟動列出的每個模組。

• Conflicts

與這個模組有衝突的模組，如果列出模組中有已經在執行的，這個服務就不能啟動，反之亦然。

上面這些配置中，除了 Description 外，都能夠被新增多次。比如前面第一個例子中的After引數在一行中使用空格分隔指定所有值，也可以像第二個例子中那樣使用多個After引數，在每行引數中指定一個值。

二、Install 段

這個段中的配置與 Unit 有幾分相似，但是這部分配置需要通過 systemctl enable 命令來啟用，並且可以通過 systemctl disable 命令禁用。另外這部分配置的目標模組通常是特定啟動級別的 .target 檔案，用來使得服務在系統啟動時自動執行。

• WantedBy

和前面的 Wants 作用相似，只是後面列出的不是服務所依賴的模組，而是依賴當前服務的模組。

• RequiredBy

和前面的 Requires 作用相似，同樣後面列出的不是服務所依賴的模組，而是依賴當前服務的模組。

• Also

當這個服務被 enable/disable 時，將自動 enable/disable 後面列出的每個模組。

上面的兩個例子中使用的都是 “WantedBy=multi-user.target” 表明當系統以多使用者方式（預設的執行級別）啟動時，這個服務需要被自動執行。當然還需要 systemctl enable 啟用這個服務以後自動執行才會生效。關於 Linux 系統啟動時的執行級別，可以參看這篇文章。

三、Service 段

這個段是 .service 檔案獨有的，也是對於服務配置最重要的部分。這部分的配置選項非常多，主要分為服務生命週期控制和服務上下文配置兩個方面，下面是比較常用到的一些引數。

服務生命週期控制相關的引數：

• Type

服務的型別，常用的有 simple（預設型別） 和 forking。預設的 simple 型別可以適應於絕大多數的場景，因此一般可以忽略這個引數的配置。而如果服務程式啟動後會通過 fork 系統呼叫建立子程序，然後關閉應用程式本身程序的情況，則應該將 Type 的值設定為 forking，否則 systemd 將不會跟蹤子程序的行為，而認為服務已經退出。

• RemainAfterExit

值為 true 或 false（也可以寫 yes 或 no），預設為 false。當配置值為 true 時，systemd 只會負責啟動服務程序，之後即便服務程序退出了，systemd 仍然會認為這個服務是在執行中的。這個配置主要是提供給一些並非常駐記憶體，而是啟動註冊後立即退出然後等待訊息按需啟動的特殊型別服務使用

• ExecStart

這個引數是幾乎每個 .service 檔案都會有的，指定服務啟動的主要命令，在每個配置檔案中只能使用一次。

• ExecStartPre

指定在啟動執行 ExecStart 的命令前的準備工作，可以有多個，如前面第二個例子中所示，所有命令會按照檔案中書寫的順序依次被執行。

• ExecStartPost

指定在啟動執行 ExecStart 的命令後的收尾工作，也可以有多個。

• TimeoutStartSec

啟動服務時的等待的秒數，如果超過這個時間服務任然沒有執行完所有的啟動命令，則 systemd 會認為服務自動失敗。這一配置對於使用 Docker 容器託管的應用十分重要，由於 Docker 第一次執行時可以能會需要從網路下載服務的映象檔案，因此造成比較嚴重的延時，容易被 systemd 誤判為啟動失敗而殺死。通常對於這種服務，需要將 TimeoutStartSec 的值指定為 0，從而關閉超時檢測，如前面的第二個例子。

• ExecStop

停止服務所需要執行的主要命令。

• ExecStopPost

指定在 ExecStop 命令執行後的收尾工作，也可以有多個。

• TimeoutStopSec

停止服務時的等待的秒數，如果超過這個時間服務仍然沒有停止，systemd 會使用 SIGKILL 訊號強行殺死服務的程序。

• Restart

這個值用於指定在什麼情況下需要重啟服務程序。常用的值有 no，on-success，on-failure，on-abnormal，on-abort 和 always。預設值為 no，即不會自動重啟服務。這些不同的值分別表示了在哪些情況下，服務會被重新啟動，參見下表。

服務退出原因	no	always	on-failure	on-abnormal	on-abort	no-success
正常退出	√	√
異常退出	√	√
啟動/停止超時	√	√	√
被異常KILL	√	√	√	√

• RestartSec

如果服務需要被重啟，這個引數的值為服務被重啟前的等待秒數。

• ExecReload

重新載入服務所需執行的主要命令。

服務上下文配置相關的引數：

• Environment

為服務新增環境變數，如前面的第一個例子中所示。

• EnvironmentFile

指定載入一個包含服務所需的環境變數列表的檔案，檔案中的每一行都是一個環境變數的定義。

• Nice

服務的程序優先順序，值越小優先順序越高，預設為0。-20為最高優先順序，19為最低優先順序。

• WorkingDirectory

指定服務的工作目錄。

• RootDirectory

指定服務程序的根目錄（ / 目錄），如果配置了這個引數後，服務將無法訪問指定目錄以外的任何檔案。

• User

指定執行服務的使用者，會影響服務對本地檔案系統的訪問許可權。

• Group

指定執行服務的使用者組，會影響服務對本地檔案系統的訪問許可權。

• LimitCPU / LimitSTACK / LimitNOFILE / LimitNPROC 等

限制特定服務可用的系統資源量，例如 CPU，程式堆疊，檔案控制代碼數量，子程序數量… 不再展開說明了，值的含義可參考 Linux 文件資源配額部分中 RLIMIT_ 開頭的那些引數們。

列完這麼一大推引數的我也是醉了（這些都是常用的引數，不常用的還沒寫咧），但其實嘛，Systemd 的精華也就在此了。再仔細一推敲，這麼些冗長的引數之間還是有些規律的，並且大多可以望文生義，因此寫 Unit 檔案的差事本身倒並不讓人覺得枯燥。反觀過去需要學習N種不同配置格式來管理N種不同的系統資源的方法，Systemd的理念實在是先進了太多了。而這些引數云云，大概只有用得多了，才會覺得它們看起來不那麼討厭了吧o(//_//)o

Fleet 的 X-Fleet 段

前面討論的都是 Systemd 使用的 Unit 檔案。在這個系列的 Fleet 那篇中，演示了 Fleet 中的服務配置。

Fleet 的 Unit 服務描述檔案，實際上就是 Systemd 的 .service 配置檔案的翻版。但為了方便服務在叢集環境的自適應管理，Fleet 在 Systemd 的 Unit 配置基礎上添加了一個 X-Fleet 段，專門用於描述服務應該被分配到叢集的哪些節點啟動。它的可用引數只有5個，可以請出來一一亮相。

• MachineID

直接了當的告訴 Fleet 這個服務只能執行在特定的一個節點上，注意這裡的值必須是完整的節點 ID，這個 ID 可以通過 “fleetctl list-machines -l” 命令獲得。

• MachineOf

值是另一個 .service 檔案，表示當前服務必須執行在與指定的這個服務在同一個節點上。

• MachineMetadata

值是一個節點的 Metadata 內容，例如 "region=us-east-1" 。這些 Metadata 是在啟動節點時通過 Cloudinit 寫進去的，具體方法在系列的 Fleet 那篇文章有提及。這個引數可以使用多次，或在通過空格分隔將多個值同時傳進去。

• Conflicts

值是一個 .service 檔案的，Conflicts引數也可以使用多次，並且其值可以使用萬用字元，例如 apache* 表示所有以 “apache” 開頭的服務。

• Global

如果值為 true，則這個服務會被部署到叢集中符合 MachineMetadata限定條件的每一個節點上。注意，當 Global 值為 true 時，除了 MachineMetadata外的所有其他約束條件都會被忽略。

前四個引數在 Fleet v0.8 版本前被命名為 X-ConditionMachineID、X-ConditionMachineOf、X-ConditionMachineMetadata和 X-Conflicts，這些寫法現在已經停止使用了，但仍然可能會在一些早期的文件或網路文章中出現，如果看見了，淡定的飄過吧。

Unit模板

在現實中，往往有一些應用需要被複制多份執行，例如在一個負載均衡例項後面執行的多個相同的服務例項。但是按照之前的例子，每個服務都需要一個單獨的 Unit 檔案，這樣複製多份相同檔案的做顯然不便於服務的管理。為此 Systemd 定義了一種特殊的 Service Unit檔案，稱為 Unit 模板。

模板檔案的主要特點是，檔名以@符號結尾，而啟動的時候指定的Unit名稱為模板名稱附加一個引數字串。例如，將之前的例子第二個 Unit 檔案修改為可以用於啟動多個例項的模板。

一、首先修改檔名，新增一個@符號

例如原來的檔名是 apache.service，那麼可以將它修改為 [email protected]，這樣做的目的是表面這個檔案是一個模板檔案。而在服務啟動時可以在@後面放置一個用於區分服務例項的附加字串引數，通常這個引數會使用監聽的埠號或使用的控制檯TTY編號等。例如 “systemctl start [email protected]”。

二、然後修改 Unit 檔案內容

Unit 檔案中可以獲取服務啟動時的附加引數，因此通常需要修改 Unit 檔案中不應固定的部分，例如服務監聽的 IP 和埠，替換為從附加引數中獲取。

[Unit]
Description=My Advanced Service Template
After=etcd.servicedocker.service
[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill apache%i
ExecStartPre=-/usr/bin/docker rm apache%i
ExecStartPre=/usr/bin/docker pull coreos/apache
ExecStart=/usr/bin/docker run --name apache%i -p %i:80 coreos/apache /usr/sbin/apache2ctl -D FOREGROUND
ExecStartPost=/usr/bin/etcdctl set /domains/example.com/%H:%i running
ExecStop=/usr/bin/docker stop apache1
ExecStopPost=/usr/bin/etcdctl rm /domains/example.com/%H:%i
[Install]
WantedBy=multi-user.target

仔細觀察一下變化了的地方，上面使用到了佔位符 %H 和 %i，常用的佔位符有6種（一共19種，其餘不怎麼常用的查文件吧），這些佔位符會在 Unit 啟動時被實際的值動態的替換掉。

佔位符	作用
%n	完整的 Unit 檔名字，包括 .service 字尾名
%m	實際執行的節點的 Machine ID，適合用來做Etcd路徑的一部分，例如 /machines/%m/units
%b	作用有點像 Machine ID，但這個值每次節點重啟都會改變，稱為 Boot ID
%H	實際執行節點的主機名
%p	Unit 檔名中在 @ 符號之前的部分，不包括 @ 符號
%i	Unit 檔名中在 @ 符號之後的部分，不包括 @ 符號和 .service 字尾名

順帶一提，這些引數中除了 %i 以外，同樣可以用於非模板的 Unit 檔案中。%p 在普通 Unit 檔案中會被動態替換為服務名稱去掉 .service 字尾的名字。

三、啟動 Unit 模板的服務例項

模板服務的啟動對於 Systemd 和 Fleet 大致相同。

Systemd 的情況略簡單一些，只需要執行時加上字尾引數。例如 “systemctl start [email protected]”。Systemd 首先會在其特定的目錄下尋找名為 [email protected]的檔案，如果沒有找到，而檔名中包含@字元，它就會嘗試去掉字尾引數匹配模板檔案。例如沒有找到 [email protected]，那麼Systemd會找到[email protected]，並將它通過模板檔案中例項化。

Fleet 沒有特定的 Unit 檔案存放目錄，不過在通過 fleetctl start 或 fleetctl submit 命令指定 Unit 檔案路徑時加上字尾引數，Fleet 同樣會自動匹配去掉字尾引數後的模板檔案。例如 “fleetctl submit ${HOME}/[email protected]”，就會匹配到 ${HOME} 目錄下面的 [email protected] 模板檔案。

後續綜合案例的文章中，還會結合實際例子詳細的介紹模板的使用場景。

小結

這一篇的內容略為零碎，主要是對 CoreOS 中的系統資源和服務起著管理作用的 Unit 配置檔案做了比較深入的說明。特別是最後的 Unit 模板部分在一定程度上賦予了服務橫向拓展的能力，在實際的專案環境中使用得相當普遍。這些系統管理方面的技巧，需要一定的實戰磨練才能體會其中的好處。

最近有同事問我，介紹了這麼多的 CoreOS，能否用一句話來評述一下這個系統，以及它最適用於什麼樣的應用場景呢？

對於第一個問題，CoreOS 並不是什麼神祕的銀彈，它只是一個“理念比較先進（具體見系列第一篇）”並且“對叢集和應用容器比較友好”的伺服器 Linux 發行版。有些人會追問，要是把 CoreOS 和其他發行版進行對比哪個好用呢。這個…專注的領域不一樣啊，CoreOS 永遠也不會替代 Fedora 和 Ubuntu 這些桌面 Linux 發行版的地位，因為它實際上是一個高度精簡的沒有 GUI 和 x-window 的作業系統（但並不是說 CoreOS 不能夠提供需要 GUI 的服務，因為可以在容器中安裝 x-window 和 VNC 服務）。

對於第二個問題，其實是沒有準確答案的，Linux 系統發行版的選擇完全是個人偏好問題。普遍來說，基於 CoreOS 的自動無縫升級和對容器和叢集友好的特性，它會比較適用於需要長期執行，並且具備橫向擴充套件架構，特別是 Micro Service 架構的以對外提供服務為目的的叢集。但並不是說 CoreOS 就不能用在一般的伺服器場景，美國的SaaS雲服務網站Iron.io和購物網站Shopify都使用了CoreOS 作為其業務支撐的平臺，它們的業務場景除了都使用大規模的叢集外，各方面都很不一樣。

在接下來的兩篇中會連續介紹兩種結合 CoreOS 的內建特性實現服務高可用的綜合案例，敬請期待。