如何区分Puppet，Ansible，Saltstack的作用特点？

目前主流的自动化运维工具有puppet、ansible、saltstack，实际上每一个工具都基本上能够完成你的运维任务，也都是久经考验的。都有NB的地方，也有挫的地方，所以，完全没法从功能、特性等等这些方面去选择。

如果考虑到快速使用，建议puppet，有一个foreman做web平台，上手快。

如果考虑后期自己开发，并且是无agent方式，可以用ansible，基于ssh的，比较直接粗暴，会有种很“爽“的感觉。

ansible主要是远程命令执行，比较适合做“一次性”的工作。

saltstack用的不多，不做评论。

我个人比较喜欢用puppet和ansible，倒不是说saltsatack不好，是我从开始就在用puppet，所以，就没有再去学习saltsatck的必要了。

ansible的优势是什么，如何在企业中更好地使用ansible？

ansible比较适合做“一次性”的工作，例如，系统部署、应用发布、打补丁等等。

在企业中使用ansible，要注意以下几点：

1. 安全控制，简单来说就是避免用root用户来执行。

2. 控制好依赖 在写playbook的时候，控制好先后顺序和依赖关系。

3. 结果的收集和分析 因为一下子几百台机器一起干活，所以，就要自己写外置脚本，更好地收集ansible的操作结果，并且进行直观的汇总和展现。

Foreman的作用是什么？

foreman是基于puppet的一个“增强工具”，主要能够帮到我们运维狗的有：

1. 操作系统的部署

foreman提供了一个基于kickstart的部署工具，输入一台服务器的部署网卡的mac地址和hostname、ip等信息，就能自动的帮我们部署完，并且，还可以生成一个部署iso，用于该服务器的重新部署。

2. puppet的节点管理（ENC）

原声的puppet管理节点分类以及节点和puppet类之间的映射靠文件描述，企业客户更希望有一个直观的工具，foreman可以通过Web界面将节点分组，将类分组，并且构建两者的映射关系。

3. puppet的Web界面

有个Web总是比命令行要方便，foreman提供了一个还算的过去的web界面，用于节点管理、类管理、变量管理、配置管理、部署管理等功能。

如何利用foreman呢？

说实话，相比运维狗能写出来的界面，foreman已经很高大上了，所以，我们前面几个项目都是基于foreman进行扩展的，当时学习ruby，做需求分析，苦逼的用ruby实现功能，当时实现了自动化的安全检查、系统升级等功能。

后来客户需求越来越多，我们觉得不能局限于foreman的限制，就开始利用foreman的REST API实现功能的扩展，保证一个干净、原生的foreman。

foreman给我们的一个很大帮助就是，他把所有的配置、fact结果、运行结果什么都放到了mysql数据库里，所以，我们在做一些运行分析的时候，可以直接从数据库中获取数据进行分析即可。

foreman帮我们搞定了节点管理、数据入库，剩下的就是你的想象力了。

puppet的fact机制是什么，如何利用fact？

简单来说，fact就是puppet的一个组件，这个组件以一堆ruby脚本的形式存在在被管理服务器上，每次运行puppet命令的时候，都会先执行这一堆脚本，获得一堆变量=>值对，然后返回给服务器。

可以在一个安装了puppet的服务器上执行facter命令：

[root@fm-server ~]# facter

architecture => x86_64

augeasversion => 1.0.0

bios_release_date => 12/01/2006

bios_vendor => innotek GmbH

bios_version => VirtualBox

......

interfaces => eth0,lo

ipaddress => 192.168.56.30

ipaddress_eth0 => 192.168.56.30

ipaddress_lo => 127.0.0.1

is_virtual => true

kernel => Linux

kernelmajversion => 3.8

kernelrelease => 3.8.13-44.1.1.el6uek.x86_64

kernelversion => 3.8.13

...

具体脚本的位置在：/usr/lib/ruby/site_ruby/1.8/facter/ 这个目录中，有兴趣的同学可以自己看看。

系统默认了将近100个fact变量，实际上我们也可以自己扩展自己需要的fact变量，扩展fact有4种方法：

1. 直接在/usr/lib/ruby/site_ruby/1.8/facter/目录中自己写一个fact脚本，看看其他的怎么写的，比划着写就行了

2. 自己随便找个目录，把你自己的ruby脚本放到哪个目录中，然后定义变量：export FACTERLIB=/mypuppet/myfact/,脚本写法同上

3. fact支持外部fact，这个定义写在了/usr/lib/ruby/site_ruby/1.8/facter/util/config.rb文件中：

@external_facts_dirs = ["/opt/puppetlabs/facter/facts.d",

"/etc/facter/facts.d",

"/etc/puppetlabs/facter/facts.d"]

把你的fact定义放到那些目录中（可能需要自己创建），fact定义支持txt、yaml、json、sh四种方式，我比较喜欢用sh：

[root@fm-server ~]# mkdir -p /etc/facter/facts.d

[root@fm-server ~]# cd /etc/facter/facts.d/

[root@fm-server facts.d]# vi test.sh

#!/bin/bash

echo "testfact=Test"

[root@fm-server facts.d]# chmod 755 test.sh

[root@fm-server facts.d]# facter |grep test

testfact => Test

4. 用pluginsync发布，这个方法我用的很少，因为太麻烦了，我是极简主义者

对于自定义facter，大家可以参考

https://docs.puppetlabs.com/facter/3.1/fact_overview.html

找到了这个机制，我们如何利用facter呢？ 通常来说，有2个用法：

1. 使用fact变量来实现配置的自动调节

例如apache服务器，希望按照cpu的核数调整并发的进程数

fact变量中有一个：

[root@fm-server ~]# facter |grep process

physicalprocessorcount => 1

processor0 => Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz

processorcount => 1

processors => {"physicalcount"=>1, "count"=>1, "models"=>["Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz"]}

就可以在apache的puppet类中写：

StartServers <%= @processorcount.to_i*12 %>

这样不同的服务器的apache的启动进程就不同了

2. 利用fact收集想收集的信息

这个在自定义配置中已经讲了方法，反正是shell脚本，你想干啥就干啥，

foreman会把fact入库，你可以很方便的通过api或者直接访问数据库来获得你想要的数据。