LinchPin：一個使用 Ansible 的簡化的編配工具

針對暫時的資源，解除安裝功能有一些限制，像網路、儲存、等等。網路資源可以被用於多個雲實體。在這種情況下，執行一個 linchpin destroy 某些資源就不能解除安裝。這取決於每個供應商的實現。檢視每個供應商[9]的具體實現。

LinchPin 的 Python API

在 linchpin 命令列中實現的功能大多數都是用 Python API 寫的。這個 API，雖然不完整，但它已經成為 LinchPin 工具的至關重要的元件。

這個 API 由下麵的三個包組成：

該命令列工具是基於 linchpin 包來管理的。它匯入了 linchpin.cli 模組和類，該類是 linchpin.api 的子類。這樣做的目的是為了允許使用 linchpin.api 來做其它的 LinchPin 實現，比如像計劃中的 RESTful API。

更多資訊，去檢視 Python API library documentation on Read the Docs[6]。

Hook

LinchPin 1.0 的其中一個大的變化是轉向 hook。hook 的標的是在 linchpin 執行期間的特定狀態下，允許配置使用更多外部資源。目前的狀態有：

在每種狀態下，這些 hooks 允許執行外部指令碼。存在幾種型別的 hook，包括一個定製的叫做 Action Managers。這是一個內建的 Action Manager 的串列：

hook 被系結到一個特定的標的，並且每個標的使用時必須重新宣告。將來，hook 將可能是全域性的，然後它們在每個標的的 hooks 節下命名會更簡單。

使用 hook

hook 描述起來非常簡單，但理解它們強大的功能卻並不簡單。這個特性的存在是為了給使用者靈活提供那些 LinchPin 開發者所沒有考慮到的功能。這個概念可能會帶來 ping 一套系統的簡單方式，舉個實體，比如在執行另一個 hook 之前。

更仔細地去研究 工作空間 ，你可能會註意到 hooks 目錄，讓我們看一下這個目錄的結構：

$ tree hooks/
hooks/
├── ansible
│   ├── ping
│   │   └── dummy_ping.yaml
└── shell
    └── database
        ├── init_db.sh
        └── setup_db.sh

在任何情況下，hook 都可以用在 PinFile 中，展示如下：

---
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

基本概念是有三個 postup 動作要完成。Hook 是從上到下執行的，因此，Ansible ping 任務將首先執行，緊接著是兩個 shell 任務， setup_db.sh 和 init_db.sh。假設 hook 執行成功。將發生一個系統的 ping，然後，一個資料庫被安裝和初始化。

認證的驅動程式

在 LinchPin 的最初設計中，開發者決定在 Ansible playbooks 中管理認證；然而，逐漸有更多的 API 和命令列驅動的工具後，意味著認證將被置於 playbooks 庫之外，並且還可以根據需要去傳遞認證值。

配置

讓使用者使用驅動程式提供的認證方法去完成這個任務。舉個實體，如果對於 OpenStack 呼叫的拓撲，標準方法是使用一個 yaml 檔案，或者類似於 OS_ 字首的環境變數。clouds.yaml 檔案是一個 profile 檔案的組成部分，它有一個 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

更多詳細資訊在 OpenStack documentation[10]。

這個 clouds.yaml 或者任何其它認證檔案位於 default_credentials_path （比如，~/.config/linchpin）中，併在拓撲中取用：

---
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

default_credentials_path 可以透過修改 linchpin.conf 改變。

拓撲在底部包含一個新的 credentials 節。使用 openstack、ec2、和 gcloud 模組，也可以去指定類似的憑據。認證驅動程式將檢視給定的名為 clouds.yaml 的檔案，並搜尋名為 default 的 配置。

假設認證被找到並被載入，配給將正常繼續。

簡化

雖然 LinchPin 可以完成複雜的拓撲、庫存佈局、hooks、和認證管理，但是，終極標的是簡化。透過使用一個命令列介面的簡化，除了提升已經完成的 1.0 版的開發者體驗外，LinchPin 將持續去展示覆雜的配置可以很簡單地去管理。

社群的成長

在過去的一年中，LinchPin 的社群現在已經有了 郵件串列[11]和一個 IRC 頻道（#linchpin on chat.freenode.net，而且在 GitHub[12] 中我們很努力地管理它。

在過去的一年裡，社群成員已經從 2 位核心開發者增加到大約 10 位貢獻者。更多的人持續參與到專案中。如果你對 LinchPin 感興趣，可以給我們寫信、在 GitHub 上提問，加入 IRC，或者給我們發郵件。

這篇文章是基於 Clint Savage 在 OpenWest 上的演講 Introducing LinchPin: Hybrid cloud provisioning using Ansible[13] 整理的。OpenWest[14] 將在 2017 年 7 月 12-15 日在鹽城湖市舉行。

作者簡介：

Clint Savage - 工作於 Red Hat 是一位負責原子專案（Project Atomic）的高階軟體工程師。他的工作是為 Fedora、CentOS、和 Red Hat Enterprise Linux（RHEL）提供自動原子伺服器構建。

via: https://opensource.com/article/17/6/linchpin

作者：Clint Savage[16] 譯者：qhwdw 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出