本週稍早時候， Nutanix 宣布 Calm 3.0.0的全面上市。這是一個令人振奮的版本，因為它對於管理應用程式和主機工作的方式進行了一些重大改善。

舉例：

• 直接從 Calm 創建影像，也就是說從連接到 Calm 管理的 VM(虛擬機器) 磁盤上創建 AHV影像
• 單個 VM 應用程式的部署後，進行更新
• Calm 中的執行手冊，即使不是從 Calm 藍圖啟動，也可以跨多個應用程式和主機協調任務

而今天將要帶大家來看的則是執行手冊。

終點

在 Calm 中，執行手冊將其執行的任務分配給端點。將端點視為執行任務的 IP地址或主機。在Calm UI 中，每個端點都配有 IP位址和憑據-下面顯示的範例是IP位址為 10.133.16.151 的Linux VM。

使用此端點，我們可以開始創建在端點（或任何其他端點）上執行的執行手冊。就本文而言，我們將在端點 22 上使用 SSH ，透過 SSH 私人鑰匙進行身份驗證連接到該 Linux VM。

執行手冊

一旦定義了端點，就可以開始創建可以在這些端點上執行的執行手冊。本文中的範例將包含以下簡單的工作流程：

• 將執行一個小腳本，該腳本反映了特定的退出代碼。
  。退出代碼 0 代表成功。
  。非 0 的代碼代表失敗。我們的腳本可以選擇退出代碼1以模擬失敗。
• 如果決策任務為True（退出代碼0），則將執行一個小型腳本，該腳本執行以下操作：
  。在當前用戶的主目錄中創建一個名為 backup 的目錄（如果該目錄尚不存在）
  。將名為/etc/haproxy/haproxy.cfg的文件複製到〜/ backups
• 如果決策任務為False（退出代碼1），則會顯示一條消息，通知用戶發生了非 0 的退出代碼。
• 完成上述所有任務後，無論成功與否，都會顯示一條簡單的退出消息

與Calm中所有基於 GUI (圖形使用者介面)的任務一樣，此工作流程的創建非常簡單。使用執行手冊編輯器，我們可以構建如下方的運行手冊：

值得注意的是，該特定的執行手冊已配置為使用“ LAMP HAProxy Server ”作為默認端點。這意味著只要沒有另外指定端點，都將使用“ LAMP HAProxy Server ”端點。

透過API的執行手冊

在另一篇文章中，我們將介紹如何透過API創建執行手冊。現在，我們只關注在基礎知識–透過 Nutanix Calm API 列出和執行runbook。我將使用 Postman 創建和測試我的 API 請求，並在本文底部分享我的Postman整合。

列出執行手冊

在先前的文章中，我們介紹了許多概念上與我們的執行手冊非常相似的事物-列出了 Prism Central 實際上存在的執行手冊。

下方的 API POST列出了IP地址為10.133.16.228的Prism Central上的現有執行手冊

https://10.133.16.228:9440/api/nutanix/v3/runbooks/list

您會注意到，這類似於透過 Nutanix Calm API 列出的其他實體（藍圖，應用程式等）。唯一的區別是 JSON POST 的正文需要指定“ runbook”作為要列出的實體類型：

{"kind": "runbook"}

在10.133.16.228的 Prism Central 實例上，有一個名為“ HAProxy Runbook ”的單一執行手冊。以上請求的回應如下：

{
    "api_version": "3.0",
    "metadata": {
        "total_matches": 1,
        "kind": "runbook"
    },
    "entities": [
        {
            "status": {
                "last_update_time": 1591926226637012,
                "name": "HAProxy Runbook",
                "deletion_time": 1,
                "deleted": false,
                "spec_version": 11,
                "description": "",
                "creation_time": 1591842034066247,
                "state": "ACTIVE",
                "schema_version": "1.1.0",
                "entity_verison": 11,
                "running_runs": 0,
                "run_count": 13,
                "messages": [],
                "last_run_time": 1591926229971955,
                "tenant_uuid": "",
                "uuid": "8ece271f-9147-df66-5721-c93338b3f0dd"
            },
            "spec": {},
            "api_version": "3.0",
            "metadata": {
                "last_update_time": "1591926226637012",
                "owner_reference": {
                    "kind": "user",
                    "uuid": "00000000-0000-0000-0000-000000000000",
                    "name": "admin"
                },
                "kind": "runbook",
                "uuid": "8ece271f-9147-df66-5721-c93338b3f0dd",
                "project_reference": {
                    "kind": "project",
                    "name": "ntnxdemo-no-aws",
                    "uuid": "e4f8329c-bf9c-4dd1-8f33-042ce6b86eee"
                },
                "spec_version": 11,
                "creation_time": "1591842034066247",
                "name": "HAProxy Runbook"
            }
        }
    ]
}

請特別注意單個Runbook的UUID：8ece271f-9147-df66-5721-c93338b3f0dd。在處理該特定執行手冊時，我們很快就會需要它。

一旦知道了要使用的Runbook的UUID，就可以透過一個簡單的GET請求獲得更多訊息：

https://10.133.16.228:9440/api/nutanix/v3/runbooks/8ece271f-9147-df66-5721-c93338b3f0dd

回應包含有關 Runbook 的所有訊息，包括在每個階段執行的腳本（如果有的話），依據，默認端點等。

執行Runbook

讓我們看一下如何使用v3 Calm API執行 Runbook。到目前為止，我們已經研究了如何透過 UUID “尋找” Runbook。在這種情況下，我們的Runbook的UUID是8ece271f-9147-df66-5721-c93338b3f0dd。

簡單的Runbook執行

在最簡單的級別上，我們可以提交Runbook運行請求，並發送一個空的POST正文。這將執行Runbook ，並使用在 “ Calm UI” 中創建的Runbook指定設置。這包括像是端點和憑證之類的參數。

空的POST正文:

{}

指定了空的POST正文後，完整的請求路徑如下：

https://10.133.16.228:9440/api/nutanix/v3/runbooks/8ece271f-9147-df66-5721-c93338b3f0dd/run

來自成功執行請求的響應如下：

{
    "status": {
        "runlog_uuid": "cfa369e5-fb82-4f22-97aa-610d773e502d"
    },
    "spec": {},
    "api_version": "",
    "metadata": {}
}

高端Runbook執行

上面的範例很棒，但是如果我們想控制 Runbook 在哪個端點上執行該怎麼辦？現在就可以通過 UI 或 API 在任意端點上隨時執行它們_這是Runbook最強大的功能之一。

每個端點都有一個UUID，與執行手冊完全相同。我們可以提交一個簡單的GET請求，該請求將列出我們的端點，如下所示：

https://10.133.16.228:9440/api/nutanix/v3/endpoints/list

此請求還將要求我們指定“端點”作為要列出的實體類型：

{"kind": "endpoint"}

每個端點將在回應內的實體組數中列出，如下所示。請注意，此已經刪除了大部分回應，僅留下了端點“主要”屬性的範例：

在上面的螢幕截圖中，您將在名為“ LAMP MySQL Server ”的端點中看到UUID 28ce21ec-27da-6212-070a-073da9201dc6。我們將如何僅針對該端點執行 runbook呢？

該請求與我們之前的請求非常相似，只是這次我們需要將請求一起提交給適當的JSON有效負載。下面的JSON有效負載使用default_target_reference設置請求的默認端點：

{
  "spec": {
    "args": [
    ],
    "default_target_reference": {
      "kind": "app_endpoint",
      "name": "LAMP MySQL Server",
      "uuid": "28ce21ec-27da-6212-070a-073da9201dc6"
    }
  }
}

發送請求的方式與之前相同，將產生一個回應，該回應顯示出執行日誌UUID，與預期的一樣。現在的區別是，Calm UI中Runbook的默認終點已被JSON有效負載中指定的終結點覆蓋。

分析結果

在我們的請求回應中，您將看到其中一個屬性名為runlog_uuid。與先前記錄的啟動藍圖的過程類似，我們可以查詢執行日誌UUID並獲取有關執行期間發生情況的詳細訊息。對此的GET請求如下：

https://10.133.16.228:9440/api/nutanix/v3/runbooks/runlogs/cfa369e5-fb82-4f22-97aa-610d773e502d

雖然我們可以查看回應並獲取有關狀態的詳細資料，但是我們現在要注意的唯一一件事是執行日誌的狀態–只有相關部分顯示：

{
  "api_version": "3.0",
  "metadata": {},
  "status": {
    "description": "",
    "name": "",
    "state": "SUCCESS",
    "critical": false,
    "action_reference": {
      "kind": "app_action",
      "name": "HAProxy Runbook",
      "uuid": "8ece271f-9147-df66-5721-c93338b3f0dd"
    },
    "type": "workflow_action_runlog",
    "userdata_reference": {
      "kind": "app_user",
      "uuid": "00000000-0000-0000-0000-000000000000",
      "name": "admin"
    },
    "is_runlog_archived": false,
    "reason_list": [],
    "runbook_json": {
      "name": "HAProxy Runbook"
    }
  },
  "spec": {
    "name": "",
    "description": ""
  }
}

在這種情況下，我們可以看到 Runbook 的狀態屬性為“ SUCCESS ”，並且該Runbook的名稱符合預期-HAProxy Runbook。

下載日誌

除了查看透過JSON回應執行的Runbook JSON結果外，我們還可以從Runbook 請求中下載輸出結果。在查看快速範例之前，請看下面的螢幕截圖，並注意以下幾點：

• 每個任務都有其自己的面板，可以單獨查看（由橙色箭頭指示）
• 執行手冊的開始和結束時間都清晰可見
• 輸出記錄到Runbook控制台

但是，可能出於儲存、附加解析或分發等目的，需要下載這些日誌。這就像是向runbooks / runlogs / {uuid} / output / download API發出請求一樣簡單：

https://10.133.16.228:9440/api/nutanix/v3/runbooks/runlogs/cfa369e5-fb82-4f22-97aa-610d773e502d/output/download

回應是可下載的二進製ZIP格式文件。在查看ZIP文件的內容之前，我們先來看一下剛剛執行的Runbook的Calm UI:

上圖執行的 Runbook 的輸出為ZIP格式，如下所示：

這是什麼意思呢？

API請求本身並不複雜。它們遵循最近已發布的Nutanix API的設計目標，即實體列表相同，實體詳細訊息和結果，執行日誌也是如此。更進一步，我們還可以採用其他方法在非常大的環境中列出這些實體-請參閱“五百個通過 v3 API 的VM ”。完全相同的方法適用於端點和執行手冊。

今天的重點是，Calm 3.0.0可能是至今為止最重要的版本。在下一篇文章中，將介紹API自動化以及其他一些Calm 3.0.0新功能的用法。

感謝您的閱讀，祝您有美好的一天！