chusiang
commented
7 years ago - [ ] 有空應該把這篇文章整理至 http://ansible.tw 上的才是。
Open chusiang opened 7 years ago
chusiang
commented
7 years ago chusiang
commented
6 years ago 來連結一下這份早期的 Ansible FAQ 提交紀錄。
https://github.com/ansible/ansible.github.com/blob/4a2bf7f60a020f0d0a7b042056fc3dd8716588f2/faq.html
今日回頭看 Ji ZHANG's Blog，才發現簡體中文的譯文已被移除了。 :joy:
chusiang
commented
5 years ago 原來 Ansible 這個單字，是從「answerable」這個單字演變而來的！
Ursula K. Le Guin coined the word "ansible" in her 1966 novel Rocannon's World. The word was a contraction of "answerable", as the device would allow its users to receive answers to their messages in a reasonable amount of time, even over interstellar distances.
Orson Scott Card 作者在《Ender's Game (安德的遊戲) 》系列作品中，也沿用 Ansible 這個單字作為比光速還要快的通訊裝置 (Faster-than-light communicatio)。
Orson Scott Card, in his 1977 novelette and 1985 novel Ender's Game and its sequels, used the term "ansible" for his own fictitious communication device. In Ender's Game, a character stated that "somebody dredged the name ansible out of an old book somewhere."
https://en.wikipedia.org/wiki/Ansible#Orson_Scott_Card's_works
如果要用一句話來說明何為 Ansible？那麼凍仁會說它是一個虛構的超光速即時通訊裝置。
Reference:
=> 原文連結 Ansible FAQ | Ji ZHANG's Blog <=
本文是從原 Ansible 官網的 FAQ 頁面翻譯而來，網站改版後該頁面已無法訪問，但可以從 Github 歷史提交中獲得。翻譯這篇原始 FAQ 文檔是因為它陳述了 Ansible 這款工具誕生的原因，設計思路和特性，以及與 Puppet、Fabric 等同類軟件的比較，可以讓我們對 Ansible有一個整體的瞭解，所以值得使用者一讀。
目錄
為什麼命名為「Ansible」？
我最喜愛的書籍之一是奧森·斯科特·卡特的《安德的遊戲》。在這本書中，「Ansible」是一種能夠跨越時空的即時通訊工具。強烈推薦這本書！
Ansible 受到了誰的啟發？
我在 Red Hat 任職期間主要開發 Cobbler，很快我和幾個同事就發現在部署工具（Cobbler）和配置管理工具（cfengine、Puppet 等）之間有一個空缺，即如何更高效地執行臨時性的任務。雖然當時有一些並行調用 SSH 腳本的方案，但並沒有形成統一的 API。所以我們（Adrian Likins、Seth Vidal、我）就開發了一個 SSH 分佈式腳本框架 —— Func。
我一直想在 Func 的基礎上開發一個配置管理工具，但因為忙於 Cobbler 和其他項目的開發，一直沒有動手。在此期間，John Eckersberg 開發了名為 Taboot 的自動化部署工具，它基於 Func，採用 YAML 描述，和目前 Ansible 中的 Playbooks 很像。
近期我在一家新公司嘗試引入 Func，但遇到一些 SSL 和 DNS 方面的問題，所以想要開發一個更為簡單的工具，吸收 Func 中優秀的理念，並與我在 Puppet Labs 的工作經驗相結合。我希望這一工具能夠易於學習，且不需要進行任何安裝步驟。使用它不需要引入一整套新的理論，像 Puppet 和 Chef 那樣，從而降低被某些運維團隊排擠的可能。
我也曾參與過一些大型網站的應用部署，發覺現有的配置管理工具都太過複雜了，超過了這些公司的需求。程序發佈的過程很繁複，需要一個簡單的工具來幫助開發和運維人員。我不想教授他們 Puppet 或 Chef，而且他們也不願學習這些工具。
於是我便思考，應用程序的部署就應該那麼複雜嗎？答案是否定的。
我是否能開發一款工具，讓運維人員能夠在 15 分鐘內學會使用，並用自己熟悉的語言來擴展它？這就是 Ansible 的由來。運維人員對自己的服務器設施最清楚，Ansible 深知這一點，並將同類工具中最核心的功能提取出來，供我們使用。
Ansible 不僅易於學習和擴展，它更是集配置管理、應用部署、臨時任務等功能於一身。它非常強大，甚至前所未有。
我很想知道你對 Ansible 的看法，到郵件列表裡發表一下意見吧。
與同類軟件比較
Func？
Ansible 默認使用 SSH，而非 SSL 和守護進程，無需在遠程服務器上安裝任何軟件。你可以使用任何語言編寫插件，只要它能夠返回 JSON 格式即可。Ansible 的 API 深受 Func 的影響，但它和 Func 相較提供了配置管理和多節點統一化部署（Playbooks）等功能。
Puppet？
首先我要強調的是，如果沒有 Puppet，就不會有 Ansible。Puppet 從 cfengine 中吸收了配置管理的概念，並更合理地加以實現。但是，我依舊認為它可以再簡單一些。
Ansible 的 playbook 是一套完整的配置管理系統。和 Puppet 不同，playbook 在編寫時就隱含了執行順序（和 Chef 類似），但同時也提供了事件機制（和 Puppet 類似），可以說是結合了兩者的優點。
Ansible 沒有中心節點的概念，從而避免了驚群效應。它一開始就是為多節點部署設計的，這點 Puppet 很難做到，因為它是一種「拉取」的架構。Ansible 以「推送」為基礎，從而能夠定義執行順序，同時只操作一部分服務器，無需關注它們的依賴關係。又因為 Ansible 可以用任何語言進行擴展，因此並不是只有專業的程序員才能為其開發插件。
Ansible 中資源的概念深受 Puppet 的啟發，甚至「state」這一關鍵字直接來自 Puppet 的「ensure」一詞。和 Puppet 不同的是，Ansbile 可以用任何語言進行擴展，甚至是 Bash，只需返回 JSON 格式的輸出即可。你不需要懂得 Ruby。
和 Puppet 不同，Ansible 若在配置某台服務器時發生錯誤，它會立即終止這台服務器的配置過程。它提倡的是「提前崩潰」，修正錯誤，而非最大化應用。這一點在我們需要配置包含依賴關係的服務器架構時尤為重要。
Ansible 的學習曲線非常平滑，你不需要掌握編程技能，更不需要學習新的語言。Ansible 內置的功能應該能夠滿足超過 80% 的用戶需求，而且它不會遇到擴展性方面的瓶頸（因為沒有中心節點）。
如果系統中安裝了 factor，Ansible 同樣支持從中獲取系統信息。Ansible 使用 jinja2 作為模板語言，類似於 Puppet 使用 erb 文件作為模板。Ansible 可以使用自己的信息收集工具，因此 factor 並不是必需的。
Chef？
Ansible 與 Chef 的區別和 Puppet 類似。Chef 的配置非常困難，而且需要你掌握 Ruby 語言。也因為如此，Chef 在 Rails 使用者中很流行。
Ansible 是按照編寫順序來執行任務的，而不是顯示地定義依賴關係，這點和 Chef 相似。但 Ansible 更進一步，它支持事件觸發，比如修改了 Apache 的配置文件，Apache 就會被重啟。
和 Chef 不同的是，Ansible 的 playbook 不是一門編程語言，而是一種可以存儲的數據結構。這就意味著你的運維工作不是一項開發型的任務，測試起來也相對簡單。
無論你有怎樣的語言背景，都可以使用 Ansible。Chef 和 Puppet 有超過六萬行的代碼，而 Ansible 則是一段小巧簡單的程序。我相信這一點會使得 Ansible 更加健壯和可靠，並匯聚一批活躍的社區貢獻者——因為任何人都可以提交補丁或是模塊。
Ansible 同樣支持從 ohai 中獲取系統信息，當然這同樣不是必需的。
Capistrano/Fabric？
這些工具並不適合用作服務器配置工具，它們主要用於應用程序的部署。
而 Ansible 則提供了完整的配置管理，以及在擴展性方面提供了一些高級特性。
Ansible playbook 的語法簡介只佔一個 HTML 頁面，有著非常平緩的學習曲線。由於 Ansible 使用了「推送」的設計，因此對系統管理員（不僅僅是開發者）同樣適用，並能用它處理各種臨時性的任務。
其它問題
Ansible 的安全性如何？
Ansible 沒有守護進程，主要使用 OpenSSH 進行通信，這是一款已被反覆檢驗並廣泛使用的軟件。其它工具都會在遠程服務器上以 root 用戶運行守護進程，因此相較於這些工具，Ansible 會更為安全，且無需擔心網絡方面的問題。
如果你的中心節點遭到入侵（或是被惡意員工登錄），只要你是使用 SSH-agent、或是經過加密的密碼，那你的密鑰仍然是被鎖定的，別人無法操控你的節點。而對於 Chef、Puppet 等工具來說，一旦配置文件遭到篡改，那危及的將是整個網絡。
此外，由於 Ansible 沒有守護進程，可以節省下一部分內存和計算資源，這對需要最大化性能的用戶來說也是一個優點。
Ansible 如何擴展？
無論是在單次執行模式還是 playbook 模式下，Ansible 都可以並行執行任務，這要感謝 Python 提供的多進程處理模塊。
你可以自行決定要一次性配置 5 台還是 50 台服務器，這取決於服務器的計算能力，以及你想要多快完成任務。
由於沒有守護進程，所以平時不會佔用任何資源，而且你不用擔心一次性有太多節點一起從控制節點上獲取信息。
對於 SSH，Ansible 默認使用 paramiko 庫，當然也能使用原始的 openssh。Ansible 可以利用 SSH 的 ControlMaster 特性來重用網絡連接。
當要維護上萬個節點時，單個 Ansible playbook 可能不太合理，這時你就能使用 Ansible 的「拉取」模式。這種模式下需要配合 git 和 cron，可以擴展到任意多台服務器。「拉取」模式可以使用本地連接，或是 SSH。關於這個模式的詳細說明可以在幫助文檔的「Advanced Playbooks」一節查閱。即使在「拉取」模式下，你同樣能夠享受到 Ansible 的種種便利。
如果你想進一步探討擴展性，可以加入到郵件列表中。
是否支持 SSH 以外的協議？
目前 Ansible 支持 SSH 和本地連接，但它的接口實際上是非常易於擴展的，因此你可以編寫補丁來使 Ansible 運行於消息系統或 XMPP 協議之上。
如果你有任何建議，可以加入到郵件列表中一起探討。Ansible 中對於連接的管理都已單獨抽象出來，有很強的可擴性。
Ansible 的適用場景有哪些？
最適場景？使用 playbook 進行多節點云主機部署；從一個初始的操作系統開始部署應用，或是配置一個現有的系統。
Ansible 同樣適用於執行臨時性的任務，能夠用於各類 Unix-like 系統，因為它使用的就是系統本身自帶的工具，無需安裝額外軟件。
你還可以用 Ansible 來編寫各類腳本，用於收集信息、執行各種任務，對 QA、運維等團隊均適用。