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

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

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

踏出第一步

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

不幸的是，這兩個考慮真的帶來了一堆蠕蟲。連線到遠端計算機並提升許可權是一件可怕的事情。當您在遠端計算機上安裝代理並使用 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 伺服器的簡短版本看起來像這樣：

1. #ssh-keygen

2. #ssh-copy-id-i .ssh/id_dsa.pub [email protected].computer.ip

3. #ssh [email protected].computer.ip

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

為了在 sudo 中設定許可權提升，您需要編輯 sudoers 檔案。 你不應該直接編輯檔案，而是使用：

1. #sudo visudo

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

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

安裝 Ansible

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

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

1. sudoyum install epel-release

然後安裝 Ansible：

1. sudoyum install ansible

在 Ubuntu 中，首先啟用 Ansible PPA：

1. sudo apt-add-repository spa:ansible/ansible

2. (press ENTER to access the key and add the repo)

然後安裝 Ansible：

1. sudoapt-get update

2. sudoapt-get install ansible

Ansible 主機檔案配置

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

1. #file/etc/ansible/hosts

2. [webservers]

3. blogserver ansible_host=192.168.1.5

4. wikiserver ansible_host=192.168.1.10

5. [dbservers]

6. mysql_1 ansible_host=192.168.1.22

7. pgsql_1 ansible_host=192.168.1.23

方括號內的部分是指定的組。 單個主機可以列在多個組中，而 Ansible 可以指向單個主機或組。 這也是配置檔案，比如純文字密碼的東西將被儲存，如果這是你計劃的那種設定。 配置檔案中的每一行配置一個主機地址，並且可以在 ansible_host 語句之後新增多個宣告。 一些有用的選項是：

1. ansible_ssh_pass

2. ansible_become

3. ansible_become_method

4. ansible_become_user

5. ansible_become_pass

Ansible 保險庫Vault

（LCTT 譯註：Vault 作為 ansible 的一項新功能可將例如密碼、金鑰等敏感資料檔案進行加密，而非明文存放）

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

系統測試

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

1. ansible -m ping all

執行後，如果 ping 成功，您應該看到每個定義的主機顯示 ping 的訊息：pong。 這實際上並沒有測試認證，只是測試網路連線。 試試這個來測試你的認證：

1. ansible -m shell -a 'uptime' webservers

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

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

via: http://www.linuxjournal.com/content/ansible-automation-framework-thinks-sysadmin

作者：Shawn Powers[3] 譯者：Flowsnow 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出