Terraform 外掛反向工程與自動化組態檔案生成

Terraform 外掛在 IaC 管理中扮演著橋樑的角色，連線 Terraform 核心與目標平台。理解外掛的查詢邏輯、版本選擇機制以及與 API 和客戶端函式庫的互動方式，是有效運用 Terraform 的關鍵。執行 terraform init 時，Terraform 會根據預設或指定的目錄查詢外掛，並依據版本約束選擇合適的版本。若未找到符合條件的外掛，且外掛由 HashiCorp 發行，Terraform 會自動下載。外掛的運作仰賴平台提供的 API 客戶端函式庫，開發者利用這些函式庫實作 Terraform 與平台的自動化互動。進行反向工程時，使用與 Terraform 核心相同的客戶端函式庫可以確保匯入操作的準確性，並實作與平台的同步。反向工程建模的過程涉及將平台資訊轉化為通用模型，並定義組態檔案中的物件和引數。在 VMware 環境中，可以使用 MOB 作為真實資料來源，透過 REST API 提取 VM 資訊，並生成 HCL 或 JSON 格式的 Terraform 組態檔案。自動化生成組態檔案的過程中，需要考慮 Terraform 提供者版本和基礎設施平台版本的相容性，並在版本更新後重新評估匯入邏輯，確保一致性。此外，匯入指令碼的應用場景多元，包含手動使用、提交至儲存函式庫以及整合到 DevOps 管道中，提升自動化管理的效率。

Terraform 外掛與反向工程建模

在使用 Terraform 進行基礎設施即程式碼（Infrastructure as Code, IaC）管理時，瞭解 Terraform 外掛的工作原理及其反向工程建模過程是至關重要的。這些外掛在 Terraform 的操作中扮演著關鍵角色，而反向工程則能幫助我們更好地理解和操控這些外掛。

外掛安裝與查詢邏輯

當使用者執行 terraform init 命令時，Terraform 核心會在指定的目錄中查詢外掛。這些目錄可以是靜態路徑，也可以是相對於當前工作目錄的相對路徑。以下是一些常見的外掛查詢路徑：

• 位於 Terraform 二進位制檔案的目錄（例如 /usr/local/bin）
• .terraform/plugins/<OS>_<ARCH> 目錄，用於自動下載的 providers
• 使用者外掛目錄：~/.terraform.d/plugins 或 %APPDATA%\terraform.d\plugins

這些路徑中的 <OS> 和 <ARCH> 使用的是 Go 語言標準的作業系統和架構名稱，例如 ubuntu_amd64。

第三方外掛通常應安裝在使用者外掛目錄中，這在大多數作業系統中位於 ~/.terraform.d/plugins，而在 Windows 作業系統中位於 %APPDATA%\terraform.d\plugins。

如果使用 terraform init -plugin-dir=<PATH> 選項（其中 <PATH> 不為空），則會覆寫預設的外掛位置，僅搜尋指定的路徑。

外掛版本選擇

在找到已安裝的外掛後，terraform init 命令會根據組態檔案中的版本約束來選擇外掛版本：

• 如果已經安裝了符合約束的外掛版本，Terraform 會使用最新的符合約束的已安裝版本。
• 如果沒有安裝符合約束的外掛版本，且該外掛是由 HashiCorp 分發的，Terraform 會從 releases.hashicorp.com 下載最新的符合約束的版本並儲存在 .terraform/plugins/<OS>_<ARCH>。

此步驟會被忽略，如果 terraform init -plugin-dir=<PATH> 或 -get-plugins=false 被使用。

API 與客戶端函式庫

大多數平台都支援一組 API 函式庫，允許程式化地與平台互動。開發者在編寫特定提供者時利用這些客戶端函式庫進行自動化互動，並使 Terraform 核心能夠透過提供者來利用這些函式庫。這些客戶端函式庫通常透過 HTTP(s) 與平台互動。

負責管理客戶端函式庫的是特定平台支援開發者。每當客戶端函式庫發生變更時，平台開發者可以更新整合並提供新的提供者版本以包含新增功能。

反向工程中的建模

Terraform 依賴客戶端函式庫來與目標平台互動。如果我們在反向工程模型中使用相同的函式庫來與平台互動以生成組態檔案，就可以實作匯入操作。我們可以利用與 Terraform 核心相同的「真實來源」，並實作與給定平台的互動。

模型範例

反向工程中的建模是指將從第一步提取的資訊轉化為一個通用模型，用於設計新系統。以下是一個範例：

Configuration file/resource (HCL or JSON)
Source-of-truth respective to a platform
Import logic
Database
Network
Backup
Virtual machines (Compute)
Containers
Application
Infrastructure resources

此圖示展示了反向工程中的建模方面。當我們編寫匯入邏輯時，如果能夠利用之前提到的客戶端函式庫來生成點時間組態檔案以將現有資源匯入 Terraform 中。

物件識別

在反向工程建模過程中，另一個重要方面是組態檔案中物件的定義。物件是指我們希望從真實來源提取的一組引數（強制和可選）。正如玄貓之前所描述過，組態檔案是一個由使用者管理的檔案（HCL 或 JSON），其中使用者可以定義基礎設施即程式碼並進行修改以更改資源狀態。

Terraform 操作者可以輕鬆識別那些共同物件引數（強制和可選），這些引數代表他們基礎設施佈署的一大部分。匯入邏輯可以相應地編寫以提取這些物件引數值並將其寫入所需格式（HCL 或 JSON）以供 Terraform 匯入使用。

每個 Terraform 提供者都提供了一份需要在使用者生成組態檔案中定義的一系列強制和可選物件清單。Terraform 對應提供者發布的檔案通常有「資料」、「資源」等不同部分中的物件列表。

控制流程圖示

以下為如何利用已知客戶端函式庫來進行 Terraform 的反向工程操作：

  graph TD;
    C[C]
    G[G]
    A[初始化Terraform] --> B[查詢外掛路徑];
    B --> C{是否指定 -plugin-dir=路徑};
    C -- 是 --> D[查詢指定路徑];
    C -- 否 --> E[查詢預設路徑];
    D --> F[選擇符合約束版本];
    E --> F;
    F --> G{是否已安裝符合版本};
    G -- 是 --> H[使用最新已安裝版本];
    G -- 否 --> I{是否HashiCorp分發};
    I -- 是 --> J[下載最新符合版本];
    I -- 否 --> K[提示錯誤];

內容解密：

此圖示展示了Terraform 在初始化時查詢並選擇外掛的邏輯流程。

1. 初始化Terraform：執行 terraform init 命令開始。
2. 查詢外掛路徑：根據指定或預設路徑查詢已安裝外掛。
3. 是否指定 -plugin-dir=路徑：檢查命令列引數是否指定了自定義外掛目錄。
4. 查詢指定路徑或預設路徑：根據上一步判斷結果決定查詢位置。
5. 選擇符合約束版本：從查詢結果中選擇符合組態檔案版本約束要求之最新版本。
6. 是否已安裝符合版本：檢查是否有已安裝且符合要求之外掛。
7. 是否HashiCorp分發：檢查所需外掛是否由 HashiCorp 分發。
8. 下載最新符合版本或提示錯誤：若為 HashiCorp 分發之外掛則下載最新符合要求之版本；反之則提示錯誤。

探討 Terraform 反向工程的關鍵步驟

在進行 Terraform 反向工程時，理解所需的物件並收集相關的範例列表是非常重要的。這通常是一次性的工作，旨在將現有的基礎設施匯入 Terraform 進行管理。儘管你可能會從源頭收集額外的物件變數，但這並不是問題；實際上，這樣做有助於成功匯入並減少因缺少物件引數而導致的 Terraform 預設值問題。

反向工程的重建與模型定義

在反向工程的這個階段，重建模型並定義組態檔案物件是至關重要的。這個過程涉及撰寫一個匯入指令碼，該指令碼可以代表組態檔案引數以實作成功匯入現有資源。

玄貓認為以下步驟在反向工程與 Terraform 的結閤中尤為重要：

1. 進行全面測試：首先，你需要對樣本資源進行全面測試，以確保它們能夠成功地被 Terraform 管理。這一步驟將幫助你受益於基礎設施自動化。

2. 使用 terraform plan 驗證：每次自動化匯入後，使用 terraform plan 命令來驗證 Terraform 核心不建議任何更改。如果 Terraform 建議任何更改，則表示匯入不成功。這可能是由於組態檔案中缺少物件引數或資源在目標平台上直接進行了更改。

3. 整合到更大的工作流程：如果你的反向工程過程是更大工作流程的一部分，則應該在更大的上下文中驗證你所定義過程的功能，並根據預期結果解決任何問題。

此圖示

  graph TD;
    A[Terraform Plan] -->|No Changes| B[Successful Import];
    A -->|Changes Suggested| C[Create Ticket/Incident];
    C --> D[Ticket/Incident Resolution];

此圖示展示了當使用 Azure DevOps（ADO）觸發 Terraform 匯入並執行 terraform plan時，如果沒有建議更改則表示成功匯入，否則建立票據/事件以解決問題。

Azure DevOps 與事件管理

如果 terraform plan 建議更改，可以建立一個工作流程來為 Terraform 專家生成票據/事件，以修復匯入邏輯並處理組態檔案中缺失或新增的內容。

模擬案例：自動化 VMware VM 的匯入

以下是如何利用反向工程概念自動化 VMware VM 的匯入過程。VMware 的「受控物件瀏覽器」（MOB）作為一個「真實來源」，可以幫助我們完成反向工程。其他平台也有類別似的掛接點，允許在相應平台上進行反向工程。

玄貓舉例說明瞭一個使用 Python 編寫的匯入指令碼，該指令碼從 vCenter MOB 收集所需的引數值。這個指令碼可以透過 REST 請求從 vCenter 物件瀏覽器自動收集資料。收集到的資料是 vCenter 資料函式庫中 VM 物件的一致且精確的快照。指令碼輸出可以是 HashiCorp Command Language（HCL）或 JSON 格式的檔案，作為進一步在 Terraform 中進行匯入的組態檔案。

此圖示

  graph TD;
    A[VM Name & vCenter Details] --> B[Python Import Script];
    B --> C[Data Collection via REST API];
    C --> D[vCenter Object Browser];
    D --> E[HashiCorp Configuration File (HCL or JSON)];

此圖示展示了從 VM 名稱和 vCenter 資訊開始，透過 Python 指令碼收集資料，最終生成 HashiCorp 組態檔案的過程。

內容解密：

玄貓詳細解釋該 Python 指令碼如何透過 REST API 自動化資料收集流程，確保收集到的是精確且即時的 VM 物件資料。生成 HCL 或 JSON 格式的組態檔案可用於進一步在 Terraform 中進行基礎設施管理。

使用 Terraform 進行反向工程的進階應用

自動化取得組態檔案

在現代資訊科技環境中，自動化取得組態檔案是一項關鍵技術，能夠大幅提升效率並減少人為錯誤。這些自動化指令碼（如 import 指令碼）的設計目的在於從特定平台取得資料並將其輸出到組態檔案中，這與其他形式的自動化邏輯類別似。然而，這些指令碼也有其依賴項，例如 Terraform 提供者版本和基礎設施平台版本。

Terraform 提供者版本

Terraform 提供者是連線 Terraform 核心與目標基礎設施平台的媒介。隨著 Terraform 社群不斷改進其提供者，引數值或名稱可能會被新增、修改或移除。因此，為了保持一致的反向工程體驗，建議保持提供者版本穩定。如果需要更新提供者，應遵循反向工程的「檢閱」階段，確保匯入邏輯與新版本的一致性。

基礎設施平台修訂

基礎設施平台是取得平台內物件真實資訊的來源。對於 VMware 平台，MOB（Managed Object Browser）是這些物件的來源。VMware 開發者會不斷修訂或更新其物件庫存。每次升級 vCenter 版本時，可能會影響物件和值的儲存方式。因此，在更新平台（如 vCenter）時，應遵循反向工程的「檢閱」階段步驟，確保匯入邏輯與新版本的一致性。

匯入指令碼的使用案例

匯入指令碼有多種應用場景，可以幫助 IT 管理員和 DevOps 工作流程：

1. 手動消費：輸出組態檔案可以由 IT 管理員手動使用，以便透過 Terraform 實作 DevOps 模式管理應用程式。
2. 儲存函式庫提交：輸出組態檔案可以提交到 DevOps 或 GitHub 儲存函式庫中，供最終使用者直接消費。這些儲存函式庫可以與 Terraform 連線，並處理其他 VM 管理工作流程。
3. DevOps 管道：匯入指令碼的輸出可以直接輸送到 DevOps 管道中，用於進一步自動匯入所需資源並透過 DevOps 系統實作自動組態管理。

這些應用場景展示瞭如何將匯入邏輯整合到多種自動化方案中，以便更高效地管理基礎設施平台。

自動生成時間點組態檔案

瞭解如何將資源反向工程到 Terraform 是非常重要的。以下是一個典型 VMware VM 組態檔案的範例，包含必要和選擇性引數。

{
    "terraform": {
        "required_providers": {
            "vsphere": {
                "source": "local/hashicorp/vsphere",
                "version": "2.3.1"
            }
        }
    },
    "provider": {
        "vsphere": {
            "vsphere_server": "xx.xx.xx.xx",
            "user": "user@domain",
            "password": "xxxx",
            "allow_unverified_ssl": true
        }
    },
    "data": {
        "vsphere_datacenter": {
            "dc": {
                "name": "XXX-YourDatacentername-XXX"
            }
        },
        "vsphere_resource_pool": {
            "pool": {
                "name": "<Cluster>/Resources",
                "datacenter_id": "${data.vsphere_datacenter.dc.id}"
            }
        },
        "vsphere_datastore": {
            "datastore": {
                "name": "<Datastore name where VM resides>",
                "datacenter_id": "${data.vsphere_datacenter.dc.id}"
            }
        },
        "vsphere_network": {
            "network0": {
                "name": "VM Network",
                "datacenter_id": "${data.vsphere_datacenter.dc.id}"
            }
        }
    }
}

內容解密：

這段程式碼展示了一個完整的 JSON 組態檔案範例，適用於 VMware VM 的反向工程。

• Terraform 必要提供者：指定了 Terraform 需要使用的 vsphere 提供者及其版本（2.3.1），並標示為從本地安裝。
• 提供者詳細資訊：包含連線到 vSphere 平台所需的詳細資訊，如伺服器位址、使用者名稱、密碼以及 SSL 驗證設定。
• 資料區段：定義了 VM 的外部資源詳細資訊，如資料中心、資源池、資料儲存和網路等。

自動化取得組態檔案的流程圖

  graph TD
    C[C]
    G[G]
    A[開始] --> B[取得 MOB 資訊]
    B --> C{檢查 Terraform 提供者版本}
    C -->|正確| D[取得組態引數]
    C -->|錯誤| E[更新提供者版本]
    E --> F[重新評估匯入邏輯]
    F --> C
    D --> G{檢查基礎設施平台版本}
    G -->|正確| H[生成組態檔案]
    G -->|錯誤| I[更新平台版本]
    I --> J[重新評估匯入邏輯]
    J --> G
    H --> K[結束]

內容解密：

此圖示展示了自動取得組態檔案的完整流程：

1. 開始：從取得 MOB 資訊開始。
2. 取得 MOB 資訊：從 MOB 中取得必要的物件和值。
3. 檢查 Terraform 提供者版本：確保使用的是正確且穩定的提供者版本。
4. 取得組態引數：從 MOB 中取得所需的組態引數。
5. 更新提供者版本：如果發現提供者版本不正確或需要更新，則進行更新並重新評估匯入邏輯。
6. 檢查基礎設施平台版本：確保使用的是正確且穩定的平台版本。
7. 生成組態檔案：根據取得的資訊生成最終組態檔案。
8. 更新平台版本：如果發現平台版本不正確或需要更新，則進行更新並重新評估匯入邏輯。
9. 結束：完成自動生成組態檔案的過程。

這些步驟和圖示展示瞭如何透過自動化流程來高效地生成和管理基礎設施組態。