Ansible：像系統管理員一樣思考的自動化框架

這些年來，我已經寫了許多關於 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 updatesudo apt-get install ansible

Ansible 主機文件配置

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

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

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

ansible_ssh_passansible_becomeansible_become_methodansible_become_useransible_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 文檔獲取更多幫助。

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

作者：Shawn Powers 譯者：Flowsnow 校對：wxy

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