Ansible最佳實踐管理主機與群組變數

Ansible 是一款功能強大的自動化工具，能簡化複雜的 IT 基礎設施管理工作。有效管理變數是 Ansible 自動化的核心，尤其在多環境佈署時更顯重要。本文將探討 Ansible 變數管理的最佳實踐，包含變數優先順序的理解、目錄結構的規劃、group_by 模組的運用，以及版本控制的重要性。透過這些實務技巧，能提升 Ansible Playbook 的靈活性、可維護性和可靠性，讓自動化組態管理更有效率。

Ansible 最佳實踐：管理主機與群組變數

在 Ansible 中，正確管理變數對於維護可靠且一致的自動化工作流程至關重要。特別是在處理多個環境時，變數的管理變得更加複雜。本章節將探討如何在 Ansible 中最佳地定義和管理主機與群組變數。

理解變數優先順序

在 Ansible 中，變數的優先順序決定了當多個地方定義了相同的變數時，哪一個值會被使用。以下是一些關鍵的優先順序規則：

1. 主機變數優先於群組變數：如果為特定主機定義了變數，它將覆寫任何為該主機所屬群組定義的相同變數。
2. all 群組變數的優先順序最低：all 是一個特殊的群組變數定義，它適用於所有庫存群組。但是，它的優先順序最低，因此任何其他群組或主機變數定義都可以覆寫它。

實踐範例：建立目錄結構與測試變數優先順序

為了演示這些概念，我們將建立一個簡單的開發環境目錄結構，並測試不同變數定義的優先順序。

1. 建立目錄結構

$ mkdir -p inventories/development/group_vars
$ mkdir -p inventories/development/host_vars

2. 建立庫存檔案 在 inventories/development/hosts 中：

[app]
server1 ansible_host=192.168.1.101
server2 ansible_host=192.168.1.102

3. 定義 all 群組變數 在 inventories/development/group_vars/all.yml 中：

---
http_port: 8080

4. 建立 Playbook 在 site.yml 中：

---
- name: Play using best practice directory structure
  hosts: all
  tasks:
    - name: Display the value of our inventory variable
      debug:
        var: http_port

5. 執行 Playbook

$ ansible-playbook -i inventories/development/hosts site.yml

內容解密：

• 首先，我們建立了一個基本的目錄結構來組織我們的庫存和變數。
• 我們在 all.yml 中定義了一個變數 http_port，並在 Playbook 中查詢它的值。
• 當我們執行 Playbook 時，我們看到兩個主機都正確地顯示了 http_port 的值為 8080。

測試變數優先順序

現在，讓我們來測試當在不同群組中定義相同的變數時會發生什麼。

1. 在 app 群組中定義 http_port 在 inventories/development/group_vars/app.yml 中：

---
http_port: 8081

2. 再次執行 Playbook

$ ansible-playbook -i inventories/development/hosts site.yml

內容解密：

• 當我們在 app.yml 中為 app 群組重新定義 http_port 為 8081 時，我們觀察到這個新值被使用，因為 app 群組的定義比 all 群組的定義具有更高的優先順序。
• 這表明 Ansible 正確地根據群組變數的優先順序規則處理了變數的值。

圖表翻譯：

此圖示展示了 Ansible 處理群組變數優先順序的流程。首先，系統會檢查是否存在特定的群組變數定義。如果使用 all 群組變數，則 http_port 被設定為 8080。如果使用 app 群組變數，則 http_port 被設定為 8081。最終，系統會顯示設定的 http_port 值。這個流程清晰地說明瞭 Ansible 如何根據不同的群組變數定義來決定最終使用的變數值。

Ansible變數定義與優先順序的最佳實踐

在Ansible中，變數的定義與使用是自動化組態管理的關鍵部分。正確理解變數的優先順序對於編寫靈活且可維護的Playbook至關重要。本文將探討Ansible中變數的定義方式及其優先順序，並透過具體示例來說明如何有效地管理和使用變數。

變數定義的多樣性

Ansible允許在多個地方定義變數，包括但不限於：

• Inventory檔案：可以直接在Inventory檔案中定義變數。
• group_vars目錄：為特定的群組定義變數。
• host_vars目錄：為特定的主機定義變數。
• Playbook檔案：在Playbook中直接定義變數。

變數優先順序的實驗

為了更好地理解變數的優先順序，我們進行了一系列實驗。

首先，在inventories/development/hosts檔案中定義了一個名為http_port的變數，並指定為8081。

[app]
server1 ansible_host=192.168.1.101 http_port=8081
server2 ansible_host=192.168.1.102

執行Playbook後，輸出的結果顯示http_port的值確實是8081。

接著，我們建立了一個子群組centos和另一個群組newcentos，並將app群組作為它們的子群組。在inventories/development/group_vars/centos.yml和inventories/development/group_vars/newcentos.yml中分別定義了http_port變數，值分別為8082和8083。

# centos.yml
http_port: 8082

# newcentos.yml
http_port: 8083

執行Playbook後，發現http_port的值變成了8083。這是因為Ansible按照字母順序載入群組變數，而newcentos的名稱在字母順序上靠後，因此其定義的變數值覆寫了之前的定義。

http_port: 9090

使用頂層Playbook

在Ansible的最佳實踐中，推薦使用一個頂層的Playbook，通常命名為site.yml。這個Playbook作為入口點，可以包含多個角色和任務，使得自動化流程更加簡潔明瞭。

使用頂層Playbook的好處包括：

• 簡化操作：新操作員可以快速找到入口點，無需深入瞭解整個目錄結構。
• 提高可維護性：透過角色和任務的拆分，使得程式碼更加模組化和可重用。

版本控制與最佳實踐

將Ansible程式碼納入版本控制系統（如Git）是最佳實踐之一。這不僅能夠跟蹤變更歷史，還能夠與團隊成員協作，共同維護自動化程式碼的品質。

版本控制的好處

• 歷史追蹤：能夠檢視每次變更的內容和原因。
• 團隊協作：多個開發者可以平行工作，透過分支和合併功能協同開發。
• 自動化測試與佈署：結合CI/CD工具，實作自動化的測試和佈署流程。

圖表翻譯：

此圖示展示了使用 Git 進行版本控制的基本流程。首先，建立一個 Git 倉函式庫，接著新增檔案到倉函式庫並提交更改。提交後，將更改推播到遠端倉函式庫，以便進行協作開發。這個流程確保了程式碼變更的可追蹤性和團隊協作的高效性。

版本控制工具的最佳實踐

在前面的章節中，我們已經討論過版本控制和測試對於 Ansible 自動化程式碼的重要性。無論是程式碼、inventory（或動態 inventory 指令碼）、自定義模組、外掛、角色還是 playbook 程式碼，都需要進行版本控制。這是因為 Ansible 自動化的最終目標通常是使用 playbook（或一組 playbooks）佈署整個環境，尤其是在佈署到雲端環境時。

為何需要版本控制

任何對 Ansible 程式碼的更改都可能導致環境的重大變化，甚至影響重要的生產服務是否正常運作。因此，維護 Ansible 程式碼的版本歷史記錄至關重要，確保所有人都在使用相同的版本。

選擇版本控制系統

您可以選擇最適合自己的版本控制系統。大多數企業環境中已經存在某種版本控制系統。如果您之前沒有使用過版本控制系統，建議您在 GitHub 或 GitLab 等平臺上註冊免費帳戶，它們提供免費的版本控制倉函式庫，以及更進階的付費方案。

Git 版本控制的基本使用

雖然完整的 Git 版本控制討論超出了本文的範圍，但我們將引導您完成最簡單的使用案例。假設您使用的是 GitHub 上的免費帳戶，如果您使用的是不同的提供商，只需將 URL 更改為您的版本控制倉函式庫主機提供的即可。

安裝 Git 工具

首先，您需要在 Linux 主機上安裝命令列 Git 工具。在 CentOS 上，您可以透過以下命令安裝：

$ sudo yum install git

在 Ubuntu 上，過程同樣簡單：

$ sudo apt-get update
$ sudo apt-get install git

複製 Git 倉函式庫

安裝完成後，您的下一個任務是將 Git 倉函式庫複製到您的機器上。如果您想開始使用自己的倉函式庫，您需要在提供商那裡進行設定。GitHub 和 GitLab 都提供了優秀的檔案，您應該按照這些檔案來設定您的第一個倉函式庫。

設定並初始化後，您可以將倉函式庫複製到本地機器以進行更改。這個本地副本稱為工作副本。您可以按照以下步驟複製它並進行更改（請注意，這些只是假設的例子，讓您瞭解需要執行的命令；您應該根據自己的使用情況進行調整）：

1. 將您的 git 倉函式庫複製到本地機器以建立工作副本，使用類別似以下的命令：

$ git clone https://github.com/<YOUR_GIT_ACCOUNT>/<GIT_REPO>.git
Cloning into '<GIT_REPO>'...
remote: Enumerating objects: 7, done.
remote: Total 7 (delta 0), reused 0 (delta 0), pack-reused 7
Unpacking objects: 100% (7/7), done.

內容解密：

• 這裡使用了 git clone 命令，將遠端 Git 倉函式庫下載到本地機器。
• <YOUR_GIT_ACCOUNT> 和 <GIT_REPO> 需要替換為您的實際 GitHub 賬戶名和倉函式庫名稱。
• 命令執行後，會在當前目錄下建立一個與倉函式庫同名的資料夾，並將倉函式庫中的所有檔案下載到該資料夾中。

2. 切換到您複製的程式碼目錄（工作副本），並進行您需要的程式碼更改：

$ cd <GIT_REPO>
$ vim myplaybook.yml

內容解密：

• cd 命令用於切換當前目錄到剛剛克隆下來的倉函式庫資料夾。
• vim myplaybook.yml 命令使用 vim 編輯器開啟 myplaybook.yml 檔案，以便進行編輯。

3. 在進行程式碼更改後，請務必測試您的程式碼。當您對更改滿意時，使用類別似以下的命令將準備提交的更改檔案新增到暫存區：

$ git add myplaybook.yml

內容解密：

• git add 命令用於將檔案的更改新增到 Git 的暫存區，準備進行提交。
• 這裡增加了 myplaybook.yml 檔案，您也可以新增其他更改過的檔案。

4. 接下來，提交您所做的更改。提交基本上是在倉函式庫中建立一個新的程式碼版本，因此應該附帶有意義的提交訊息（在 -m 開關後用引號指定），如下所示：

$ git commit -m 'Added new spongle-widget deployment to myplaybook.yml'
[master ed14138] Added new spongle-widget deployment to myplaybook.yml
...

內容解密：

• git commit 命令用於提交暫存區中的更改，建立一個新的提交。
• -m 引數後面跟著的是提交訊息，用於描述本次提交所做的更改。
• 提交訊息應該清晰、簡潔且具有描述性。

5. 目前為止，所有更改僅存在於您本地機器的工作副本中。為了讓其他人也能存取這些程式碼，您需要將更新的提交推播到版本控制系統（例如 GitHub）。執行以下命令：

$ git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
...
0d00263..ed14138 master -> master

內容解密：

• git push 命令用於將本地的提交推播到遠端倉函式庫。
• 這樣，其他協作者就可以透過克隆或提取倉函式庫來取得最新的程式碼。

6. 其他協作者可以像我們在步驟1 中一樣克隆您的程式碼。或者，如果他們已經有您倉函式庫的工作副本，他們可以使用以下命令更新他們的工作副本（您也可以這樣做來檢視其他人所做的更改）：

$ git pull

內容解密：

• git pull 命令用於從遠端倉函式庫提取最新的更改，並合併到本地工作副本中。
• 這樣可以保持原生程式碼與遠端倉函式庫的一致性。

圖表翻譯：

此圖示展示了使用 Git 進行協作開發的流程。開發者首先將更改新增到本地倉函式庫，接著提交更改。然後，將提交推播到遠端倉函式庫。其他開發者可以從遠端倉函式庫提取最新的更改，以保持他們本地倉函式庫的更新。這個流程確保了團隊成員之間的程式碼同步和協作。

作業系統與發行版差異的處理

在自動化管理的過程中，我們經常會遇到不同的作業系統（OS）和發行版之間的差異。這些差異可能會對自動化指令碼的編寫和執行造成挑戰。本章節將探討如何使用Ansible來處理這些差異，並確保自動化程式碼能夠在不同的環境中順利執行。

動態建立庫存群組

在編寫Ansible Playbook時，尤其是角色（Roles），我們的目標是使其盡可能廣泛地適用於各種環境。為了實作這一目標，Ansible提供了一個特殊的模組——group_by，它可以根據主機的事實（facts）動態建立庫存群組。

讓我們透過一個簡單的例子來說明這一點。假設我們有一個包含兩個主機的庫存檔案，群組名稱為app：

[app]
server1 ansible_host=192.168.1.101
server2 ansible_host=192.168.1.102

現在，我們建立一個名為osvariants.yml的Playbook，用於演示如何根據OS發行版動態建立群組並執行相應的任務。

---
- name: 演示group_by模組的使用
  hosts: all
  tasks:
    - name: 根據主機事實建立庫存群組
      group_by:
        key: os_{{ ansible_facts['distribution'] }}

在這個Playbook中，我們使用了group_by模組來根據主機的OS發行版建立新的庫存群組。這個模組會根據ansible_facts['distribution']的值動態建立群組，例如，如果主機是Ubuntu，則會被新增到os_Ubuntu群組中；如果是CentOS，則會被新增到os_CentOS群組中。

內容解密：

1. group_by模組：用於根據主機事實動態建立庫存群組。
2. key引數：指定用於建立群組的鍵值，這裡使用了os_加上OS發行版名稱的形式。
3. ansible_facts['distribution']：這是一個由Ansible在收集事實階段取得的主機OS發行版資訊。

根據OS發行版執行特定任務

有了動態建立的群組，我們就可以編寫針對特定OS發行版的Play。例如，我們可以為CentOS和Ubuntu分別編寫安裝Apache的Play。

---
- name: 在CentOS上安裝Apache
  hosts: os_CentOS
  tasks:
    - name: 安裝Apache
      yum:
        name: httpd
        state: present

- name: 在Ubuntu上安裝Apache
  hosts: os_Ubuntu
  tasks:
    - name: 安裝Apache
      apt:
        name: apache2
        state: present

內容解密：

• 我們根據不同的OS發行版，使用不同的套件管理器（yum for CentOS, apt for Ubuntu）來安裝Apache。
• 這種方法使得我們的Playbook能夠靈活地適應不同的作業系統環境。

圖表翻譯：

此圖示展示了根據不同的OS發行版執行特定任務的流程。首先，系統會檢查主機的OS發行版。如果是CentOS，則使用yum套件管理器安裝Apache；如果是Ubuntu，則使用apt套件管理器安裝Apache。最終，無論是哪種作業系統，都能完成Apache的安裝。這個流程清晰地說明瞭如何根據不同的OS環境執行相應的任務。

在不同Linux發行版上自動安裝Apache伺服器

在現代IT基礎設施中，自動化組態管理工具如Ansible扮演著至關重要的角色。透過Ansible，我們可以輕鬆地在多個不同的Linux發行版上佈署和管理軟體。本文將重點介紹如何使用Ansible Playbook在CentOS和Ubuntu這兩種常見的Linux發行版上自動安裝Apache伺服器軟體。

建立動態庫存群組

要實作跨不同Linux發行版的自動化佈署，我們首先需要根據主機的作業系統（OS）型別動態建立庫存群組。這可以透過Ansible的group_by模組來完成。

- name: 演示group_by模組的使用
  hosts: all
  gather_facts: yes
  tasks:
    - name: 根據主機事實建立庫存群組
      group_by:
        key: "os_{{ ansible_distribution }}"

動態建立庫存群組流程

圖表翻譯：

此圖示展示了使用Ansible動態建立庫存群組的流程。首先，Ansible收集所有主機的事實；接著，根據收集到的作業系統資訊建立相應的群組；最後，完成群組建立。

編寫Playbook安裝Apache

建立好動態庫存群組後，我們可以編寫Ansible Playbook來根據不同的OS發行版安裝Apache伺服器軟體。以下是範例Playbook：

- name: 在CentOS上安裝Apache
  hosts: os_CentOS
  become: true
  tasks:
    - name: 在CentOS上安裝Apache
      yum:
        name: httpd
        state: present

- name: 在Ubuntu上安裝Apache
  hosts: os_Ubuntu
  become: true
  tasks:
    - name: 在Ubuntu上安裝Apache
      apt:
        name: apache2
        state: present

內容解密：

1. hosts引數：指定了要執行該Play的主機群組，這裡使用了前面動態建立的群組。
2. become: true：表示需要提升許可權來執行任務，因為安裝軟體需要管理員許可權。
3. yum和apt模組：分別用於在CentOS和Ubuntu上管理軟體套件。
   • 在CentOS上，Apache伺服器軟體包名為httpd。
   • 在Ubuntu上，Apache伺服器軟體包名為apache2。
4. name和state引數：指定了要安裝的軟體套件名稱和狀態。state: present確保軟體套件被安裝。

執行Playbook

執行這個Playbook時，Ansible會根據每個主機的OS發行版自動選擇正確的Play來執行。例如，如果我們的環境中有根據CentOS的伺服器，執行結果將類別似如下：

$ ansible-playbook -i hosts osvariants.yml

PLAY [演示group_by模組的使用] *************************************
TASK [Gathering Facts] *********************************************************
TASK [根據主機事實建立庫存群組] *****************************

PLAY [在CentOS上安裝Apache] ****************************************
TASK [Gathering Facts] *********************************************************
TASK [在CentOS上安裝Apache] ************************************************

從輸出結果可以看出，Playbook首先收集了主機的事實，然後根據OS發行版建立了相應的群組，最後在CentOS主機上安裝了Apache伺服器軟體。

Playbook執行流程

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Ansible最佳實踐管理主機與群組變數

package "Ansible 架構" {
    component [Control Node] as control

    package "Ansible 組件" {
        component [Inventory] as inventory
        component [Playbooks] as playbooks
        component [Roles] as roles
        component [Modules] as modules
    }

    package "Managed Nodes" {
        component [Web Server] as web
        component [DB Server] as db
        component [App Server] as app
    }
}

control --> inventory : 主機清單
control --> playbooks : 任務定義
playbooks --> roles : 引用角色
roles --> modules : 使用模組
control --> web : SSH 連線
control --> db : SSH 連線
control --> app : SSH 連線

note right of control
  無需在目標主機安裝 Agent
  透過 SSH 執行任務
end note

@enduml

圖表翻譯：

此圖示展示了執行Ansible Playbook的流程。首先，Playbook開始執行並收集主機事實；接著，根據收集到的作業系統資訊建立相應的群組；然後，在對應的OS群組上執行安裝Apache的任務；最後，完成安裝並結束。

1. 支援更多Linux發行版：擴充套件Playbook以支援更多不同的Linux發行版，如Fedora、Debian等。
2. 整合更多工：在Playbook中整合更多工，如組態檔案管理、服務啟動和管理等。
3. 使用Ansible Roles：利用Ansible Roles來組織和重用程式碼，使Playbook更加模組化和易於維護。

透過持續最佳化和擴充套件我們的Ansible Playbook，我們可以進一步簡化IT基礎設施的管理和維護工作，提高自動化水平和維運效率。