自动化运维管理工具：
puppet：
有产品线已经在用，优点是历史悠久，比较成熟，在可远程可本地，功能强劲，不过这厮批量执行功能没得，为了批量执行个命令写个配置文件，好像有点大刀砍蚊子腿的感觉了，而且有客户端在，和授权系统结合比较麻烦。Puppet agent来master请求同步
saltstack:
和ansible都是python流的，而且就功能上来讲，两者也极为相似，不同之处是salt stack是有客户端的，并且execution模块还用0MQ实现了pub-sub，命令和执行结果因此可以高效并行传输，不过成也萧何败也萧何，第一个sub阶段（将querystring下发到所有机器，然后收集机器响应的阶段）太依赖与客户端返回了，如果客户端未能及时返回或未响应的话，playbook执行阶段可能会直接漏掉这部分机器而没有任何提示，这对于运维来说是不可接受的，要改造这个就得推掉saltstack的现有架构…算了吧。Master手推同步信息到agent
ansible:
与前两者比起来，在特性上似乎并不抢眼，配置管理方面（playbook）绝对比不过老大哥puppet，批量执行方面也只是多线程，不像saltstack那么高大上，不过ansible搜索热度高出saltstack三倍多，显然靠的不是吹牛，至少，ansible至少不会悄悄的丢机器，这给了我们一个定心丸，而且仅依赖ssh，与登录授权管理系统天然集成，简单即有效，没有比这更美妙的事情了。Master手推同步信息到agent
Puppet
Ruby语言
运维工具
OS poriovisioning(pxe,)系统自动安装
OS configuration（puppet，ansible，chef，saltstack）
Command and control任务执行（func，ansible）
Ansible能实现puppet的所有功能 puppet比ansible能管理的节点多
Puppet：IT基础设施自动化管理工具（较ansible安全）
整个生命周期：
Provisioning系统安装
Configuration配置
Orchestration编排
Reporting报告
模式：
Master/agent模式
Master：puppet server
Agent（1,ansible远程安装puppet agent
2,把agent制作在操作系统中）:要有管理功能，真正执行所谓管理操作的核心部件，周期性的去master请求与自己相关的的配置
工作模式：
声明性，基于模型：
定义：使用puppet配置语言定义基础配置信息
模拟：测试
强制(执行)：比对客户端主机与定义的目标保持一致
报告：puppet api 返回执行结果
三个层次：
配置语言：
事务层：资源之间的先后依赖关系；配置文件改变出发重启
资源抽象层：把主机上每个可以被管理对象都抽象定义为资源
资源类型：用户，组，文件，服务，cron任务等
属性及状态与其实现方式是分离的：
每一个资源都应该定义其期望状态
核心组件：资源
资源清单：manifests，定义了一个或多个资源(需要进行的操作)在server端
资源清单及清单中的资源定义的所有依赖文件，模板等数据按特定结构组织起即为”模块”
站点清单：用来记录一个主机包含的所有清单
模块：清单的组合
逻辑顺序：
可在本地模式运行或者在master和agent模式运行：
1，agent向master发送与自己相关的catalog，并发送自己的主机名和facts（主机自己的属性：IP地址，主机名，CPU等信息）；
2，服务端收到请求，查找请求者的站点清单（请求者调用了的清单）；
3，查询完之后找出这个站点的所有清单；
4，将清单在master端进行编译（catalog）；
5，将编译结果（伪代码（catalog））发送到agent端[不可能将源代码发送到agent端]；
6，伪代码在agent端的应用：
1，状态查询：已经完成的任务和需要再进行的任务。
2，执行目标状态：执行查询到的状态
7，任务执行完返回报告。
通过http协议进行通讯，证书认证，master自带CA，agent自动生成带签署的证书发给master的CA
安装：
Agent：puppet，facter
Master：puppet-server
命令用法格式：
Puppet <subcommand> [options] <action> [options]
获取所支持的所有的资源类型：
Puppetdescribe -i
Puppet 资源类型名称（file,package等） -i ##资源的具体使用方法
（puppet实现lnmp架构）：
nginx：
file文件夹：
install-nginx.sh:##将安装好安装包的所有过程命令都写到这里
#!/bin/bash
cd /mnt
tar -zxf nginx-1.8.0.tar.gz
cd nginx-1.8.0
./configure --prefix=/usr/local/lnmp/nginx --with-http_ssl_module --with-http_stub_status_module
make && make install
nginx.conf:###所安装的nginx配置文件
nginx安装包
mainfests：
config.pp:
class nginx::config {
file {
"/usr/local/lnmp/nginx/conf/nginx.conf":
source => "puppet:///modules/nginx/nginx.conf",
require => Class["nginx::install"],
notify => Class["nginx::service"]
}
}
install.pp:
class nginx::install{
package {
["pcre-devel","gcc","openssl-devel"]:
ensure => present
}
file {
"/mnt/nginx-1.8.0.tar.gz":
source => "puppet:///modules/nginx/nginx-1.8.0.tar.gz";
"/mnt/install-nginx.sh":
source => "puppet:///modules/nginx/install-nginx.sh"
}
exec {
"install nginx":
command => "sh /mnt/install-nginx.sh",
creates => "/usr/local/lnmp/nginx",
provider => shell,
require => File["/mnt/install-nginx.sh"]
}
}
init.pp:
class nginx {
include nginx::install,nginx::config,nginx::service
}
service.pp:
class nginx::service {
exec {
"start nginx":
command => "/usr/local/lnmp/nginx/sbin/nginx",
provider => shell,
require => Class["nginx::config"]
}
}
MySQL：
files：
install-myslq.sh:
my.cnf
安装包
mainfests：
config.pp：
class mysql::config {
file {
"/etc/my.cnf":
source => "puppet:///modules/mysql/my.cnf",
require => Class[mysql::install],
notify => Class[mysql::service]
}
}
init.pp:
class mysql {
include mysql::install,mysql::config,mysql::service
}
install.pp:
class mysql::install {
package {
["gcc-c++","make","ncurses-devel","bison","zlib-devel","cmake"]:
ensure => present
}
file {
"/mnt/mysql-5.5.12.tar.gz":
source => "puppet:///modules/mysql/mysql-5.5.12.tar.gz";
"/mnt/install-mysql.sh":
source => "puppet:///modules/mysql/install-mysql.sh"
}
exec {
"install mysql":
command => "cd /mnt;sh install-mysql.sh",
provider => shell,
creates => "/usr/local/lnmp/mysql",
timeout => 9999,
require => File["/mnt/install-mysql.sh"],
tries => 3
}
}
service.pp:
class mysql::service {
exec {
"start mysql":
command => "/etc/init.d/mysqld start",
provider => shell,
require => Class["mysql::install"]
}
}
php:...
Ansible：
OS Provisioning：PXE，Cobbler（repository，distritution，profile）
PXE：Dhcp（服务端udp 67 客户端udp 68）
Tftp（udp 69）
Dnsmasq：dhcp
OS config：
Puppet，saltstack
运维工具分类：
Agent：puppet，saltstack
无agent：ansible，依赖于每个被管理主机运ssh服务
Aansible特点：
使用简单，灵活
模块可使用任意语言
多任务批量执行-->>playbook
YAML标签来定义文本文档格式
当管理多个不同服务的服务器时，每个服务器都需要安装
NTP 时间同步
基本结构组件（5个）：
Ansible core：核心组件
Host Inventory主机列表：用来定义由ansible能够管理的服务器的IP地址，掩码，ssh用户密码等信息
支持分类，分组
Core核心模块：调用管理模块来针对某个用户完成相对任务
大部分任务 而不是全部任务
Custom自定义模块：可以用各种语言来自定义模块，完成ansible不具有的模块
Connection 连接插件：用来与主机连接，连接插件paramiko
Playbook：用于将一个或多个主机需要进行的任务记录下来用于执行，可以多次调用执行，yaml，jinjia2定义模板
特性：1，基于Python实现，paramiko，pyyaml，jinjia2三个关键模块
2，部署简单，无agent
3，默认使用ssh协议，1，密钥认证；2，在inventor中指明密码
4，主从模式：master：asible，ssh 客户端
Slave：ssh server
5，支持自定义模块，支持各种编程语言
6，支持playbook
7，基于模块完成各种任务
配置文件：/etc/ansible/ansible.cfg定义批量执行的个数等信息
/etc/ansible/hostsinventory记录表
分组
[web]
Ip
[mysql]
ip
支持通配符[001:006]
命令：ansible-playbook
Ansble-doc -l:显示ansible支持的模块
Ansible-doc -s：查看模块的具体信息
Ansible [主机] -m 模块 -a ‘参数’
Ansible webserver -m cron -a ‘minute=’*/10’ job=’/bin/echo hello’ name=’test cron job’ ’
Ping：测试指定主机能否连接
Service：指定运行状态
Enable=：取值true 开机启动，flase开机不启动
Name=：服务名称
State=：状态，取值有 started，stopped，restarted
Shell：在远程主机上执行命令，尤其是管道等功能复杂的命令
Script：将本地脚本复制到远程主机并运行，要使用相对路径指定脚本
Yum 安装程序包
Name:指明要安装的程序包，可以带上版本号
State：present，lastest表示安装，absent表示卸载
YAML 标记语言：
键值对加缩进
可读性好
和脚本语言交互好
使用实现语言的数据类型
有一个一致的信息模型
易于实现
基于流来处理
表达能力强，扩展性好
语法：
YAML的语法和其他告诫语言类似，并且可以简单的表达清单，散列表，标量的数据结构，其结构通过空格来展示，序列（同一类对象有多个时叫序列）里的项用‘ - ’ 表示，Map里的键值对用‘ ：’分隔
List序列/列表：
用 - 表示，表示同一类型的对象
Dictionary 字典：
一个键对应一组值，也可以放置于{key：value}中
基础元素：
变量
Inventory
条件测试
迭代
Playbook的组成结构：
Inventory
Modules
Ad Hoc Commands
Playbooks
Tasks：任务，调用模块完成的某操作
Varliables：变量
Templates：模板
Handlers：处理器，有某件事情触发执行的操作
Roles：角色
基本结构：
- host: webservers
remote_user:
tasks:
- task1
module_name:module_args
- task2
本文转自 Taxing祥 51CTO博客，原文链接:http://blog.51cto.com/12118369/1957608
