[[270833]]

學(xué)習(xí)如何使 Ansible 自動對一系列臺式機和筆記本應(yīng)用配置。

Ansible 是一個令人驚訝的自動化的配置管理工具。其主要應(yīng)用在服務(wù)器和云部署上，但在工作站上的應(yīng)用（無論是臺式機還是筆記本）卻鮮少得到關(guān)注，這就是本系列所要關(guān)注的。

在這個系列的***部分，我向你展示了 ansible-pull 命令的基本用法，我們創(chuàng)建了一個安裝了少量包的劇本。它本身是沒有多大的用處的，但是為后續(xù)的自動化做了準備。

在這篇文章中，將會達成閉環(huán)，而且在***部分，我們將會有一個針對工作站自動配置的完整的工作解決方案?，F(xiàn)在，我們將要設(shè)置 Ansible 的配置，這樣未來將要做的改變將會自動的部署應(yīng)用到我們的工作站上?，F(xiàn)階段，假設(shè)你已經(jīng)完成了***部分的工作。如果沒有的話，當(dāng)你完成的時候回到本文。你應(yīng)該已經(jīng)有一個包含***篇文章中代碼的 GitHub 庫。我們將直接在之前創(chuàng)建的部分之上繼續(xù)。

首先，因為我們要做的不僅僅是安裝包文件，所以我們要做一些重新的組織工作?，F(xiàn)在，我們已經(jīng)有一個名為 local.yml 并包含以下內(nèi)容的劇本：

- hosts: localhost
  become: true
  tasks:
  - name: Install packages
    apt: name={{item}}
    with_items:
      - htop
      - mc
      - tmux

如果我們僅僅想實現(xiàn)一個任務(wù)那么上面的配置就足夠了。隨著向我們的配置中不斷的添加內(nèi)容，這個文件將會變的相當(dāng)?shù)凝嫶蠛碗s亂。***能夠根據(jù)不同類型的配置將我們的動作play分為獨立的文件。為了達到這個要求，創(chuàng)建一個名為任務(wù)手冊taskbook的東西，它和劇本playbook很像但內(nèi)容更加的流線型。讓我們在 Git 庫中為任務(wù)手冊創(chuàng)建一個目錄。

mkdir tasks

local.yml 劇本中的代碼可以很好地過渡為安裝包文件的任務(wù)手冊。讓我們把這個文件移動到剛剛創(chuàng)建好的 task 目錄中，并重新命名。

mv local.yml tasks/packages.yml

現(xiàn)在，我們編輯 packages.yml 文件將它進行大幅的瘦身，事實上，我們可以精簡除了獨立任務(wù)本身之外的所有內(nèi)容。讓我們把 packages.yml 編輯成如下的形式：

- name: Install packages
  apt: name={{item}}
  with_items:
    - htop
    - mc
    - tmux

正如你所看到的，它使用同樣的語法，但我們?nèi)サ袅藢@個任務(wù)無用沒有必要的所有內(nèi)容?，F(xiàn)在我們有了一個專門安裝包文件的任務(wù)手冊。然而我們?nèi)匀恍枰粋€名為 local.yml 的文件，因為執(zhí)行 ansible-pull 命令時仍然會去找這個文件。所以我們將在我們庫的根目錄下（不是在 task 目錄下）創(chuàng)建一個包含這些內(nèi)容的全新文件：

- hosts: localhost
  become: true
  pre_tasks:
    - name: update repositories
      apt: update_cache=yes
      changed_when: False
 
  tasks:
    - include: tasks/packages.yml

這個新的 local.yml 扮演的是導(dǎo)入我們的任務(wù)手冊的索引的角色。我已經(jīng)在這個文件中添加了一些你在這個系列中還沒見到的內(nèi)容。首先，在這個文件的開頭處，我添加了 pre_tasks，這個任務(wù)的作用是在其他所有任務(wù)運行之前先運行某個任務(wù)。在這種情況下，我們給 Ansible 的命令是讓它去更新我們的發(fā)行版的軟件庫的索引，下面的配置將執(zhí)行這個任務(wù)要求：

apt: update_cache=yes

通常 apt 模塊是用來安裝包文件的，但我們也能夠讓它來更新軟件庫索引。這樣做的目的是讓我們的每個動作在 Ansible 運行的時候能夠以***的索引工作。這將確保我們在使用一個老舊的索引安裝一個包的時候不會出現(xiàn)問題。因為 apt 模塊僅僅在 Debian、Ubuntu 及它們的衍生發(fā)行版下工作。如果你運行的一個不同的發(fā)行版，你要使用特定于你的發(fā)行版的模塊而不是 apt。如果你需要使用一個不同的模塊請查看 Ansible 的相關(guān)文檔。

下面這行也需要進一步解釋：

changed_when: False

在某個任務(wù)中的這行阻止了 Ansible 去報告動作改變的結(jié)果，即使是它本身在系統(tǒng)中導(dǎo)致的一個改變。在這里，我們不會去在意庫索引是否包含新的數(shù)據(jù)；它幾乎總是會的，因為庫總是在改變的。我們不會去在意 apt 庫的改變，因為索引的改變是正常的過程。如果我們刪除這行，我們將在過程報告的后面看到所有的變動，即使僅僅庫的更新而已。***忽略這類的改變。

接下來是常規(guī)任務(wù)的階段，我們將創(chuàng)建好的任務(wù)手冊導(dǎo)入。我們每次添加另一個任務(wù)手冊的時候，要添加下面這一行：

tasks:
  - include: tasks/packages.yml

如果你現(xiàn)在運行 ansible-pull 命令，它應(yīng)該基本上像上一篇文章中做的一樣。不同的是我們已經(jīng)改進了我們的組織方式，并且能夠更有效的擴展它。為了節(jié)省你到上一篇文章中去尋找，ansible-pull 命令的語法參考如下：

sudo ansible-pull -U https://github.com/<github_user>/ansible.git

如果你還記得話，ansible-pull 的命令拉取一個 Git 倉庫并且應(yīng)用它所包含的配置。

既然我們的基礎(chǔ)已經(jīng)搭建好，我們現(xiàn)在可以擴展我們的 Ansible 并且添加功能。更特別的是，我們將添加配置來自動化的部署對工作站要做的改變。為了支撐這個要求，首先我們要創(chuàng)建一個特殊的賬戶來應(yīng)用我們的 Ansible 配置。這個不是必要的，我們?nèi)匀荒軌蛟谖覀冏约旱挠脩粝逻\行 Ansible 配置。但是使用一個隔離的用戶能夠?qū)⑵涓綦x到不需要我們參與的在后臺運行的一個系統(tǒng)進程中，

我們可以使用常規(guī)的方式來創(chuàng)建這個用戶，但是既然我們正在使用 Ansible，我們應(yīng)該盡量避開使用手動的改變。替代的是，我們將會創(chuàng)建一個任務(wù)手冊來處理用戶創(chuàng)建任務(wù)。這個任務(wù)手冊目前將會僅僅創(chuàng)建一個用戶，但你可以在這個任務(wù)手冊中添加額外的動作來創(chuàng)建更多的用戶。我將這個用戶命名為 ansible，你可以按照自己的想法來命名（如果你做了這個改變要確保更新所有出現(xiàn)地方）。讓我們來創(chuàng)建一個名為 user.yml 的任務(wù)手冊并且將以下代碼寫進去：

- name: create ansible user
  user: name=ansible uid=900

下一步，我們需要編輯 local.yml 文件，將這個新的任務(wù)手冊添加進去，像如下這樣寫：

- hosts: localhost
  become: true
  pre_tasks:
    - name: update repositories
      apt: update_cache=yes
      changed_when: False
 
  tasks:
    - include: tasks/users.yml
    - include: tasks/packages.yml

現(xiàn)在當(dāng)我們運行 ansible-pull 命令的時候，一個名為 ansible 的用戶將會在系統(tǒng)中被創(chuàng)建。注意我特地通過參數(shù) uid 為這個用戶聲明了用戶 ID 為 900。這個不是必須的，但建議直接創(chuàng)建好 UID。因為在 1000 以下的 UID 在登錄界面是不會顯示的，這樣是很棒的，因為我們根本沒有需要去使用 ansibe 賬戶來登錄我們的桌面。UID 900 是隨便定的；它應(yīng)該是在 1000 以下沒有被使用的任何一個數(shù)值。你可以使用以下命令在系統(tǒng)中去驗證 UID 900 是否已經(jīng)被使用了：

cat /etc/passwd |grep 900

不過，你使用這個 UID 應(yīng)該不會遇到什么問題，因為迄今為止在我使用的任何發(fā)行版中我還沒遇到過它是被默認使用的。

現(xiàn)在，我們已經(jīng)擁有了一個名為 ansible 的賬戶，它將會在之后的自動化配置中使用。接下來，我們可以創(chuàng)建實際的定時作業(yè)來自動操作。我們應(yīng)該將其分開放到它自己的文件中，而不是將其放置到我們剛剛創(chuàng)建的 users.yml 文件中。在任務(wù)目錄中創(chuàng)建一個名為 cron.yml 的任務(wù)手冊并且將以下的代碼寫進去：

- name: install cron job (ansible-pull)
  cron: user="ansible" name="ansible provision" minute="*/10" job="/usr/bin/ansible-pull -o -U https://github.com/<github_user>/ansible.git > /dev/null"

cron 模塊的語法幾乎不需加以說明。通過這個動作，我們創(chuàng)建了一個通過用戶 ansible 運行的定時作業(yè)。這個作業(yè)將每隔 10 分鐘執(zhí)行一次，下面是它將要執(zhí)行的命令：

/usr/bin/ansible-pull -o -U https://github.com/<github_user>/ansible.git > /dev/null

同樣，我們也可以添加想要我們的所有工作站部署的額外的定時作業(yè)到這個文件中。我們只需要在新的定時作業(yè)中添加額外的動作即可。然而，僅僅是添加一個定時的任務(wù)手冊是不夠的，我們還需要將它添加到 local.yml 文件中以便它能夠被調(diào)用。將下面的一行添加到末尾：

- include: tasks/cron.yml

現(xiàn)在當(dāng) ansible-pull 命令執(zhí)行的時候，它將會以用戶 ansible 每隔十分鐘設(shè)置一個新的定時作業(yè)。但是，每個十分鐘運行一個 Ansible 作業(yè)并不是一個好的方式，因為這個將消耗很多的 CPU 資源。每隔十分鐘來運行對于 Ansible 來說是毫無意義的，除非我們已經(jīng)在 Git 倉庫中改變一些東西。

然而，我們已經(jīng)解決了這個問題。注意我在定時作業(yè)中的命令 ansible-pill 添加的我們之前從未用到過的參數(shù) -o。這個參數(shù)告訴 Ansible 只有在從上次 ansible-pull 被調(diào)用以后庫有了變化后才會運行。如果庫沒有任何變化，它將不會做任何事情。通過這個方法，你將不會無端的浪費 CPU 資源。當(dāng)然在拉取存儲庫的時候會使用一些 CPU 資源，但不會像再一次應(yīng)用整個配置的時候使用的那么多。當(dāng) ansible-pull 執(zhí)行的時候，它將會遍歷劇本和任務(wù)手冊中的所有任務(wù)，但至少它不會毫無目的的運行。

盡管我們已經(jīng)添加了所有必須的配置要素來自動化 ansible-pull，它仍然還不能正常的工作。ansible-pull 命令需要 sudo 的權(quán)限來運行，這將允許它執(zhí)行系統(tǒng)級的命令。然而我們創(chuàng)建的用戶 ansible 并沒有被設(shè)置為以 sudo 的權(quán)限來執(zhí)行命令，因此當(dāng)定時作業(yè)觸發(fā)的時候，執(zhí)行將會失敗。通常我們可以使用命令 visudo 來手動的去設(shè)置用戶 ansible 去擁有這個權(quán)限。然而我們現(xiàn)在應(yīng)該以 Ansible 的方式來操作，而且這將會是一個向你展示 copy 模塊是如何工作的機會。copy 模塊允許你從庫復(fù)制一個文件到文件系統(tǒng)的任何位置。在這個案列中，我們將會復(fù)制 sudo 的一個配置文件到 /etc/sudoers.d/ 以便用戶 ansible 能夠以管理員的權(quán)限執(zhí)行任務(wù)。

打開 users.yml，將下面的的動作添加到文件末尾。

- name: copy sudoers_ansible
  copy: src=files/sudoers_ansible dest=/etc/sudoers.d/ansible owner=root group=root mode=0440

正如我們看到的，copy模塊從我們的倉庫中復(fù)制一個文件到其他任何位置。在這個過程中，我們正在抓取一個名為 sudoers_ansible（我們將在后續(xù)創(chuàng)建）的文件并將它復(fù)制為 /etc/sudoers/ansible，并且擁有者為 root。

接下來，我們需要創(chuàng)建我們將要復(fù)制的文件。在你的倉庫的根目錄下，創(chuàng)建一個名為 files 的目錄：

mkdir files

然后，在我們剛剛創(chuàng)建的 files 目錄里，創(chuàng)建名為 sudoers_ansible 的文件，包含以下內(nèi)容：

ansible ALL=(ALL) NOPASSWD: ALL

就像我們正在這樣做的，在 /etc/sudoer.d 目錄里創(chuàng)建一個文件允許我們?yōu)橐粋€特殊的用戶配置 sudo 權(quán)限?，F(xiàn)在我們正在通過 sudo 允許用戶 ansible 不需要密碼提示就擁有完全控制權(quán)限。這將允許 ansible-pull 以后臺任務(wù)的形式運行而不需要手動去運行。

現(xiàn)在，你可以通過再次運行 ansible-pull 來拉取***的變動：

sudo ansible-pull -U https://github.com/<github_user>/ansible.git

從這里開始，ansible-pull 的定時作業(yè)將會在后臺每隔十分鐘運行一次來檢查你的倉庫是否有變化，如果它發(fā)現(xiàn)有變化，將會運行你的劇本并且應(yīng)用你的任務(wù)手冊。

所以現(xiàn)在我們有了一個完整的可工作方案。當(dāng)你***次設(shè)置一臺新的筆記本或者臺式機的時候，你要去手動的運行 ansible-pull 命令，但僅僅是在***次的時候。從***次之后，用戶 ansible 將會在后臺接手后續(xù)的運行任務(wù)。當(dāng)你想對你的機器做變動的時候，你只需要簡單的去拉取你的 Git 倉庫來做變動，然后將這些變化回傳到庫中。接著，當(dāng)定時作業(yè)下次在每臺機器上運行的時候，它將會拉取變動的部分并應(yīng)用它們。你現(xiàn)在只需要做一次變動，你的所有工作站將會跟著一起變動。這方法盡管有一點不同尋常，通常，你會有一個包含你的機器列表和不同機器所屬規(guī)則的清單文件。然而，ansible-pull 的方法，就像在文章中描述的，是管理工作站配置的非常有效的方法。

我已經(jīng)在我的 Github 倉庫中更新了這篇文章中的代碼，所以你可以隨時去瀏覽來對比檢查你的語法。同時我將前一篇文章中的代碼移到了它自己的目錄中。

在第三部分，我們將通過介紹使用 Ansible 來配置 GNOME 桌面設(shè)置來結(jié)束這個系列。我將會告訴你如何設(shè)置你的墻紙和鎖屏壁紙、應(yīng)用一個桌面主題以及更多的東西。

同時，到了布置一些作業(yè)的時候了，大多數(shù)人都有我們所使用的各種應(yīng)用的配置文件?？赡苁?Bash、Vim 或者其他你使用的工具的配置文件?，F(xiàn)在你可以嘗試通過我們在使用的 Ansible 庫來自動復(fù)制這些配置到你的機器中。在這篇文章中，我已將向你展示了如何去復(fù)制文件，所以去嘗試以下看看你是都已經(jīng)能應(yīng)用這些知識。