譯者點評：

微服務的運用，小型化團隊（Two-pizza team）理念的倡導使更多的公司採用研製週期(Lead Time)來衡量DevOps團隊的執行效率。在實際專案研發結束後，服務的部署頻率（Deploy Frequency）不僅說明了運維的穩定性，還能折射出業務的繁榮程度。這一切的背後都離不開運維工具強有力的保障。

讓我們一起學習下Puppet,Chef, Ansible等工具的前世今生，花五分鐘明白如何在容器化的今天，選擇一個靠譜的配置管理工具。
人工進行配置管理工作會耗費大量時間，而且風險極大，但凡是管理過伺服器的技術人員對此都深信不疑。配置管理（CM）工具很早就出現了，我相信只要可以，開發人員都會選擇一款工具進行使用。但問題的關鍵不在於是否要使用CM工具，而是選擇哪一款來使用。對於已經使用過CM工具的開發人員，他們投入了大量的時間和資金，所以很可能會覺得自己使用的工具才是最好的。通常情況下，對工具的選擇會隨著時代的發展不斷變化，今天我們選擇工具的出發點也和以往不同。

大部分案例中，工具的選擇都是基於遺留系統（我們拼命維護的系統）的架構，而非當前可用的工具種類。如果這樣的系統忽略不計，或者說誰有足夠的勇氣和財力對遺留系統進行更新處理，那麼今天佔據統治地位的一定會是容器和微服務，我們以往的選擇與現在的選擇也會截然不同。

CF引擎（CFEngine）

CF引擎可以看作是配置管理之父。1993年誕生的CF引擎，徹底改變了我們對於伺服器設定和配置的方式。一開始CF引擎是一項開源專案，2008年釋出第一個商務版本，自此實現了商業化。

CF引擎是用C語言編寫的，依賴物很少，而且執行速度極快。事實上，據我所知，CF引擎的執行速度是所有工具裡最快的。以前是這樣，現在也是。當然，白璧微瑕，CF引擎也有缺點，對編碼技術的要求可能是其主要的缺點。許多情況下，一般的技術人員不會使用CF 引擎。必須是懂得C語言的開發人員才能夠管理CF引擎。這個缺點並沒有限制CF引擎的發展，很多大的公司企業都採用了CF引擎。但是，隨著新工具的出現，人們的選擇也越來越多，現在已經很少有人會採用CF引擎。

Puppet

隨後出現了Puppet，一開始Puppet也是作為一個開源專案出現的，後來發展成為商用版本。Puppet採用了模型驅動的方法，與CF引擎相比在操作上更加“友好”，學習起來也相對簡單。即便是運營人員也能夠通過簡單學習使用這款配置管理工具。CF引擎使用的是C語言，而Puppet使用的是Ruby語言，相比C語言要更加靈活，而且支援的作業系統也更多。

Puppet的出現使得CF引擎逐漸退出了歷史舞臺，主要原因還是CF引擎對於編碼能力的要求較高。但這並不是說人們已經完全不適用CF引擎了。就像Cobol語言，雖然過時，但還是有一些銀行和金融場景會用到。Puppet也不會立刻就消失不見，只是它已經沒有了往日的榮光。

Chef

終於，Chef出現了，該工具確實解決了Puppet的一些小問題，但只是暫時的。隨著Puppet和Chef逐漸發展流行，兩個工具進入了“零和競爭”的狀態。只要一方開發出新的功能或有了新的改進，另一方就會立刻模仿並進行相同的改動。這樣一來，兩個工具各自的功能都越來越多，複雜性也越來越高，相應的學習起來的難度也越來越大。對比來說，Chef對於開發人員要更加“友好”，而Puppet則更適合運營和系統管理類的任務。兩款工具不分伯仲，開發人員在選擇時通常也是經驗居多，並沒有什麼判斷標準。

Puppet和Chef工具都很成熟，應用都很廣泛（尤其是在商業環境中），開源社群的貢獻也都很多。唯一的問題就是，兩款工具對於我們想要實現的東西來說過於複雜。這兩款工具在設計之初就沒有充分考慮到容器，它們也不會想到這場“博弈”最終會因為Docker而發生變化，因為那個時候Docker還沒有出現。

到目前為止，我們談論的所有工具都是為了解決配置管理問題，但當我們使用容器和不可變部署後，這些問題就應該不復存在了。沒有伺服器冗亂問題、沒有成百上千的程式包、配置檔案、使用者、日誌等等，我們現在面對的是大量容器以及極少量的其他東西。但這並不是說我們不需要配置管理，相反，我們更加需要！只是工具能夠做到的事情相比以前要少很多。大部分情況下，我們只需要一個或兩個使用者、Docker服務正常執行、還有其他很少的東西，剩餘的就是容器，而部署則變成了不同的工具組合，重新定義CM應該做的事情。

今天我們可能會用到很多部署工具，Docker Compose，Mesos，Kubernetes，以及DockerSwarm只是日益湧現的眾多配置管理工具的一部分。在這種背景下，我們對於配置管理的選擇應當注重簡潔性和不可變性，而不是其他東西。語法應當簡單易讀，即便是從來沒有用過工具的人都應當可以看懂；而不可變性可以通過使用push模型來實現（該模型不需要在目標伺服器上安裝任何東西）。

Ansible

配置管理工具基本上都面臨著同樣的問題，而Ansible決定通過非常不同的方式來解決問題。最顯著的一點就是Ansible通過SSH（安全外殼協議）進行所有的操作。使用CF引擎和Puppet時，需要在其管理的所有伺服器上安裝客戶端。雖然Chef聲稱其可以不安裝，但其無代理商（agent-less）版本支援的功能十分有限。與Ansible相比可謂相差萬里，因為SSH的存在，Ansible對伺服器幾乎沒有任何要求。它會使用定義完善且應用廣泛的協議執行所有需要執行的命令，確保目標伺服器與我們的規定相符合。唯一的要求就是Python，而Python也早已預安裝在大部分的Linux作業系統中了。換句話說，其他配置管理工具一直強制你按照某種特定方式設定伺服器。

Ansible則會充分利用現有的東西，而且沒有其他任何要求。Ansible的架構使得你只需要一個簡單的例項，該例項執行在一個Linux或者OS X的電腦上，這樣就可以用筆記本管理所有的伺服器。我們不建議這種做法（筆記本只是為了說明Ansible 的簡潔性），Ansible可能更適合執行在“實體”的伺服器（其他持續整合和持續部署工具最好也安裝在該伺服器上）上。從我個人經驗來看，類似Ansible這樣基於推送系統（push-based system）的工具要優於之前我們討論的那些基於pull的工具。

掌握其他工具的過程可能錯綜複雜，但學習Ansible也就分分鐘的事。它的語法以YAML（是另一種標記語言）為基礎，即便是從未使用過工具的人，只需看一眼介紹就能明白所有東西。Chef、Puppet以及CF引擎都是由開發人員編寫，閱讀人群也都是開發人員。Ansible也是由開發人員編寫，但人們不用學習另一種語言和/或DSL（領域專用語言）就能讀懂。

有些人或許會指出Ansible的主要缺點：對Windows的支援很有限。它的客戶端幾乎不能在Windows系統上執行，而且只有非常有限的很少一部分模組可以執行使用。在我看來，假設我們使用容器，那麼這種缺點反而是一種優點。Ansible的開發人員並沒有浪費時間去開發一個全能型工具，而是專注於該工具最適合的場景（即就是Linux系統中通過SSH實現命令）。無論如何，Docker 目前還不能在Windows系統上執行容器。或許未來可以做到，但現在（或者至少在我寫本書的時候）還只是空中樓閣。即便我們不考慮容器及其未來在Windows上的應用，其他工具在Windows上的表現也都遠遜於在Linux上的表現。簡單來說，Linux的系統架構比Windows系統的架構更適合配置管理工具。

可能我不應該講這麼多，苛求Windows系統，還質疑大家的選擇。如果你真的選擇了Windows伺服器，而非Linux，那麼我所講的所有Ansible的優點都不復存在。對於Windows，你應該選擇Chef或Puppet，此外，忽略CF引擎（除非你已經在使用了）。

結語（final thought）

幾年前，如果有人問我應該選哪個工具，我可能很難回答。但是今天，如果他在使用容器（無論是Docker還是其他容器）和不可變部署，答案十分簡單，就是Ansible（至少在我提到的這幾個裡面，Ansible是最好的），不論是何時何地，只要與Docker和Docker部署工具結合使用，Ansible都是最好的選擇。我們甚至會討論是否還需要CM工具。在某些案例中，人們完全依賴CoreOS、容器、以及類似Docker Swarm或Kubernetes這樣的部署工具。

我並沒有這樣絕對的想法（到目前為止），相反我認為在今天CM工具仍然有重要的價值。只是根據CM工具的目的來看（CM工具需要完成的任務），其它工具相對來說更加複雜，學習起來也更難，Ansible才是我們真正需要的。至今為止我還沒有見過誰看不懂Ansible playbook。這樣一來，配置管理就成為了整個開發小組的責任（因為每個人都能夠使用Ansible）。

我並不說大家要對基礎架構掉以輕心（當然要有足夠的重視）。但是，不論是什麼任務，整個團隊所有開發人員能夠通力合作確實是很顯著地優勢（與以前相比），配置管理方面也應該是這樣。CF引擎、Chef和Puppet的架構都過於複雜，學習起來比較困難，至少與Ansible相比是這樣的。

上面我們簡述的4個工具只是眾多CM工具中的一部分，你大可認為這4個都不是最好的，選擇其他的工具。當然，這些都取決於我們希望達到的目標以及個人的喜好。但是，與其他工具不同的是，Ansible能夠節省大量的時間。學習Ansible十分簡單，即便最後你沒有選擇使用它，你也不會覺得在Ansible上浪費了很多時間。此外，只要我們在不斷學習新知識，就會不斷進步，臻於至善。

普元公眾號：