2016 年末開始的 ，現在已經擁有一個 API 和一個成長中的社區。-- Clint
本文導航? 是一個庫09%?深入了解命令行11%?配置文件17%?工作空間20%?初始化 ( init)23%?配給 ( up)29%?庫存生成43%?卸載 （ ）48%? 的 API54%?%?使用 %?認證的驅動程序76%?配置78%?簡化89%?社區的成長90%編譯自|
作者|Clint
譯者|qhwdw
2016 年末開始的 ，現在已經擁有一個 API 和一個成長中的社區。
去年，我的團隊公布了[1][2]，這是一個使用 的混合云編配工具。配給云資源從來沒有這么容易便捷過。借助 強力支持， 專注于簡化，使云資源讓用戶可以觸手可及。在這篇文章中，我將介紹 ，并且去看看過去的 10 個月該項目是如何逐漸成熟。
（LCTT 譯注：關于 應該翻譯成慣例的“編排”還是“編配”，有個 @ 提出的建議[3]，歡迎大家參與討論。）
剛出現的時候，使用-命令去運行 ，雖然可以完成，但是還是很復雜的， 現在有一個前端命令行用戶界面（CLI），它是用Click[4]寫的，而且它使 比以前更簡化。
沒有止步于 CLI， 現在還有一個[5]API，它可以用于管理資源，比如， EC2 和 實例、網絡、存儲、安全組等等。這個 API文檔[6]可以在你想去嘗試 的 API 時幫助你。
是一個庫
因為 的核心是 [7]，其角色、模塊、過濾器，以及任何被稱為 模塊的東西都被移進 庫中，這意味著我們雖然可以直接調用 ，但它不是資源管理的首選機制。可執行文件事實上已經成為該命令行的前端。
深入了解命令行
讓我們深入了解命令行：
$ linchpin
Usage: linchpin [OPTIONS] COMMAND [ARGS]...
?linchpin: hybrid cloud orchestration
Options:
?-c, --config PATH ? ? ? Path to config file
?-w, --workspace PATH ? ?Use the specified workspace if the familiar Jenkins
? ? ? ? ? ? ? ? ? ? ? ? ?$WORKSPACE environment variable is not set
?-v, --verbose ? ? ? ? ? Enable verbose output
?--version ? ? ? ? ? ? ? Prints the version and exits
?--creds-path PATH ? ? ? Use the specified credentials path if WORKSPACE
? ? ? ? ? ? ? ? ? ? ? ? ?environment variable is not set
?-h, --help ? ? ? ? ? ? ?Show this message and exit.
Commands:
?init ? ? Initializes a linchpin project.
?up ? ? ? Provisions nodes from the given target(s) in...
?destroy ?Destroys nodes from the given target(s) in...
你可以立即看到一個簡單的描述，以及命令的選項和參數。這個幫助的最下面的三個命令是本文的重點內容。
配置文件
之前有個名為.yml的文件。但現在這個文件沒有了，替換它的是一個 ini 形式的配置文件，稱為.conf。雖然這個文件可以被修改或放到別的地方，它可以放置在配置文件容易找到的庫路徑中。在多數情況下，.conf文件是不需要去修改的。
工作空間
工作空間是一個定義好的文件系統路徑，它是一個邏輯上的資源組。一個工作空間可以認為是一個特定環境、服務組、或其它邏輯組的一個單點。它也可以是一個所有可管理資源的大的存儲容器。
工作空間可以在命令行上使用--（-w）選項去指定，隨后是工作空間路徑。它也可以使用環境變量指定（比如，bash 中的$）。默認工作空間是當前目錄。
初始化 ( init)
運行 init將生成一個需要的目錄結構，以及一個、、和文件的示例：
$ export WORKSPACE=/tmp/workspace
$ linchpin init
PinFile and file structure created at /tmp/workspace
$ cd /tmp/workspace/
$ tree
.
├── credentials
├── hooks
├── inventories
├── layouts
│?? └── example-layout.yml
├── PinFile
├── resources
└── topologies
? ?└── example-topology.yml
在這個時候，可以執行 up，然后提供一個虛擬機，和一個名為-的網絡。會生成一個庫存，并放在/.目錄中。它可以通過讀取/-.yml和的值了解它。
配給( up)
一旦有了一個 、拓撲、和一個可選的布局，就可以配給了。
我們使用 dummy （模擬）工具，因為用它來配給非常簡單；它不需要任何額外的東西（認證、網絡、等等）。dummy 配給程序會創建一個臨時文件，它表示所配給的主機。如果臨時文件沒有任何數據，說明主機沒有被配給，或者它已經被銷毀了。
dummy 配給程序的目錄樹大致如下：
$ tree
.
├── hooks
├── inventories
├── layouts
│?? └── dummy-layout.yml
├── PinFile
├── resources
└── topologies
? ?└── dummy-cluster.yml
也很簡單；它指定了它的拓撲，并且為目標提供一個可選的布局：
---
dummy1:
?topology: dummy-cluster.yml
?layout: dummy-layout.yml
dummy-.yml拓撲文件是一個引用，指向到配給的三個類型的資源：
---
topology_name: "dummy_cluster" # topology name
resource_groups:
?-
? ?resource_group_name: "dummy"
? ?resource_group_type: "dummy"
? ?resource_definitions:
? ? ?-
? ? ? ?name: "web"
? ? ? ?type: "dummy_node"
? ? ? ?count: 3
執行命令 up將基于上面的（在這個案例中是）生成和文件。
$ linchpin up
target: dummy1, action: up
$ ls {resources,inventories}/dummy*
inventories/dummy_cluster.inventory ?resources/dummy_cluster.output
要驗證 dummy 集群的資源，可以檢查/tmp/dummy.hosts：
$ cat /tmp/dummy.hosts
web-0.example.net
web-1.example.net
web-2.example.net
Dummy 模塊為假定的（或模擬的）配給提供了一個基本工具。關于在 、AWS EC2、 Cloud 上和 的更多詳細情況，可以去看示例[8]。
庫存生成
作為上面提到的 的一部分，可以指定一個。如果這個文件被指定，并且放在一個正確的位置上，就會為配給的資源自動生成一個用于 的靜態庫存文件：
---
inventory_layout:
?vars:
? ?hostname: __IP__
?hosts:
? ?example-node:
? ? ?count: 3
? ? ?host_groups:
? ? ? ?- example
當 up運行完成，資源文件將提供一個很有用的詳細信息。特別是，插入到靜態庫存的 IP 地址或主機名：
[example]
web-2.example.net hostname=web-2.example.net
web-1.example.net hostname=web-1.example.net
web-0.example.net hostname=web-0.example.net
[all]
web-2.example.net hostname=web-2.example.net
web-1.example.net hostname=web-1.example.net
web-0.example.net hostname=web-0.example.net
卸載 （ ）
也可以執行資源卸載。卸載動作一般認為該資源是已經配給好的；然而，因為 是冪等的， 將僅檢查確認該資源是啟用的。如果這個資源已經是啟用的，它將去卸載它。
命令 也將使用資源和/或拓撲文件去決定合適的卸載過程。
角色不使用資源，卸載期間僅有拓撲：
$ linchpin destroy
target: dummy1, action: destroy
$ cat /tmp/dummy.hosts
-- EMPTY FILE --
針對暫時的資源，卸載功能有一些限制，像網絡、存儲、等等。網絡資源可以被用于多個云實例。在這種情況下，執行一個 某些資源就不能卸載。這取決于每個供應商的實現。查看每個供應商[9]的具體實現。
的 API
在命令行中實現的功能大多數都是用 API 寫的。這個 API，雖然不完整，但它已經成為 工具的至關重要的組件。
這個 API 由下面的三個包組成：
??.cli?.api
該命令行工具是基于包來管理的。它導入了.cli模塊和類，該類是.api的子類。這樣做的目的是為了允許使用.api來做其它的 實現，比如像計劃中的 API。
更多信息，去查看 API on Read the Docs[6]。
Hook
1.0 的其中一個大的變化是轉向 hook。hook 的目標是在運行期間的特定狀態下，允許配置使用更多外部資源。目前的狀態有：
?preup: 在配給拓撲資源之前運行?: 在配給拓撲資源之后運行，并且生成可選的庫存?: 卸載拓撲資源之前運行?: 卸載拓撲資源之后運行
在每種狀態下必須使用角色管理工具安裝或配置 2.0，這些 hooks 允許運行外部腳本。存在幾種類型的 hook，包括一個定制的叫做 。這是一個內置的 的列表：
?shell: 允許任何的內聯的 shell 命令，或者一個可運行的 shell 腳本?: 運行一個 腳本?: 運行一個 ，允許傳遞一個和作為 字典?: 運行一個 Node.js 腳本?ruby: 運行一個 Ruby 腳本
hook 被綁定到一個特定的目標，并且每個目標使用時必須重新聲明。將來，hook 將可能是全局的，然后它們在每個目標的hooks節下命名會更簡單。
使用 hook
hook 描述起來非常簡單，但理解它們強大的功能卻并不簡單。這個特性的存在是為了給用戶靈活提供那些 開發者所沒有考慮到的功能。這個概念可能會帶來 ping 一套系統的簡單方式，舉個實例，比如在運行另一個 hook 之前。
更仔細地去研究工作空間，你可能會注意到hooks目錄，讓我們看一下這個目錄的結構：
$ tree hooks/
hooks/
├── ansible
│ ? ├── ping
│ ? │?? └── dummy_ping.yaml
└── shell
? ?└── database
?? ? ? ├── init_db.sh
?? ? ? └── setup_db.sh
在任何情況下，hook 都可以用在中，展示如下：
---
dummy1:
?topology: dummy-cluster.yml
?layout: dummy-layout.yml
?hooks:
? ?postup:
? ? ?- name: ping
? ? ? ?type: ansible
? ? ? ?actions:
? ? ? ? ?- dummy_ping.yaml
? ? ?- name: database
? ? ? ?type: shell
? ? ? ?actions:
? ? ? ? ?- setup_db.sh
? ? ? ? ?- init_db.sh
基本概念是有三個 動作要完成。Hook 是從上到下運行的，因此，任務將首先運行，緊接著是兩個 shell 任務，.sh和.sh。假設 hook 運行成功。將發生一個系統的 ping，然后，一個數據庫被安裝和初始化。
認證的驅動程序
在 的最初設計中，開發者決定在 中管理認證；然而必須使用角色管理工具安裝或配置 2.0，逐漸有更多的 API 和命令行驅動的工具后，意味著認證將被置于 庫之外，并且還可以根據需要去傳遞認證值。
配置
讓用戶使用驅動程序提供的認證方法去完成這個任務。舉個實例，如果對于 調用的拓撲，標準方法是使用一個 yaml 文件，或者類似于OS_前綴的環境變量。.yaml文件是一個 文件的組成部分，它有一個auth節：
clouds:
?default:
? ?auth:
? ? ?auth_url: http://stack.example.com:5000/v2.0/
? ? ?project_name: factory2
? ? ?username: factory-user
? ? ?password: password-is-not-a-good-password
更多詳細信息在 [10]。
這個.yaml或者任何其它認證文件位于path（比如，~/./）中，并在拓撲中引用：
---
topology_name: openstack-test
resource_groups:
?-
? ?resource_group_name: linchpin
? ?resource_group_type: openstack
? ?resource_definitions:
? ? ?- name: resource
? ? ? ?type: os_server
? ? ? ?flavor: m1.small
? ? ? ?image: rhel-7.2-server-x86_64-released
? ? ? ?count: 1
? ? ? ?keypair: test-key
? ? ? ?networks:
? ? ? ? ?- test-net2
? ? ? ?fip_pool: 10.0.72.0/24
? ?credentials:
? ? ?filename: clouds.yaml
? ? ?profile: default
path可以通過修改.conf改變。
拓撲在底部包含一個新的節。使用、ec2、和模塊，也可以去指定類似的憑據。認證驅動程序將查看給定的名為.yaml的文件，并搜索名為的配置。
假設認證被找到并被加載，配給將正常繼續。
簡化
雖然 可以完成復雜的拓撲、庫存布局、hooks、和認證管理，但是，終極目標是簡化。通過使用一個命令行界面的簡化，除了提升已經完成的 1.0 版的開發者體驗外， 將持續去展示復雜的配置可以很簡單地去管理。
社區的成長
在過去的一年中， 的社區現在已經有了郵件列表[11]和一個 IRC 頻道（# on ，而且在[12]中我們很努力地管理它。
在過去的一年里，社區成員已經從 2 位核心開發者增加到大約 10 位貢獻者。更多的人持續參與到項目中。如果你對 感興趣，可以給我們寫信、在 上提問，加入 IRC，或者給我們發郵件。
這篇文章是基于 Clint 在 上的演講 : cloud using [13]整理的。[14]將在 2017 年 7 月 12-15 日在鹽城湖市舉行。
作者簡介：
Clint - 工作于 Red Hat 是一位負責原子項目（ ）的高級軟件工程師。他的工作是為 、、和 Red Hat Linux（RHEL）提供自動原子服務器構建。
via:
作者：Clint [16]譯者：qhwdw校對：wxy
本文由LCTT原創編譯，Linux中國榮譽推出
LCTT 譯者
qhwdw 共計翻譯：34篇貢獻時間：46 天