自动化运维管理工具:

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   [options] [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(repositorydistritution,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