配置管理工具故障轉移行為
我目前正在嘗試向我的管理層出售“DevOps”，我正在調查的一件事是配置管理工具。對我們來說最重要的事情之一是我們擁有一個具有高可用性和良好故障轉移行為的系統。
- 對於 CF-Engine 這不是問題，因為每個節點都可以配置為作為伺服器執行，如果伺服器不可用，執行將繼續。
- 對於 Puppet，您可以選擇 Master/Masterless 模式及其優缺點。
- 對於 Chef，初始執行需要主伺服器獲取策略，但之後如果主伺服器不可用，任何執行都將繼續使用目前策略。
- 對於 Salt，如果主伺服器出現故障，則不會強制執行配置，因為所有操作都在主伺服器上完成
- 對於 Ansible（如 salt），如果主伺服器出現故障，則不再強制執行配置，因為所有操作都由主伺服器完成
我沒有將 Windows PowerShell DSC 包括在此列表中，因為我目前的使用者案例是我將使用 PowerShell DSC 來協助管理 Windows 系統，其中 Puppet、Chef、Ansible、Salt 或 CF-Engine 作為整體管理工具
我想知道我對工具的理解是否正確，如果不是，為什麼？
我只會評論我有經驗的那些，這意味著 Puppet 和 Ansible。我省略了一些細節。
兩者都可以設置為僅在需要時執行無代理或本地執行。要僅在本地使用它們，您顯然需要某種方法將所需的清單/劇本傳輸到目標機器並在那裡執行它們。
談到 Puppet 與 master 的使用，您可以使用負載均衡器和實際的 master 來實現冗餘。
相反，在 Ansible 中沒有 master 概念，只要您有訪問 playbook 的方法，每台可以使用 ssh / powershell 連接到託管機器的機器都可以。也許您的意思是 Ansible Tower，它使用數據庫進行操作，如果需要，您可以將其集群化。
這給我們帶來了兩種情況下的真正冗餘，即實際的腳本。在幾乎所有情況下，我都看到那些留在 git 儲存庫中，因此它本質上是多餘的，只需複製它，您就可以擁有多少“主”副本。
希望這可以幫助。
如果您查看 salt，構成 master 和 minions 之間工作連接的唯一資訊是：
- 僕從可以以某種方式解析主IP的事實
- /etc/salt/pki/master 目錄中的 minions 公鑰
如果您的鹽大師死了，系統將繼續執行而沒有任何影響。但你是對的，當主人離開時，你不能對你的配置進行任何更改。所以一個問題是你能多快把它拿回來？
您可以簡單地重新安裝 master 並啟動它 - 您可以再次接受您的 minions 密鑰（或重新安裝潛在的備份），並且您與舊 master 處於相同的位置。如果您不能重複使用同一台機器，那麼您需要以某種方式將 minions 指向新的 master。
數據庫中沒有可能損壞或消失的狀態數據。對我來說，這就是它的美妙之處。它是一個覆蓋，它不會擠進去。不是——作為另一個例子——像 juju，當你的數據庫消失時，你的系統就像被斬首一樣，你必須重新安裝。
Salt中還有Multimaster 和 Syndic - 高可用性是其開發中長期存在的主題。