自動化管理工具的意義及選擇
a: 人工進行配置管理工作會耗費大量時間，而且風險極大，但凡是管理過服務器的技術人員對此都深信不疑。
b: 工具的選擇都是基於遺留系統（我們拼命維護的系統）的架構，而非當前可用的工具種類。
工具介紹：
1：CF引擎
CF引擎可以看作是配置管理之父。1993年誕生的CF引擎，徹底改變了我們對於服務器設置和配置的方式。一開始CF引擎是一項開源項目，2008年發布第一個商務版本，自此實現了商業化。CF引擎是用C語言編寫的，依賴物很少，而且運行速度極快。但一般的技術人員不會使用CF 引擎。必須是懂得C語言的開發人員才能夠管理CF引擎。
特點：
使用維護困難
2：Puppet
隨后出現了Puppet，一開始Puppet也是作為一個開源項目出現的，后來發展成為商用版本。Puppet采用了模型驅動的方法，與CF引擎相比在操作上更加“友好”，學習起來也相對簡單。CF引擎使用的是C語言，而Puppet使用的是Ruby語言，相比C語言要更加靈活，
Puppet的出現使得CF引擎逐漸退出了歷史舞台，主要原因還是CF引擎對於編碼能力的要求較高。
3：Chef
終於，Chef出現了，該工具確實解決了Puppet的一些小問題，但只是暫時的。隨着Puppet和Chef逐漸發展流行，兩個工具進入了“零和競爭”的狀態。只要一方開發出新的功能或有了新的改進，另一方就會立刻模仿並進行相同的改動。這樣一來，兩個工具各自的功能都越來越多，復雜性也越來越高，相應的學習起來的難度也越來越大。
Puppet和Chef工具都很成熟，應用都很廣泛（尤其是在商業環境中），開源社區的貢獻也都很多。唯一的問題就是，兩款工具對於我們想要實現的東西來說過於復雜。
這兩款工具在設計之初就沒有充分考慮到容器，它們也不會想到這場“博弈”最終會因為Docker而發生變化，因為那個時候Docker還沒有出現。
今天我們可能會用到很多部署工具，Docker Compose，Mesos，Kubernetes，以及DockerSwarm只是日益涌現的眾多配置管理工具的一部分。在這種背景下，
我們對於配置管理的選擇應當注重簡潔性和不可變性，而不是其他東西。語法應當簡單易讀，即便是從來沒有用過工具的人都應當可以看懂。
4：Ansible
配置管理工具基本上都面臨着同樣的問題，而Ansible決定通過非常不同的方式來解決問題。最顯著的一點就是Ansible通過SSH（安全外殼協議）進行所有的操作。使用CF引擎和Puppet時，需要在其管理的所有服務器上安裝客戶端。雖然Chef聲稱其可以不安裝，但其無代理商（agent-less）版本支持的功能十分有限。與Ansible相比可謂相差萬里，因為SSH的存在，Ansible對服務器幾乎沒有任何要求。Ansible的開發人員並沒有浪費時間去開發一個全能型工具，而是專注於該工具最適合的場景，有些人或許會指出Ansible的主要缺點對：Windows的支持很有限。它的客戶端幾乎不能在Windows系統上運行，而且只有非常有限的很少一部分模塊可以運行使用。
5：saltstack
Ansible和SaltStack都是的目前最流行的自動化運維工具，能滿足企業IT系統的自動化運維管理。這兩個工具都是用python開發的，
可以部署到不同的系統環境中和具有良好的二次開發特性。
1: 響應速度
SaltStack的master和minion主機是通過ZeroMQ傳輸數據，而Ansible是通過標准SSH進行數據傳輸，SaltStack的響應速度要比Ansible快很多。
標准SSH連接的時候比較耗費時間，ZeroMQ傳輸的速度會快很多，所以單單從響應速度方面考慮SaltStack會是更好的選擇。
2: 安全
Ansible和SaltStack都需要和遠程主機進行連接，它們的最大的安全問題就是MITM攻擊，通過偽裝成Master主機和遠程主機進行通信，從而進行攻擊。
SaltStack使用ZeroMQ進行數據傳輸，ZeroMQ本身數據傳輸不支持加密，SaltStack可以通過使用AES數據加密方法來對數據進行加密傳輸，但是SaltStack
的minion主機以守護進程的方式運行在遠端暴露了很多容易被攻擊的點。 Ansible使用標准SSH連接傳輸數據，不需要在遠程主機上啟動守護進程，並且標
准SSH數據傳輸本身就是加密傳輸，這樣遠程主機不容易被攻擊。也不是說Ansible就可以完全避免被攻擊，Ansible使用paramiko庫進行SSH連接，paramiko
是一個有很不錯記錄SSH連接的python庫。Ansible可以通過配置StrictHostKeyChecking參數，使得遠程主機上的keys和之前連接不一樣的時候Ansible沒有
及時感知和提醒用戶。但是Ansible可以通過修改配置文件和配置一個合適的known_hosts文件來解決這個問題，因此Ansible在安全方面還是比SaltStack做的好。
3: 自身運維
SaltStack需要在Master和Minion主機啟動守護進程，自身需要檢測守護進程的運行狀態，增加運維成本。Ansible和遠端主機之間的通信是通過標准SSH進行，
遠程主機上只需要運行SSH進程就可以進行運維操作，SSH是機房主機中一般都安裝和啟動的進程，所以在Ansible進行運維的時候只需要關注Ansible主機的運
行狀態。Ansible對機房運維不會增加過多的運維成本。從工具本身的運維角度來說，Ansible要比SaltStack簡單很多。
4: 使用語法
Ansible的Playbook語法要比SaltStack的State語法具有更好的可讀性。在使用的過程中發現Ansible在實現loop的更加的簡潔，也可以使用相對路徑。舉例說明，
SaltStack在備份文件A.txt和B.txt的State語法為：
# back up A.txt and B.txt
{% for remote_target %} /backup/{{ filename}}: file.managed: ‐ source: salt://remote-host/{{ filename }} ‐ require: ‐ cmd: A.txt ‐ cmd: B.txt {% endfor %}
Ansible的Playbook語法實現同樣的功能如下：
-name: back up A.txt and B.txt copy: src ={{item}} Dest=/backup/{{item}} with_items: - A.txt - B.txt
總結：
推薦使用ansible，掌握其他工具的過程可能錯綜復雜，但學習Ansible也就分分鍾的事。它的語法以YAML（是另一種標記語言）為基礎，即便是從未使用過工具的人，只需看一眼介紹就能明白所有東西。我們說：只要與Docker和Docker部署工具結合使用，Ansible都是最好的選擇。Ansible能夠節省大量的時間。學習Ansible十分簡單，即便最后你沒有選擇使用它，你也不會覺得在Ansible上浪費了很多時間。