自动化管理工具的意义及选择
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上浪费了很多时间。