[[223376]]

這些年來，我已經寫了許多關于 DevOps 工具的文章，也培訓了這方面的人員。盡管這些工具很棒，但很明顯，大多數都是按照開發人員的思路設計出來的。這也沒有什么問題，因為以編程的方式接近配置管理是重點。不過，直到我開始接觸 Ansible，我才覺得這才是系統管理員喜歡的東西。

喜歡的一部分原因是 Ansible 與客戶端計算機通信的方式，是通過 SSH 的。作為系統管理員，你們都非常熟悉通過 SSH 連接到計算機，所以從單詞“去”的角度來看，相對于其它選擇，你更容易理解 Ansible。

考慮到這一點，我打算寫一些文章，探討如何使用 Ansible。這是一個很好的系統，但是當我第一次接觸到這個系統的時候，不知道如何開始。這并不是學習曲線陡峭。事實上，問題是在開始使用 Ansible 之前，我并沒有太多的東西要學，這才是讓人感到困惑的。例如，如果您不必安裝客戶端程序（Ansible 沒有在客戶端計算機上安裝任何軟件），那么您將如何啟動？ 

踏出第一步

起初 Ansible 對我來說非常困難的原因在于配置服務器/客戶端的關系是非常靈活的，我不知道我該從何入手。事實是，Ansible 并不關心你如何設置 SSH 系統。它會利用你現有的任何配置。需要考慮以下幾件事情：

1. Ansible 需要通過 SSH 連接到客戶端計算機。
2. 連接后，Ansible 需要提升權限才能配置系統，安裝軟件包等等。

不幸的是，這兩個考慮真的帶來了一堆蠕蟲。連接到遠程計算機并提升權限是一件可怕的事情。當您在遠程計算機上安裝代理并使用 Chef 或 Puppet 處理特權升級問題時，似乎感覺就沒那么可怕了。 Ansible 并非不安全，而是安全的決定權在你手中。

接下來，我將列出一系列潛在的配置，以及每個配置的優缺點。這不是一個詳盡的清單，但是你會受到正確的啟發，去思考在你自己的環境中什么是理想的配置。也需要注意，我不會提到像 Vagrant 這樣的系統，因為盡管 Vagrant 在構建測試和開發的敏捷架構時非常棒，但是和一堆服務器是非常不同的，因此考慮因素是極不相似的。 

一些 SSH 場景 

1）在 Ansible 配置中，root 用戶以密碼進入遠程計算機。

擁有這個想法是一個非?？膳碌拈_始。這個設置的“優點”是它消除了對特權提升的需要，并且遠程服務器上不需要其他用戶帳戶。 但是，這種便利的成本是不值得的。 首先，大多數系統不會讓你在不改變默認配置的情況下以 root 身份進行 SSH 登錄。默認的配置之所以如此，坦率地說，是因為允許 root 用戶遠程連接是一個不好的主意。 其次，將 root 密碼放在 Ansible 機器上的純文本配置文件中是不合適的。 真的，我提到了這種可能性，因為這是可以的，但這是應該避免的。 請記住，Ansible 允許你自己配置連接，它可以讓你做真正愚蠢的事情。 但是請不要這么做。 

2）使用存儲在 Ansible 配置中的密碼，以普通用戶的身份進入遠程計算機。

這種情況的一個優點是它不需要太多的客戶端配置。 大多數用戶默認情況下都可以使用 SSH，因此 Ansible 應該能夠使用用戶憑據并且能夠正常登錄。 我個人不喜歡在配置文件中以純文本形式存儲密碼，但至少它不是 root 密碼。 如果您使用此方法，請務必考慮遠程服務器上的權限提升方式。 我知道我還沒有談到權限提升，但是如果你在配置文件中配置了一個密碼，這個密碼可能會被用來獲得 sudo 訪問權限。 因此，一旦發生泄露，您不僅已經泄露了遠程用戶的帳戶，還可能泄露整個系統。 

3）使用具有空密碼的密鑰對進行身份驗證，以普通用戶身份進入遠程計算機。

這消除了將密碼存儲在配置文件中的弊端，至少在登錄的過程中消除了。 沒有密碼的密鑰對并不理想，但這是我經常做的事情。 在我的個人內部網絡中，我通常使用沒有密碼的密鑰對來自動執行許多事情，如需要身份驗證的定時任務。 這不是最安全的選擇，因為私鑰泄露意味著可以無限制地訪問遠程用戶的帳戶，但是相對于在配置文件中存儲密碼我更喜歡這種方式。 

4）使用通過密碼保護的密鑰對進行身份驗證，以普通用戶的身份通過 SSH 連接到遠程計算機。

這是處理遠程訪問的一種非常安全的方式，因為它需要兩種不同的身份驗證因素來解密：私鑰和密碼。 如果你只是以交互方式運行 Ansible，這可能是理想的設置。 當你運行命令時，Ansible 會提示你輸入私鑰的密碼，然后使用密鑰對登錄到遠程系統。 是的，只需使用標準密碼登錄并且不用在配置文件中指定密碼即可完成，但是如果不管怎樣都要在命令行上輸入密碼，那為什么不在保護層添加密鑰對呢？

5）使用密碼保護密鑰對進行 SSH 連接，但是使用 ssh-agent “解鎖”私鑰。

這并不能完美地解決無人值守、自動化的 Ansible 命令的問題，但是它確實也使安全設置變得相當方便。 ssh-agent 程序一次驗證密碼，然后使用該驗證進行后續連接。當我使用 Ansible 時，這是我想要做的事情。如果我是完全值得信任的，我通常仍然使用沒有密碼的密鑰對，但是這通常是因為我在我的家庭服務器上工作，是不是容易受到攻擊的。

在配置 SSH 環境時還要記住一些其他注意事項。 也許你可以限制 Ansible 用戶（通常是你的本地用戶），以便它只能從一個特定的 IP 地址登錄。 也許您的 Ansible 服務器可以位于不同的子網中，位于強大的防火墻之后，因此其私鑰更難以遠程訪問。 也許 Ansible 服務器本身沒有安裝 SSH 服務器，所以根本沒法訪問。 同樣，Ansible 的優勢之一是它使用 SSH 協議進行通信，而且這是一個你用了多年的協議，你已經把你的系統調整到最適合你的環境了。 我不是宣傳“最佳實踐”的忠實粉絲，因為實際上最好的做法是考慮你的環境，并選擇最適合你情況的設置。 

權限提升

一旦您的 Ansible 服務器通過 SSH 連接到它的客戶端，就需要能夠提升特權。 如果你選擇了上面的選項 1，那么你已經是 root 了，這是一個有爭議的問題。 但是由于沒有人選擇選項 1（對吧？），您需要考慮客戶端計算機上的普通用戶如何獲得訪問權限。 Ansible 支持各種權限提升的系統，但在 Linux 中，最常用的選項是 sudo 和 su。 和 SSH 一樣，有幾種情況需要考慮，雖然肯定還有其他選擇。 

1）使用 su 提升權限。

對于 RedHat/CentOS 用戶來說，可能默認是使用 su 來獲得系統訪問權限。 默認情況下，這些系統在安裝過程中配置了 root 密碼，要想獲得特殊訪問權限，您需要輸入該密碼。使用 su 的問題在于，雖說它可以給了您完全訪問遠程系統，而您確實也可以完全訪問遠程系統。 （是的，這是諷刺。）另外，su 程序沒有使用密鑰對進行身份驗證的能力，所以密碼必須以交互方式輸入或存儲在配置文件中。 由于它實際上是 root 密碼，因此將其存儲在配置文件中聽起來像、也確實是一個可怕的想法。 

2）使用 sudo 提升權限。

這就是 Debian/Ubuntu 系統的配置方式。 正常用戶組中的用戶可以使用 sudo 命令并使用 root 權限執行該命令。 隨之而來的是，這仍然存在密碼存儲或交互式輸入的問題。 由于在配置文件中存儲用戶的密碼看起來不太可怕，我猜這是使用 su 的一個進步，但是如果密碼被泄露，仍然可以完全訪問系統。 （畢竟，輸入 sudo 和 su - 都將允許用戶成為 root 用戶，就像擁有 root 密碼一樣。） 

3） 使用 sudo 提升權限，并在 sudoers 文件中配置 NOPASSWD。

再次，在我的本地環境中，我就是這么做的。 這并不完美，因為它給予用戶帳戶無限制的 root 權限，并且不需要任何密碼。 但是，當我這樣做并且使用沒有密碼短語的 SSH 密鑰對時，我可以讓 Ansible 命令更輕松的自動化。 再次提示，雖然這很方便，但這不是一個非常安全的想法。 

4）使用 sudo 提升權限，并在特定的可執行文件上配置 NOPASSWD。

這個想法可能是安全性和便利性的最佳折衷。 基本上，如果你知道你打算用 Ansible 做什么，那么你可以為遠程用戶使用的那些應用程序提供 NOPASSWD 權限。 這可能會讓人有些困惑，因為 Ansible 使用 Python 來處理很多事情，但是經過足夠的嘗試和錯誤，你應該能夠弄清原理。 這是額外的工作，但確實消除了一些明顯的安全漏洞。 

計劃實施

一旦你決定如何處理 Ansible 認證和權限提升，就需要設置它。 在熟悉 Ansible 之后，您可能會使用該工具來幫助“引導”新客戶端，但首先手動配置客戶端非常重要，以便您知道發生了什么事情。 將你熟悉的事情變得自動化比從頭開始自動化要好。

我已經寫過關于 SSH 密鑰對的文章，網上有無數的設置類的文章。 來自 Ansible 服務器的簡短版本看起來像這樣：

# ssh-keygen
# ssh-copy-id -i .ssh/id_dsa.pub remoteuser@remote.computer.ip
# ssh remoteuser@remote.computer.ip

如果您在創建密鑰對時選擇不使用密碼，最后一步您應該可以直接進入遠程計算機，而不用輸入密碼或密鑰串。

為了在 sudo 中設置權限提升，您需要編輯 sudoers 文件。 你不應該直接編輯文件，而是使用：

# sudo visudo

這將打開 sudoers 文件并允許您安全地進行更改（保存時會進行錯誤檢查，所以您不會意外地因為輸入錯誤將自己鎖住）。 這個文件中有一些例子，所以你應該能夠弄清楚如何分配你想要的確切的權限。

一旦配置完成，您應該在使用 Ansible 之前進行手動測試。 嘗試 SSH 到遠程客戶端，然后嘗試使用您選擇的任何方法提升權限。 一旦你確認配置的方式可以連接，就可以安裝 Ansible 了。 

安裝 Ansible

由于 Ansible 程序僅安裝在一臺計算機上，因此開始并不是一件繁重的工作。 Red Hat/Ubuntu 系統的軟件包安裝有點不同，但都不是很困難。

在 Red Hat/CentOS 中，首先啟用 EPEL 庫：

sudo yum install epel-release

然后安裝 Ansible：

sudo yum install ansible

在 Ubuntu 中，首先啟用 Ansible PPA：

sudo apt-add-repository spa:ansible/ansible
(press ENTER to access the key and add the repo)

然后安裝 Ansible：

sudo apt-get update
sudo apt-get install ansible

Ansible 主機文件配置

Ansible 系統無法知道您希望它控制哪個客戶端，除非您給它一個計算機列表。 該列表非常簡單，看起來像這樣：

# file /etc/ansible/hosts
 
[webservers]
blogserver ansible_host=192.168.1.5
wikiserver ansible_host=192.168.1.10
 
[dbservers]
mysql_1 ansible_host=192.168.1.22
pgsql_1 ansible_host=192.168.1.23

方括號內的部分是指定的組。 單個主機可以列在多個組中，而 Ansible 可以指向單個主機或組。 這也是配置文件，比如純文本密碼的東西將被存儲，如果這是你計劃的那種設置。 配置文件中的每一行配置一個主機地址，并且可以在 ansible_host 語句之后添加多個聲明。 一些有用的選項是：

ansible_ssh_pass
ansible_become
ansible_become_method
ansible_become_user
ansible_become_pass 

Ansible 保險庫Vault

（LCTT 譯注：Vault 作為 ansible 的一項新功能可將例如密碼、密鑰等敏感數據文件進行加密，而非明文存放）

我也應該注意到，盡管安裝程序比較復雜，而且這不是在您首次進入 Ansible 世界時可能會做的事情，但該程序確實提供了一種加密保險庫中的密碼的方法。 一旦您熟悉 Ansible，并且希望將其投入生產，將這些密碼存儲在加密的 Ansible 保險庫中是非常理想的。 但是本著先學會爬再學會走的精神，我建議首先在非生產環境下使用無密碼方法。 

系統測試

最后，你應該測試你的系統，以確保客戶端可以正常連接。 ping 測試將確保 Ansible 計算機可以 ping 每個主機：

ansible -m ping all

運行后，如果 ping 成功，您應該看到每個定義的主機顯示 ping 的消息：pong。 這實際上并沒有測試認證，只是測試網絡連接。 試試這個來測試你的認證：

ansible -m shell -a 'uptime' webservers

您應該可以看到 webservers 組中每個主機的運行時間命令的結果。

在后續文章中，我計劃開始深入 Ansible 管理遠程計算機的功能。 我將介紹各種模塊，以及如何使用 ad-hoc 模式來完成一些按鍵操作，這些操作在命令行上單獨處理都需要很長時間。 如果您沒有從上面的示例 Ansible 命令中獲得預期的結果，請花些時間確保身份驗證可以工作。 如果遇到困難，請查閱 Ansible 文檔獲取更多幫助。