SaltStack配置管理-3、之安装tomcat状态

1、本次使用salt简单安装tomcat环境,下面是salt的安装tomcat状态实现。

# cd /srv/salt/base/
# mkdir web     #创建一个web目录
# cd web/
# cat tomcat.sls        #安装java环境及tomcat的salt状态
jdk-install:       #状态ID
  pkg.installed:       #需要有java-1.8.0的包,没有则安装,有则什么也不做
    - name: java-1.8.0-openjdk

tomcat-install:       #状态ID
  file.managed:       #file模块的方法
    - name: /usr/local/src/apache-tomcat-8.0.46.tar.gz       #放到执行的salt-minion端的这个路径下
    - source: salt://web/files/apache-tomcat-8.0.46.tar.gz     #将salt-master端的这个文件,这里的路径可以是http的路径或者是ftp的路径。
    - user: root      #文件权限设置
    - group: root
    - mode: 755
  cmd.run:    #状态里的执行命令的模块
    - name: cd /usr/local/src && tar zxf apache-tomcat-8.0.46.tar.gz && mv apache-tomcat-8.0.46 /usr/local/ && ln -s /usr/local/apache-tomcat-8.0.46 /usr/local/tomcat
    - unless: test -L /usr/local/tomcat && test -d /usr/local/apache-tomcat-8.0.46

# mkdir -p /srv/salt/base/web/files          #创建存放文件目录并长传文件bao包
# cd /srv/salt/base/web/files && ls
apache-tomcat-8.0.46.tar.gz

2、执行状态

# salt '*' state.sls web.tomcat           #多级目录通过.来调用,和python调用模块类似

由于时间关系,更新速度不是很快,后续会做更多更新,请持续关注。

自动化运维工具之SaltStack-2、SaltStack配置管理

1、salt-master的配置文件编写格式之YAML语法说明

YAML语法数据的结构通过缩进来表示,每一级用两个空格来表示缩进,如果有下一
级结构需要以冒号结尾,连续的列表通过减号“-”来表示,减号后面需要有空格,不
是以冒号结尾的冒号后面需要有空格。

2、修改salt-master配置文件

# vim /etc/salt/master +416
416 file_roots:        #告诉salt状态文件的位置
417   base:    #base为必须存在的,
418     - /srv/salt/base      #base状态对应的文件位置
说明:/etc/salt/master 配置文件的格式是采用YAML的格式写的,所以修改需要注意
每个缩进级别由两个空格组成,不支持tabs键,有下一个级别需要以冒号结尾,列表
用“-”减号开头,注意减号后面需要有一个空格。

创建/etc/salt/master配置文件里状态文件目录:

# mkdir /srv/salt/base

修改配置后重启salt-master:

# systemctl restart salt-master

重启后测试salt-master与salt-minion端的通讯

# salt 'linux-node1' test.ping
linux-node1:
    True     #确定能成功通讯

3、使用salt写一个自动化安装apache的状态并执行

# cd /srv/salt/base
# vim apache.sls      #状态文件的名字
apache-install:    #安装状态的ID声明
  pkg.installed:    #pkg为状态模块,installed是pkg模块下的方法(即安装)
    - name: httpd    #installed方法的参数,name是一个特殊的参数(安装的东西)
注:以上整个状态的意思为:{应该有一个httpd服务,如果有则啥也不干,如果没有则下载一个}

apache-service:    #服务状态的ID
  service.running:   #service是状态模块,running是service模块下的方法(running即启动)
    - name: httpd    #方法的目标参数(启动的目标)
    - enable: True   #目标参数的动作(是否启动True则表示启动)
注:以上状态意思为{如果有httpd这个服务则启动httpd,如果没有httpd这个服务,就下载一个httpd并启动httpd}

执行这个apache状态:

[root@linux-node1 base]# salt 'linux-node1*' state.sls apache
linux-node1:      #minion端ID
----------
          ID: apache-install    #状态的ID
    Function: pkg.installed     #模块.模块的方法
        Name: httpd    #参数
      Result: True     #True为成功
     Comment: Package httpd is already installed.     #描述信息
     Started: 22:25:05.529566     #启动时间
    Duration: 1274.843 ms    #用了多少秒
     Changes:      #如果下东西了会有输出
----------
          ID: apache-service
    Function: service.running
        Name: httpd
      Result: True
     Comment: Service httpd is already enabled, and is in the desired state
     Started: 22:25:06.805143
    Duration: 268.049 ms
     Changes:   #都做了啥
              ----------
              httpd:
                  True     #启动了httpd

Summary
------------
Succeeded: 2    #成功了两个
Failed:    0
------------
Total states run:     2

执行之后即可到目标服务器去查看apache的启动装了,或者使用salt查看目标服务器的apache状态

# salt "linux-node1" cmd.run "systemctl status httpd"     #在salt-master端用此命令查看apache启动状态

本次就更新到这里,请关注后续更新,如有问题欢迎指出与交流。

自动化运维工具之SaltStack-1、SaltStack介绍及安装

1、SaltStack简介

官方网址:http://www.saltstack.com
官方文档:http://docs.saltstack.com
GitHub:https:github.com/saltstack

SaltStack是一个服务器基础架构集中化管理平台,具备配置管理、远程执行、
监控等功能,一般可以理解为简化版的puppet和加强版的func。SaltStack基于
Python语言实现,结合轻量级消息队列(ZeroMQ)与Python第三方模块
(Pyzmq、PyCrypto、Pyjinjia2、python-msgpack和PyYAML等)构建。
通过部署SaltStack环境,我们可以在成千上万台服务器上做到批量执行命令,
根据不同业务特性进行配置集中化管理、分发文件、采集服务器数据、操作系统基
础及软件包管理等,SaltStack是运维人员提高工作效率、规范业务配置与操作的利
器。

2、SaltStack特性

(1)、部署简单、方便;
(2)、支持大部分UNIX/Linux及Windows环境;
(3)、主从集中化管理;
(4)、配置简单、功能强大、扩展性强;
(5)、主控端(master)和被控端(minion)基于证书认证,安全可靠;

(6)、支持API及自定义模块,可通过Python轻松扩展。

3、SaltStack的结构

saltstack采用C/S(客户端和server端)架构,salt-master为server端,salt-minion为客户端

a)Master与Minion认证

(1)、minion在第一次启动时,会在/etc/salt/pki/minion/(该路径在/etc/salt/minion里面设置)下自动生成minion.pem(private key)和 minion.pub(public key),然后将 minion.pub发送给master。

(2)、master在接收到minion的public key后,通过salt-key命令accept minion public key,这样在master的/etc/salt/pki/master/minions下的将会存放以minion id命名的 public key,然后master就能对minion发送指令了。

b)Master与minion链接

(1)、SaltStack master启动后默认监听4505和4506两个端口。4505(publish_port)为saltstack的消息发布系统,4506(ret_port)为saltstack客户端与服务端通信的端口。如果使用lsof 查看4505端口,会发现所有的minion在4505端口持续保持在ESTABLISHED状态。

4、SaltStack基础安装与操作

(1)环境说明

192.168.1.12 安装salt-master salt-minion
192.168.1.100 安装salt-minion

1、本次操作采用CentOS 7.2系统

# cat /etc/redhat-release 
CentOS Linux release 7.2.1511 (Core) 

# uname -r
3.10.0-327.el7.x86_64

# hostname -I
192.168.1.12

# hostname -I
192.168.1.100

2、操作系统基础优化

参考博客:http://blog.51cto.com/12217917/2060136

5、yum安装SaltStack

# rpm -ivh https://repo.saltstack.com/yum/redhat/salt-repo-latest-2.el7.noarch.rpm    #两台服务器都安装rpm包

1、salt管理节点安装

# yum install -y salt-master salt-minion

2、salt所有客户端安装(被管理的机器)

# yum install -y salt-minion

6、启动Salt

1、管理端启动命令

# systemctl start salt-master      #master端启动命令
# tree /etc/salt/pki        #启动后查看目录结构
pki
└── master
    ├── master.pem     #salt-master的公钥
    ├── master.pub     #salt-master的私钥
    ├── minions
    ├── minions_autosign
    ├── minions_denied
    ├── minions_pre
    └── minions_rejected

2、配置客户端并启动客户端

# sed -n '16p' /etc/salt/minion         #修改所有客户端的配置文件
master: 192.168.56.11      #告诉客户端   salt-master是谁,:冒号后面需要有空格
注:minion配置文件的关于ID配置,{如果配置ID则使用配置里的ID作为主机通讯标记,如果不配置ID则默认以主机名作为ID为主机通讯标记(本人生产上的主机名都做修改所以这里没有配置ID),ID如果修改,需要删除之前认证的KEY,然后重新添加KEY。}
# systemctl start salt-minion        #启动客户端
注:修改客户端通讯ID的步骤{1.停止需要修改ID的salt-minion  2.salt-key 删除老的id   3.删除minion端的/etc/salt/minion_id   4.删除minion端/etc/salt/pki  5.修改minion配置文件的id   6.启动minion   7.master端重新salt-key加入}

# tree      #启动后查看客户端的结构
.
├── minion
├── minion.d
├── minion_id
└── pki
    └── minion
        ├── minion.pem    #minion的公钥
        └── minion.pub    #minion的私钥

7、在master端添加客户端

说明:这一步操作就相当与签劳动合同,表示客户端(salt-minion)接受server端(salt-master)管理。

# salt-key          #查看客户端的命令
Accepted Keys:    #已经同意的key有哪些
Denied Keys:      #拒绝的key有哪些
Unaccepted Keys:    #未同意的key有哪些
linux-node1     #客户端的通讯ID(由于前面没有配置,这里以主机名的形式出现)
linux-node2     #客户端的通讯ID(由于前面没有配置,这里以主机名的形式出现)

# salt-key -A        #-A表示同意所有的客户端通讯ID
The following keys are going to be accepted:
Unaccepted Keys:
db02-36
saltstack-41
Proceed? [n/Y] y    #确认信息,是否同意这两个key
Key for minion linux-node1
Key for minion linux-node2

关于salt-key的参数
-d 删除单个key,也支持*号模糊匹配删除   (针对key的操作)
-D 删除所有key,慎用                    (针对key的操作)
-L 列表                                 (远程执行、列表key等)
-A 同意所有key                          (针对key的操作)
-a 同意单个,可以用*号迷糊匹配添加      (针对key的操作)
-G 匹配Grains                           (远程执行)
-I 匹配Pillar                             (远程执行)
-E 支持正则表达式                       (远程执行)
-S 指定客户端的ip地址                   (远程执行)
-C 一条远程执行的命令同时支持多个参数   (远程执行)
-N 支持节点组                           (远程执行)
更多操作请通过salt-key --help来查看

8、master端确认是否能连接到客户端(salt-minion端)

1、测试所有客户端是否能通讯

# salt '*' test.ping        #{*为通配符,表示所有。test为模块,ping为test模块下的一个方法(测试是否能通讯)}
linux-node2
    True      #True为通,False为失败
linux-node1
    True

2、远程执行shell命令

# salt ' linux-node2 ' cmd.run "w"       #单独指定某个客户端的通讯ID表示在这台客户端执行(cmd.cun表示执行shell命令,支持linux下所有的shell命令)
linux-node2:
     20:26:56 up  2:10,  1 user,  load average: 0.00, 0.01, 0.05

本次就介绍到这里,如有问题欢迎指出与交流。

saltstack配置文件详解

软件依赖

  • Python版本大于2.6或版本小于3.0: 对Python版本要求
  • msgpack-python: SalStack消息交换库
  • YAML: SaltStack配置解析定义语法
  • Jinja2: SaltStack states配置模板
  • MarkupSafe: Python unicode转换库
  • apache-libcloud: SaltStack对云架构编排库
  • Requests: HTTP Python库
  • ZeroMQ: SaltStack消息系统
  • pyzmq: ZeroMQ Python库
  • PyCrypto: Python密码库
  • M2Crypto: Openssl Python包装库

Master配置文件

主要配置

未分类

安全配置

未分类

salt-ssh配置

未分类

state系统配置

未分类

文件服务配置

未分类

pillar系统配置

未分类

syndic配置

未分类

日志配置

未分类

Minion配置文件

未分类

模块管理配置

未分类

长连接配置

未分类

saltstack mutilmaster的具体配置和实现

简介:在上一篇讲完了salt-master的HA整体架构之后,再来看看它的多master的实现方案。该文档参考saltstack官方文档:
https://docs.saltstack.com/en/develop/topics/tutorials/multimaster.html

步骤:

  1. 创建一个master服务的备份节点
  2. copy 主master节点的key到备节点
  3. 启用备master节点
  4. 重启minions
  5. 在备节点接受key

step1 -2:

默认的master的private key是在目录: /etc/salt/pki/master. 将该目录下的master.pem拷贝到备master节点的同一位置,对master的public key文件master.pub做同样的操作。

step3:

注意,一旦新的key被备份节点接受后,要进行安全的一些操作 。:
配置minions:

master:
  - saltmaster1.example.com  #或者IP地址
  - saltmaster2.example.com

配置完成后,minion将会核对主master和备master进行核对,并且两个master都对minion有操作权限。
注意:minion可以自动检测失败的master,并且尝试重连到一个更快的master,将minion端的参数master_alive_interval 设置为true,即可开启该功能。

在master之间共享文件:
salt本身在master之间没有共享文件的功能,共享能力需要考虑。
那么需要分别在每一个master节点上面进行手动接受key,才可以实现双节点的备份,这明显不方便。
但是也可以通过共享文件:/etc/salt/pki/master/{minions,minions_pre,minions_rejected}来实现。
file_roots:
共享文件如何共享呢,那么可以选择简单易用的gitfs,来同步多master之间的文件共享。

saltstack的HA高可用架构方案

saltstack集群管理简介:saltstack的常规方案为 ‘单master-多minions’ 架构 ,如下图左,对批量节点进行管理和操作;在较大规模的集群系统下,常用的为三层架构,‘单master-单syndic-多minions’架构,对集群进行分块管理,如下图右,三层架构可以通过master节点将任务分发到syndic节点,对各个syndic管理的区域的minion机器进行操作,之后结果返回到syndic节点,并二次返回到master节点,可以再master节点一并获取返回结果。

问题:上述架构中的高可用性方案是没有的,仅仅作为一个管理工具,上述架构已经可以满足基本要求;
然而因为公司更多的业务系统通过调用saltstack来进行集群管理,那么对salt的要求也从工具到了基础架构组件的层面,因此,对服务可用性方面的要求
就更高了,salt原生默认‘单master-minion’架构,salt-api也是daemon方式运行,因此,在推广到生产环境之后,可用性就遭到了极其严重的考验,
比如,单master故障整个集群的操作就实现不了,如何实时迁移恢复,如何对文件进行备份,如何对master节点和syndic节点做主备方案,如何使得主备管理均可访问到
minion节点,又如何对三层架构syndic节点存储的文件做到统一管理,并且进行文件主备方案,高可用性也是在生产环境中任何系统所必须的一项内容。

方案:mutil-master,mutil-syndic,以及使用gitfs对syndic节点的文件进行同步到服务器。并将服务器做好两城主备。

官方相关参考文档:http://docs.saltstack.com/en/latest/topics/highavailability/index.html
在参考了几个成功案例之后,最后的架构参考了:MultiSyndic、MultiMaster、Failover Minion、Ext Job Cache
博客地址:http://openskill.cn/article/181

mutil-syndic
首先是mutil-syndic,mutil-syndic是指一台syndic节点同时被多台MOfM(master of masters)管理,官方文档对简单的配置做了一些介绍:
https://docs.saltstack.com/en/latest/topics/topology/syndic.html
具体的源码则是放到了minion.py,本身原理便是MultiSYndic会去复用一些Syndic的功能,然后做一些转发的处理。
具体的设置综合mutil-master,需要设置syndic_master为一个list,另外key等文件要做共享设置,其次就是写入一些必要
的syndic本身的配置。

Failover Minion or MultiMinion
这是salt在minion端实现的特性,它允许minion定期的去探测当前master的存活性,一旦发现master不可用,就在一定时间
内做出切换,从而提供整体服务调用的可用性。
具体配置参考官网内容:https://docs.saltstack.com/en/develop/topics/tutorials/multimaster_pki.html
需要注意的是配置multi-master或者multimaster PKI都可以使用failover特性。minion的具体配置内容如下:

# multi-master  
master:    
    - 172.16.0.10  
    - 172.16.0.11  
    - 172.16.0.12  

# 设置为failover minion  
master_type: failover  

# 设置启动时随机选择一台master  
master_shuffle: True  

# 探测master是否存活的schedule job  
# 即使用salt schedule特性实现的功能  
master_alive_interval: <seconds>  

但是上述架构也是有弊端的,正如开端描述的,MOfM在下发命令的时候,所有的节点都通过syndic节点在短时间内大量返回,MofM就等于承受了一次短时间的数据流量的
冲击,1W台minion就是1W条minion job数据,再加上find job任务,理论上产生的数据量和计算能力的消耗是巨大的。
因而在生产环境中,我们目前基本上是在采用,对于某些区域的机器,直接在syndic节点进行操作。这样就避免造成master巨大的处理能力。
然而,我们在master节点进行全区域操作的情况下,master并非是对所有区域同时进行访问,而是在等待单syndic节点返回结束后,开始进行下一个syndic节点的返回。

Saltstack模块file发送中文名称文件问题解决

最近又用到了saltstack,发现过了这么多年,salt的file模块无法发送中文名称文件问题还没有人解决。
蛋蛋的忧伤啊,国内这么流行的东西既然不支持中文。
于是从昨晚一直决战到今天天亮,终于找到了可行性方法。
下面做个笔记,希望能帮到有需要的人。

一、系统环境

系统:CentOS7.2
python版本:2.7.5
salt版本:2015.5.10

二、问题展现

需求:要同步一个文件夹(同步文件或文件夹一样)到minion端,文件夹里包含中文名称的文件
执行过程报错:

[plain] view plain copy
192.168.1.127:  
----------  
          ID: dir_send  
    Function: file.recurse  
        Name: /tmp/ylhb  
      Result: False  
     Comment: An exception occurred in this state: Traceback (most recent call last):  
                File "/usr/lib/python2.7/site-packages/salt/state.py", line 1564, in call  
                  **cdata['kwargs'])  
                File "/usr/lib/python2.7/site-packages/salt/states/file.py", line 2401, in recurse  
                  ) for (k, v) in six.iteritems(ret['comment'])).strip()  
                File "/usr/lib/python2.7/site-packages/salt/states/file.py", line 2401, in <genexpr>  
                  ) for (k, v) in six.iteritems(ret['comment'])).strip()  
              UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 10: ordinal not in range(128)  
     Started: 16:16:17.297668  
    Duration: 23.924 ms  
     Changes:     

Summary  
------------  
Succeeded: 0  
Failed:    1  
------------  
Total states run:     1  
ERROR: Minions returned with non-zero exit code  

查看python默认编码:

[plain] view plain copy
>>> import sys  
>>> sys.getdefaultencoding()  
'ascii'  
>>>   

可知默认的编码是ascii。
由于python默认编码为ascii,当程序中出现非ascii编码时,python的处理常常会报“UnicodeDecodeError: ‘ascii’ codec can’t decode byte 0xe9 in position 10: ordinal not in range(128)”这样的错(python3不会有这样的问题)。

三、解决方法

只需修改python默认编码为“utf-8”即可(master端和minion端都要修改),修改方式如下:
新增文件/usr/lib/python2.7/site-packages/sitecustomize.py,内容如下:

[python] view plain copy
# -*- coding: UTF-8 -*-  
import sys   
reload(sys)  
sys.setdefaultencoding('utf-8')  

再次查看python默认编码:

[python] view plain copy
>>> import sys  
>>> sys.getdefaultencoding()  
'utf-8'  
>>>   

重启salt服务(master端执行“systemctl restart salt-master”,minion端执行“systemctl restart -salt-minion”)。
再次执行发送中文名称文件:

[plain] view plain copy
192.168.1.127:  
----------  
          ID: dir_send  
    Function: file.recurse  
        Name: /tmp/ylhb  
      Result: True  
     Comment: Recursively updated /tmp/ylhb  
     Started: 17:06:40.381259  
    Duration: 71.074 ms  
     Changes:     
              ----------  
              /tmp/ylhb/雨落寒冰:  
                  ----------  
                  diff:  
                      New file  
                  mode:  
                      0644  

Summary  
------------  
Succeeded: 1 (changed=1)  
Failed:    0  
------------  
Total states run:     1  

以上发送中文名称文件成功。

注:以上仅适用于Linux系列系统,暂不支持Windows(闭源太麻烦了,已经很多年没用了,试着把python升级到3以上版本解决吧)

saltstack的state.sls和state.highstate之区别

saltstack的state.sls和state.highstate之区别

state.sls默认的运行环境是base环境,但是它并不读取top.sls(top.sls定义了运行环境以及需要运行的sls)。关于state.sls的官方文档说明如下:

salt.modules.state.sls(mods, saltenv='base', test=None, exclude=None, queue=False, env=None,**kwargs)

这里saltenv指的是运行环境,默认是base环境。

state.highstate: 这个是全局的所有环境,以及所有状态都生效。它会读取每一个环境的top.sls,并且对所有sls都生效。

我只有一个base环境,这个base环境下的top.sls文件内容如下:

base:
  '*':
    - backup
    - monitor
    - sysctr
    - slowlog
    - offline
    - conf
    - statistics
    - test
    - shell
    - dbmsdba
    - dba-tools

top.sls文件并没有定义 – sync_dbconf这个sls。但是在base环境定义的目录下:

file_roots:
   base:
     - /data/dbms/salt

也就是/data/dbms/salt目录下,定义了sync_dbconf.sls文件,该sls定义是为了向minion下发特定的文件。

1)、使用state.highstate的时候

/data1/Python-2.7.4/bin/salt 'minion_xxxx' state.highstate

可以发现并没有将sync_dbconf.sls定义的文件下发到minion端

2)、使用state.sls的时候

/data1/Python-2.7.4/bin/salt 'minion_xxxx' state.sls sync_dbconf

发现可以将sync_dbconf.sls定义的文件下发到minion端

以上说明:

1、state.highstate会读取所有环境(包括base环境)的top.sls文件,并且执行top.sls文件内容里面定义的sls文件,不在top.sls文件里面记录的sls则不会被执行;

2、state.sls默认读取base环境,但是它并不会读取top.sls文件。你可以指定state.sls执行哪个sls文件,只要这个sls文件在base环境下存在;

3、state.sls也可以指定读取哪个环境:state.sls salt_env=’prod’ xxxx.sls,这个xxxx.sls可以不在top.sls中记录。

Saltstack (grains、pillar、jinja模版、haproy+keeplived)

配置内容接上篇

  • redhat6.5

  • server1 172.25.29.1 salt-master

  • server2 172.25.29.2 salt-minion haproy+keeplived

  • server3 172.25.29.3 salt-minion nginx

  • server4 172.25.29.4 salt-minion nginx

  • server5 172.25.29.5 salt-minion haproy+keeplived

做之前配置好本地解析

一、Grains

grains是minion第一次启动的时候采集的静态数据,可以用在salt的模块和其他组件中。其实grains在每次的minion启动(重启)的时候都会采集,即向master汇报一次的。

二、minion端配置grains

修改server3和server4的salt-minion,设定nginx角色

未分类

在server3和server4的/etc/salt下创建grains,内容如下

未分类

未分类

未分类

1. 测试grains的数据

未分类

未分类

2. 修改top.sls文件并推送

未分类

未分类

推送成功

未分类

三、mster端配置grains,不用重启服务

1. 在master端创建_grains文件

未分类

未分类

2. 修改server3和server4的grains或者是删除grains文件,做到不影响下面master这边的grains

未分类

未分类

未分类

3. 向server3和server4同步grains

未分类

查看server3和server4的salt缓存

未分类

未分类

4. 修改top.sls推送文件

未分类

推送成功

未分类

四、pillar用法

grain和pillar区别

(1)grains存储的是静态、不常变化的内容,pillar则相反

(2)grains是存储在minion本地,而pillar存储在master本地

(3)minion有权限操作自己的grains值,如增加、删除,但minion只能查看自己的pillar,无权修改

1. 配置pillar

修改server1上的master配置文件,开通pillar base目录,可以与grains共存

未分类

未分类

采集主机名

未分类

2. 设置不同的主机名推送安装不同的服务

未分类

未分类

未分类

3. 在pillar下创建一个新的top.sls推送文件

未分类

刷新

未分类

4. 检测和查看的相关命令

查看采集的推送项目,按照不同的主机名通过pillar下的web.sls做不同的事情

未分类

未分类

未分类

未分类

通过salt采集server3开启的服务

未分类

远程重启server3的nginx服务

未分类

将master server1上的文件群传给minion端

未分类

群查看minion的/tmp下的文件,已经传过来了

未分类

远程查看passwd文件

未分类

远程给server4安装htppd文档

未分类

远程给server4安装losf工具

未分类

五、jinja模版的使用

Jinja是基于python的模板引擎,在saltstack中我们使用yaml_jinja渲染器来根据模板生产对应的配置文件,对于不同的操作系统或者不同的情况通过jinja可以让配置文件或者操作形成一种模板的编写方式。

模版文件里面变量使用{{名称}},例如{{PORT}}
变量使用Grains:{{ grains[‘fqdn_ip4’] }}
变量使用执行模块:{{ salt‘network.hw_addr’ }}
变量使用Pillar:{{ pillar[‘apache’][‘PORT’] }}

1. jinja模版配置

以httpd下的web.sls为例,添加模版,端口,地址

未分类

未分类

2. 修改files下的httpd.conf配置文件为变量格式

未分类

未分类

3. 用jinja模版推送httpd服务

未分类

未分类

server3 httpd服务8080端口正常

未分类

六、jinja模版的另外三种实现方法

1. 方法一

未分类

在httpd.conf配置文件的最上面添加变量模块

未分类

下面的监听端口上按python的方式取值

未分类

在files下面新建 vim lib.sls

未分类

将之前的web.sls里的template下面注释掉

未分类

用jinja模版给server3推送httpd服务

未分类

未分类

2. 方法二

将httpd.conf里刚才上面写的删除,因为会与下面的这个方法冲突

未分类

监听端口修改为下图所示

未分类

将web.sls文件修改为以下设置

未分类

vim lib.sls

未分类

未分类

3. 方法三:使用pillar

进入到pillar的base目录下

未分类

(1)配置文件第一种写法

未分类

vim httpd.conf

未分类

(2)配置文件第二种写法

未分类

vim httpd.conf

未分类

推送

未分类

salt server4 state.sls httpd.web

未分类

七、salt自动化推送keepalived+nginx

1. 配置keepalived salt文件

未分类

vim keepalived.conf,添加vip

未分类

vim install.sls

未分类

未分类

vim service.sls

未分类

单击keepalived推送成功

2. 由于keepalived高可用,主备的配置文件不一样,需要添加jinja模版

未分类

在install.sls里添加jinja模版

未分类

keepalived.conf里的state和priority写成变量

未分类

3.新添加一台虚拟机server5做keepalived的高可用

未分类

将server5加入到salt-key

未分类

未分类

4. 修改top.sls文件并推送

未分类

5. 查看推送结果

haproy+keeplived正常启动,vip在主上

未分类

将主server2上的keepalived关闭,服务到备server5上

未分类

负载均衡haproxy正常

未分类

未分类

搭建saltstack的备份机器

高可用是运维的基本要求之一,那么运维自身的工具首先要达到这个要求。因此,需要给saltstack做个主备,以下是过程,非常简单:

一、同步主saltstack的文件到备机

rsync -av /etc/salt/* slave_salt_host:/etc/salt/

二、启动备机的salt-master

/etc/init.d/salt-master restart

三、修改minion端的配置,增加备机的IP

master:

– 10.2..