本文作者 Lorin Hochstein
Netflix的Chaos工程團隊的高級軟件工程師,曾在SendGrid實驗室擔任高級軟件工程師、在Nimbis Services擔任雲服務首席架構師，還曾是加州大學信息科學院計算機科學家。他在麥吉爾大學取得計算機工程學學士學位，在波士頓大學取得電子工程學碩士學位，在馬里蘭大學取得計算機科學的博士學位。
在 IT 行業工作其實挺糾結的。向客戶交付軟件的時候，不只是在一臺計算機上一鍵安裝了事。 實際上，慢慢的，我們都變成了系統工程師。
- 我們部署應用的時候需要把不同的服務組合起來，這些服務運行在一組分佈式計算資源上，並且使用不同的網絡協議相互通信。一個典型的應用一般由 Web 服務、 應用服務、內存緩存系統、任務隊列、消息隊列、SQL 數據庫、NoSQL 數據庫以及負載均衡等幾部分組成。
- 我們還得保證服務具有適當的冗餘。這樣出現異常（放心，異常一定會有的）的時候，我們的軟件可以平滑地處理這些異常。其次，我們還需要部署和維護配套服務，一般包括日誌系統、監控系統、數據分析系統以及與我們交互通信的第三方服務，比如，管理虛擬機實例的 IaaS 終端。
- 設想一下純手工地配置這些服務的場景 ：使用 SSH 登錄到一臺服務器，安裝軟件包， 編輯配置文件，然後換下一臺繼續。光想想就痛苦，特別是在重複到第三四次的時候，你會感到特別費時費力，枯燥乏味還特別容易出錯。而且還有很多更復雜的情況，比如在你的應用中使用了 OpenStack，全部手動來完成絕對是一個很瘋狂的想法。幸運的是，現在有一個優雅的辦法。
如果你贊同配置管理理念，並且正在考慮採用 Ansible 作爲你的配置管理工具的。不管你是準備向生產環境部署自己代碼的開發者，還是尋求更好的自動化解決方案的系統管理員，我保證你會愛上 Ansible 的。它就是解決你問題的完美解決方案。
溯源 Ansible Ansible 出自科幻小說，是虛構的一種以超光速傳遞信息的通信裝置。Ursula K. Le Guin 在他的 Rocannon’s World 一書中發明了這個概念。後來很多科幻作家都曾借鑑過這個概念。實際上，Ansible 的作者 Michael DeHaan 是從 Orson Scott Card 撰寫的 Ender’s Game 一書中借鑑來的。在那本書中，Ansible 可以跨越任何距離同時控制無數飛船，就好像在我們的世界中控制海量遠程服務器一樣。
易讀的語法
回憶一下，Ansible 的配置管理腳本叫作 playbook。playbook 的語法是基於YAML構建的，YAML 是一種以易於人類讀寫爲設計理念的數據格式語言。從某種程度上說，YAML 至於 JSON 就好像 Markdown 至於 HTML。
我喜歡把 Ansible 的 playbook 看作可執行的文檔。它就像一個 README 文件，裏面記錄了部署你的軟件所必須使用的命令，只不過這些指令永遠不會過期，因爲它們同時也是直接執行的代碼。
遠程主機無須安裝依賴
需要被 Ansible 管理的服務器需要安裝 SSH 和 Python 2.5 或更新版本，或者安裝了simplejson 庫的 Python 2.4。除此以外，不再需要預裝任何代理程序或其他軟件了。控制服務器（用於控制遠程服務器的那臺）需要安裝 Python 2.6 或者更高版本。
基於推送模式
以 Chef 和 Puppet 爲代表的使用 agent 的配置管理系統，默認採用拉取模式。安裝在服務器上的 agent 程序定期檢查中心服務器，拉取配置信息。讓配置變更能在服務器上生效大概需要經過如下過程。
- 你 ：對配置管理腳本進行變更。
- 你 ：將變更內容更新到配置管理中心服務。
- 服務器上的 agent 程序 ：當週期計時器到期時喚醒。
- 服務器上的 agent 程序 ：連接到配置管理中心服務。
- 服務器上的 agent 程序 ：下載新的配置管理腳本。
- 服務器上的 agent 程序 ：在本地執行那些改變服務器狀態的配置管理腳本。
與此相反，Ansible 默認採取的是基於推送的模式。配置變更步驟如下所示。
- 你 ：在 playbook 中進行變更。
- 你 ：運行新的 playbook。
- Ansible ：連接到服務器並執行那些改變服務器狀態的模塊。
一旦運行 ansible-playbook 命令，Ansible 馬上連接到遠程服務開始幹活。
基於推送模式的方式最突出的優點是 ：直接由你來控制變更在服務器上發生的時間。你不需要呆呆地等計時器過期。拉取模式的擁躉號稱拉取模式在大規模服務器場景下具有較好的擴展性，並且更適合處理新服務器隨時上下線的場景。然而，Ansible 已經成功地在具有成千上萬個節點的生產環境中工作，並且可以完美支持服務器動態上下線的場景。
如果你真的更喜歡拉取模式，Ansible 可以使用 ansible-pull 工具實現，它是在 Ansible官方版本內一起發佈的。
使用Ansible管理小規模環境
沒錯，Ansible 可以用於管理成百上千個節點。但是，它真正吸引我的地方是應用於小規模集羣時的易用性。使用 Ansible 管理單一節點非常簡單，你只需編寫一個 Ansible 腳本文件。Ansible 遵循了 Alan Kay 的格言“簡單的事情應該保持簡單，複雜的事情應該做到可能”。
內置模塊
你可以使用 Ansible 在你管理的遠程服務器上執行任何 shell 命令，但是 Ansible 真正強大的地方在於內置的模塊集。使用模塊你可以 ：安裝某個軟件包、重啓某個服務或者複製某個配置文件。
稍後我們就會看到，Ansible 模塊是聲明式的。模塊聲明它可以用於描述你希望服務器所處於的狀態。例如，你打算藉助用戶模塊保證擁有一個名爲 deploy 且所屬組爲 web 的賬號。如下所示 ：
user: name=deploy group=web
另外，模塊是冪等的。如果用戶 deploy 不存在，Ansible 就創建它。如果它存在，Ansible 不會做任何事。冪等性是一個非常讚的特性，因爲它意味着向同一臺服務器多次執行同一個 Ansible playbook 是安全的。相對於一般運維團隊自己編寫的 shell 腳本來說，這是一個非常大的優勢。運維團隊自己編寫的腳本在第二次執行的時候很可能會帶來不一樣（往往是預期以外的）的影響。
關於收斂性 配置管理領域的書籍往往會提到收斂性的概念。與配置管理中的收斂性最相關的是Mark Burgess 以及他編寫的配置管理系統 CFEngine。對於一個配置管理系統，如果它具有收斂性，那麼這個系統也許需要多次運行才能將服務器置於期望的狀態。而在這個過程中的每一次運行，都會使服務器更接近於那個狀態。 收斂性的想法並沒有被真正應用到 Ansible 中，Ansible 並沒有需要多次運行來配置服務器的設計。相對的，Ansible 的模塊實現的行爲是 ：只需要運行 playbook 一次即可以將每臺服務器都置爲期望的狀態。
非常輕量的抽象層
某些配置管理工具提供一個抽象層，這樣你就可以使用相同的配置管理腳本對運行不同操作系統的服務器進行管理。例如 ：配置管理工具提供一個 package 抽象去替代 yum 或者 apt 這樣的包管理器，這樣就無須處理包管理器的差異了。
Ansible 的處理方式不太一樣。如果在基於 apt 的系統上安裝軟件包，那麼你還是得使用apt 模塊，在基於 yum 的系統上安裝軟件包使用 yum 模塊。
雖然聽起來這種設計是一個缺點，但從工程實踐上來看，我認爲它反倒使得 Ansible 更易用。Ansible 不需要我們去學習一套新的用於屏蔽不同操作系統差異的抽象。這使得Ansible 需要學習的東西更少，在開始使用它之前幾乎不需要其他必備知識。
如果你真的希望有這層抽象，可以在編寫自己的 Ansible playbook 時，實現針對不同操作系統的遠程服務器運行不同的操作。但是實際工作中我儘量避免這麼做，我會更專注於編寫用於某個特定的操作系統（比如 Ubuntu）的 playbook。
在 Ansible 社區，複用的基本單元是模塊。由於模塊的功能範圍非常小，並且可以只針對特定的操作系統，所以非常易於實現定義明確且易於分享的模塊。Ansible 項目對於接受社區貢獻的模塊這點上非常開放。我也貢獻過幾個模塊，因此對此瞭如指掌。
Ansible playbook 在設計上並不考慮在不同的系統環境之間複用。在第 7 章我們將會討論 role，它將 playbook 整合爲更可複用的對象，此外還有非常便利的 Ansible Galaxy，它是一個在線的 role 倉庫。
在實際工作中，每家公司組建服務器的方式都會有一些不同，根據你的公司的情況編寫playbook 會比嘗試複用別人的 playbook 更合適。但我相信翻閱其他人分享的 playbook範例對於理解工作原理有重要價值。
Ansible 軟件與 Ansible 公司是什麼關係 Ansible 這個名字不僅指代軟件，還是運作這個開源軟件的公司的名字。Ansible軟件的創始人 Michael DeHaan 同時也是 Ansible 公司的前 CTO。爲了防止混淆，我們把軟件稱作Ansible，而公司則使用“Ansible 公司”來稱呼。 Ansible 公司主要經營 Ansible 的培訓和諮詢服務。除此之外，還有一個叫作Ansible Tower 的 Web 管理工具作爲專有軟件產品。2015 年 10 月，Red Hat 收購了 Ansible 公司。
本文節選自《奔跑吧Ansible（第2版）：探索自動化配置與部署捷徑》一書。Ansible 的設計初衷是在若干服務器上從零開始執行所有必需的配置與操作，因爲使用極度簡便的模型來實現對各種操作按照所需順序執行的控制，它成爲自動化運維、DevOps的最佳配置。本書由知名互聯網企業SRE團隊精心翻譯，基於真實生產環境案例，涵蓋大量官方文檔缺少的重要概念和主題，覆蓋編寫playbook、管理遠程服務器、探索內置模塊等高級內容。“奶牛書”的營養美味，讓閱讀原文帶你酣暢體會！。
- 內容簡介：Ansible是近年來急速發展的開源配置管理工具。在Ansible之前，行業中已經有很多開源配置管理工具了，特別是大名鼎鼎的Puppet，簡直是配置管理工具中的超級star。然而，Ansible依靠它的簡單易用、“零依賴”以及弱抽象獲得了無數開發者和運維工程師的青睞。遺憾的是，除了官方文檔外，Ansible相關的優秀文檔鳳毛麟角，而本書恰恰就是爲了緩解這一問題而編寫的。作者在《奔跑吧Ansible（第2版）：探索自動化配置與部署捷徑》中演示瞭如何使用Ansible管理接近真實生產環境的案例。既展現了Ansible的強大功能，又能夠幫助讀者快速入門與上手，《奔跑吧Ansible（第2版）：探索自動化配置與部署捷徑》非常適合作爲官方文檔的補充或者搭配閱讀。特別值得一提的是，《奔跑吧Ansible（第2版）：探索自動化配置與部署捷徑》第2版還增加了管理Windows服務器和網絡設備方面的章節，並重新編寫了Docker相關章節，及時地對第1版中的不足進行了改進。
