Docker世界中的配置管理

任何管理多台伺服器的人都可以确認手動執行此任務是浪費時間和風險。 配置管理（CM）已有很長時間了，我沒有一個唯一的原因可以想到為什麼不使用其中一種工具。 問題不在于是否采用其中之一，而是要選擇哪一個。 那些已經擁抱彼此并投入大量時間和金錢的人可能會争辯說，最好的工具就是他們選擇的工具。 通常情況下，選擇會随着時間而變化，而今天一個選擇與另一個選擇的理由可能會有所不同。 在大多數情況下，選擇不是基于可用的選項，而是基于我們誓言要維護的遺留系統的體系結構。 如果要忽略這樣的系統，或者有足夠的勇氣和财力的人願意對其進行現代化，那麼當今的現實将由容器和微服務主導。 在這種情況下，我們昨天做出的選擇肯定不同于我們今天可以做出的選擇。

發動機

CFEngine可被視為配置管理之父。 它建立于1993年，徹底改變了我們伺服器設定和配置的方式。 它最初是一個開源項目，并在2008年釋出第一個企業版時實作了商業化。

CFEngine用C編寫，隻有很少的依賴關系，并且閃電般快。 實際上，據我所知，沒有其他工具能夠克服CFEngine的速度。 那曾經是，現在仍然是它的主要優勢。 但是，它有其缺點，可能是主要的編碼技能要求。 在許多情況下，普通操作員無法使用CFEngine。 它需要C開發人員來管理它。 但這并沒有阻止它在一些大型企業中被廣泛采用。 但是，由于年輕人通常會随着年齡的增長而勝出，是以會建立新的工具，如今由于公司對其進行的投資，很少有人選擇CFEngine而不被“強迫”這樣做。

木偶

後來， 木偶應運而生。 它還開始于一個開源項目，随後是企業版。 與CFEngine相比，它具有模型驅動的方法和較小的學習曲線，是以被認為更“友好操作”。 最後，運維部門可以利用一種配置管理工具。 與CFEngine使用的C語言不同，Ruby被證明更易于推理，并為ops所接受。 CFEngine的學習曲線可能是Puppet進入配置管理市場并慢慢将CFEngine推向曆史的主要原因。 這并不意味着不再使用CFEngine。 是的，而且似乎并不會很快消失，就像Cobol仍然存在于許多銀行和其他金融相關業務中一樣。 但是，它因選擇武器而聲名狼藉。

廚師

然後， 廚師許諾解決木偶的一些細微差别。 确實有一段時間了。 後來，随着Puppet和Chef的受歡迎程度不斷提高，他們進入了“零和遊戲”。 他們中的一個提出新的或某些改進後，另一個人就采納了。 兩者都具有越來越多的工具，這些工具往往會增加其學習曲線和複雜性。 Chef有點“對開發人員友好”，而Puppet則被認為更面向操作和sysadmin類型的任務。 兩者之間都沒有一個明顯的優勢，是以通常根據個人經驗進行選擇。 Puppet和Chef都已經成熟，被廣泛采用（尤其是在企業環境中），并且具有大量的開源貢獻。 唯一的問題是，對于我們要完成的任務而言，它們太複雜了。 他們倆都沒有考慮到容器的設計。 他們都不知道Docker會改變“遊戲”，因為在他們設計之時它并不存在。

到目前為止，我們提到的所有配置管理工具都在嘗試解決采用容器和不可變部署時不應該出現的問題。 我們之前遇到的伺服器混亂不再了。 現在，我們正在嘗試處理大量容器以及數量非常有限的其他任何東西，而不是數百甚至數千個軟體包，配置檔案，使用者，日志等。 這并不意味着我們不需要配置管理。 我們的确是！ 但是，選擇工具應做的範圍要小得多。 在大多數情況下，我們需要一個或兩個使用者才能啟動并運作Docker服務，還有其他一些事情。 其餘的都是容器。 部署正成為一組不同工具的主題，并重新定義了CM應該做什麼的範圍。 Docker Compose和Kubernetes隻是我們今天可能使用的快速增長的部署工具中的少數幾個。 在這種情況下，我們的配置管理選擇應該比其他事情更重視簡單性和不變性。 文法應該簡單易懂，即使對于從未使用過該工具的人也是如此。 不變性可以通過強制執行不需要在目标伺服器上安裝任何東西的推送模型來實作。

Ansible

Ansible試圖解決與其他配置管理工具相同的問題，但是方式卻截然不同。 一個重要的差別是它通過SSH執行所有操作。 CFEngine和Puppet要求将用戶端安裝在應管理的所有伺服器上。 盡管Chef聲稱不支援，但它對無代理運作的支援功能有限。 與不要求伺服器有任何特殊要求的Ansible相比，這本身就是一個巨大的差異，因為SSH幾乎始終存在。 它利用定義良好且使用廣泛的協定來運作需要運作的任何指令，以確定目标伺服器符合我們的規範。 唯一的要求是大多數Linux發行版中已經預安裝了Python。 換句話說，與試圖迫使您以某種方式設定伺服器的競争對手不同，Ansible利用了現有的現實，不需要任何東西。 由于其體系結構，您隻需要在Linux或MacOS計算機上運作的單個執行個體即可。 例如，我們可以通過筆記本電腦管理所有伺服器。 盡管不建議這樣做，并且Ansible可能應在“真實”伺服器上運作（最好是在安裝了其他持續內建和部署工具的同一伺服器上），但筆記本電腦示例說明了其簡單性。 以我的經驗，像Ansible這樣的基于推的系統比我們之前讨論的基于拉的工具更容易推理。

與掌握其他工具所需的所有複雜性相比，Learn Ansible隻需花費一小部分時間。 它的文法基于YAML（又一種标記語言），并且一眼就能看懂一本劇本，即使從未使用過該工具的人也可以了解發生了什麼。 與由開發人員為開發人員編寫的Chef，Puppet尤其是CFEngine不同，Ansible由開發人員編寫，其對象是比其他語言和/或DSL學習能力更好的人。

有人指出，主要缺點是Ansible對Windows的有限支援。 用戶端甚至無法在Windows上運作，并且可在劇本中使用并在其上運作的子產品數量非常有限。 我認為，假設我們正在使用容器，這是一個不利條件。 Ansible開發人員沒有浪費時間嘗試建立一個全面的工具，而是專注于最有效的工具（Linux上通過SSH的指令）。 無論如何，Docker尚未準備好在Windows中運作容器。 可能是在将來，但是在此刻（或至少在我撰寫本文時），這在路線圖上，結果令人懷疑。 即使我們忽略容器及其在Windows上的可疑未來，其他工具在Windows上的性能也比Linux差很多。 簡而言之，Windows體系結構對CM目标的友好程度不如Linux。

我可能已經走得很遠了，在Windows上應該不要太苛刻，并質疑您的選擇。 如果您确實喜歡Windows伺服器而不是某些Linux發行版，那麼我對Ansible的所有贊揚都是徒勞的。 您應該選擇Chef或Puppet，并且除非已經使用，否則請忽略CFEngine。

個人選擇

如果幾年前有人問我應該使用哪種工具，我将很難回答。 今天，如果可以選擇切換到容器（無論是Docker還是其他類型）和不可變的部署，那麼選擇就很明确了（至少在我提到的工具中）。 Ansible（與Docker和Docker部署工具結合使用）在一天中的任何時候都可以赢得勝利。 我們甚至可能會争論是否完全需要CM工具。 舉個例子，人們完全依賴CoreOS，容器和諸如Docker Swarm或Kubernetes之類的部署工具。 我還沒有如此激進的意見，但我認為CM仍然是軍火庫中的寶貴工具，但是。 由于CM工具需要執行的任務範圍，Ansible正是我們需要的工具。 任何更複雜或更難學的東西都是過大的。 我尚未找到維護Ansible劇本有困難的人。 是以，配置管理很容易成為整個團隊的責任。我并不是要說基礎架構應該輕描淡寫（絕對不應該這樣）。 但是，在任何類型的任務中，都有整個團隊參與項目的貢獻是一個很大的優勢，CM也不例外。 CFEngine，Chef和Puppet因其複雜的架構和陡峭的學習曲線而顯得過高。 至少與Ansible相比。

我們簡短介紹過的四個工具絕不是我們唯一可以選擇的工具。 您可能會輕易争辯說，這些都不是最好的，然後投票贊成其他東西。 很公平。 這完全取決于我們要歸檔的首選項和目标。 但是，與其他人不同，Ansible幾乎不會浪費時間。 很容易學習，即使您選擇不采用它，也無法說浪費了很多寶貴的時間。 此外，我們學到的一切都會帶來新的東西，并使我們成為更好的專業人員。

如果您想了解更多有關在Docker中使用Ansible的實際示例 ，請在此部落格中搜尋 。

翻譯自: https://www.javacodegeeks.com/2015/08/configuration-management-in-the-docker-world.html