編者按：本文節選自節選自《基于Linux的企業自動化》第五章。“第5章，使用Ansible構建用于部署的虛擬機模板，通過構建虛擬機模板來探索部署Linux的最佳實踐，虛擬機模板將以實際操作的方式大規模部署在虛擬機管理程序上。”

名詞解釋：

- cloud-init: 提供云實例初始時自定義配置的能力，支持多個發行版和多個平臺；

- docker-compose：業務只需要單個容器場時，可以用docker命令管理。如果業務需要多個容器，可以用docker-compose定義和運行它們；

- Ansible-vault：提供文件和變量的加密能力，可以用于保護密碼等敏感數據。

以下是原文

5.3 使用Ansible來構建和標準化模板

你現在應該有一個基本的Linux映像，以便在企業中部署。如果你選擇下載一個現成的模板（或者確實是使用公共云提供商提供的模板），那么你的映像將是一個非常空白的模板，隨時可以定制。如果你之前選擇構建自己的映像，那么你可能已經選擇執行了少量定制，例如我們之前執行的cloud-init安裝。然而，你會注意到，我們是手工完成這些的，這與我們在本書早期所稱贊的可伸縮、可重復、可審核的流程很不一樣。在我們繼續閱讀本章的這一節時，我們將了解如何使用Ansible自定義一個基本模板，而不管它來自何處。

沒有適合所有人的普適的Linux映像，因此，本章介紹的方法并不一定是最佳的。但是，我們將研究一些與自定義為要部署的映像相關聯的更常見的任務，例如：

將文件傳輸到映像中

安裝軟件包

編輯配置文件

驗證映像

通過這些示例的組合，大多數讀者都應該能夠輕松地根據自己的需求定制自己的映像。讓我們開始更深入地探討這個問題，看看如何將文件傳輸到我們之前使用Ansible創建的虛擬機映像中。

5.3.1 將文件傳輸到映像中

根據作者的經驗，通常需要將文件注入（inject）到操作系統映像中，以確保它滿足給定的一組要求。這些文件可能是簡單的文本文件，例如當前的企業標準每日消息（message of the day）、現有軟件包的配置文件，甚至可能是軟件包中不存在的二進制文件。Ansible可以輕松地處理所有這些問題，所以讓我們看一些具體的例子。一般來說，在角色中編寫Ansible代碼以支持重用和可讀性是一種很好的做法，因此我們將在這里為示例定義一個角色。在這個例子中，我做了以下假設：

我們已經下載/構建了本章上一節中概述的Linux模板。

我們正在虛擬機中運行此裸模板。

此虛擬機的IP地址為192.168.81.141。

虛擬機已使用以下憑據設置了用戶賬戶：

用戶名：imagebuild。

口令：Password。

此賬戶已啟用sudo。

很自然，我們不會分發一個其中包含一個使用這樣的弱口令的啟用sudo的賬戶的云映像，因此我們假設我們只在構建階段使用該賬戶，然后在清理階段將其刪除。Ansible需要能夠連接到遠程主機來執行它的工作，但是它使用的賬戶在本質上可能是暫時的，并且在使用后會被刪除：

1.在我們的示例中，我們將創建一個類似于下面的清單文件。你的實際清單文件無疑會有所不同，為你的映像和環境定制它是留給你的一個練習：

[imagesetup]

192.168.81.141

[imagesetup:vars]

ansible_user=imagebuild

ansible_password=password

ansible_sudo_pass=password

這是一個非常簡單的示例；在許多方面，當我們沒有配置SSH密鑰身份驗證時，它是這個過程所需的最低限度的配置。SSH密鑰通常是處理SSH身份驗證的最佳方法，因為它們提供了一些好處，尤其是任務可以在沒有口令提示的情況下運行。

提示

盡管此清單文件本質上是暫時的，但使用ansible-vault存儲口令仍然是最佳實踐，這里建議這樣做。為了本章的簡單性和減少你需要完成的步驟的數量，我們將不加密口令（采用明文）。

接下來，我們將為角色創建基本目錄結構：

$ mkdir -p roles/filecopyexample/tasks

$ mkdir -p roles/filecopyexample/files

3.現在，讓我們創建幾個示例文件進行復制。首先，創建一個要附加到roles/filecopyexample/files/motd中的當天消息的自定義消息：

------------------------

Enteprise Linux Template

Created with Ansible

-----------------------

4.我們還要為chrony服務創建一個新的配置文件來同步我們的公司時間服務器,在roles/filecopyexample/files/chrony.conf中輸入：

pool ntp.example.com iburst maxsources 4

keyfile /etc/chrony/chrony.keys

driftfile /var/lib/chrony/chrony.drift

logdir /var/log/chrony

maxupdateskew 100.0

rtcsync

makestep 1 3

我們打算將這兩個文件復制到遠程服務器。但是，Ansible并不局限于從Ansible主機復制文件，它還可以將文件從遠程服務器直接下載到目標主機：

1.假設你的構建需要docker-compose，我們可以從內部服務器下載它，如果你的映像服務器可以訪問internet，甚至可以直接從internet下載。假設我們想在映像中安裝docker-compose1.18.0，我們可以指示Ansible直接從https://github.com/docker/compose/releases/download/1.18.0/docker-compose-Linux-x86_64下載。

2.現在，讓我們構建我們的角色來復制兩個文件并把docker-compose下載到我們的映像中，這必須寫在roles/filecopyexample/tasks/main.yml中。此角色的第一部分顯示在以下代碼中，用于跨我們前面討論的兩個配置文件進行復制：

---

- name: Copy new MOTD file, and backup any existing file if it exists

copy:

src: files/motd

dest: /etc/motd

owner: root

group: root

mode: '0644'

backup: yes

- name: Copy across new chrony configuration, and backup anyexisting file if it exists

copy:

src: files/chrony.conf

dest: /etc/chrony.conf

owner: root

group: root

mode: '0644'

backup: yes

然后此角色繼續在VM映像上安裝docker-compose的任務：

- name: Install docker-compose 1.18.0

get_url:

url: https://github.com/docker/compose/releases/download/1.18.0/docker-compose-Linux-x86_64

dest: /usr/local/bin/docker-compose

mode: 0755

owner: root

group: root

因此，我們的角色現在已經完成了，不過請確保為你的環境正確定制它。例如，docker-compose可能有較新的版本，這意味著前面的get_url模塊的url參數將發生更改。

提示

chrony配置文件的路徑可能會因操作系統而異。請在運行前面的劇本之前檢查此項。示例中顯示的路徑適用于CentOS 7系統，正如我們先前構建的系統。

3.最后，我們將在頂級目錄中（從中創建roles/目錄）創建一個供調用的site.yml文件，并運行此角色。這應該包含以下內容：

---

- name: Run example roles

hosts: all

become: yes

roles:

- filecopyexample

4.最后，讓我們用ansible-playbook -i hostssite.yml命令運行我們的示例并查看發生了什么：

如我們所見，changed的狀態告訴我們所有三個文件都已成功傳輸或下載，作為示例，我們可以看到現在可以運行docker-compose了，它是在劇本運行期間安裝的（盡管這需要Docker正確運行，在本例中沒有安裝它）。

顯然，這個示例已經做出了一個基本假設，即在構建階段，chrony包安裝在我們的示例映像上。盡管出于我們前面討論的原因，從一個最小的操作系統映像開始是有意義的，但幾乎可以肯定的是，在基本構建之上安裝一些補充軟件包是有必要的，我們將在下一節中對此進行探討。

5.3.2 安裝軟件包

我們在上一節中已經介紹了如何安裝獨立的二進制文件，如docker-compose，但是如果我們需要實際安裝一些未安裝在我們的基本映像中的其他操作系統軟件包呢？例如，cloud-init在大多數云環境中非常有用，但它沒有包含在我們之前執行的CentOS 7最小安裝中。

在這里，Ansible同樣可以提供幫助，這次，我們將定義一個角色來安裝我們需要的軟件包。我們將重用上一節中的清單文件，并以與之前相同的方式創建一個名為packageinstall的新角色：

1.現在，前面關于復制文件的示例將適用于所有Linux分發版，唯一需要注意的是目標文件存在的位置可能不同。例如，CentOS 7虛擬機映像將在/etc/chrony.conf中安裝chrony配置文件，而Ubuntu 18.04 LTS服務器將在/etc/chrony/chrony.conf中安裝它。除了對copy模塊的dest:參數的這一小改動之外，代碼將保持不變。

遺憾的是，軟件包的安裝會變得更復雜一些。

2.假設我們想在CentOS 7 2示例映像上安裝cloud-init和docker，執行此操作所需的角色可能如下所示：

---

- name: Install the epel-release package

yum:

name: epel-release

state: present

- name: Install cloud-init and docker

yum:

name: "{{ item }}"

state: present

loop:

- cloud-init

- docker

3.我們必須先安裝EPEL存儲庫，然后才能安裝所需的軟件包裝。當我們運行它時，輸出應該是這樣的：

如果你使用的是不同的Linux發行版，那么你需要相應地改變包管理器。例如，在使用apt包管理器的發行版（如Debian或Ubuntu）上，等效的Ansible角色類似于以下代碼塊：

---

- name: Install cloud-init and docker

apt:

name: "{{ item }}"

state: present

loop:

- cloud-init

- docker.io

注意模塊從yum到apt的變化，以及用于Docker容器服務的不同軟件包名。除此之外，劇本幾乎是一模一樣的。

我們可以進一步改進，這種不同導致了需要為兩種不同的操作系統基礎維護兩個不同的角色，但是如果我們可以智能地將它們組合成一個角色呢？幸運的是，Ansible在第一次運行時收集的事實可以用來識別操作系統，從而運行正確的代碼。

我們將重新利用前面的示例代碼，將這兩個安裝組合成一個Ansible角色：

1.代碼的第一部分與前面的示例幾乎相同，只是我們現在已經指定了when子句，以確保它只在基于Debian或Ubuntu的Linux發行版上運行：

---

- name: Install cloud-init and docker

apt:

name: "{{ item }}"

state: present

loop:

- cloud-init

- docker.io

when: ansible_distribution == 'Debian' or ansible_distribution =='Ubuntu'

2.我們再添加兩個在CentOS或Red Hat Enterprise Linux上執行安裝Docker 所需的步驟：

- name: Install the epel-release package

yum:

name: epel-release

state: present

when: ansible_distribution == 'CentOS' or ansible_distribution =='Red Hat enterprise Linux'

- name: Install cloud-init and docker

yum:

name: "{{ item }}"

state: present

loop:

- cloud-init

- docker

when: ansible_distribution == 'CentOS' or ansible_distribution =='Red Hat enterprise Linux'

再次注意每個任務下的when子句，這些具體示例用于根據Ansible在運行的初始部分獲得的事實來確定是否應該運行任務。因此，如果我們現在在Ubuntu系統上運行這個角色，我們會看到以下內容：

3.如你所見，與apt相關的第一個任務是運行的，但是下面基于yum的的兩個任務由于不滿足when子句的條件，已被跳過。現在，如果我們在CentOS 7目標上運行它，我們會看到：

現在情況正好相反：apt任務被跳過，但運行了兩個與yum相關的任務。

通過這種方式，即使在處理幾個不同的基本操作系統時，也可以維護單個角色來安裝一組通用的軟件包需求。將when子句與Ansible事實相結合是一種非常有效的方法，可以確保單個代碼庫在跨各種系統時的正確行為，因此如果你的SOE確實擴展到基于Debian和RedHat的系統，那么你仍然可以輕松簡單地維護代碼。

一旦安裝了補充軟件包，通常必須對其進行配置才能使其有用。在下一節中，我們將探討Ansible在編輯配置文件中的用法。