当前位置: 澳门新濠3559 > 服务器运维 > 正文

开始链接,那如何基于自动化运维平台管理好这

时间:2019-11-09 19:36来源:服务器运维
京东物流系统自动化运维平台技术揭密,物流系统揭密 环境: Ansible 运维自动化 ( 配置管理工具 ) 简介: 当下有许多的运维自动化工具( 配置管理),例如:Ansible、SaltStack、Puppet、Fab

京东物流系统自动化运维平台技术揭密,物流系统揭密

环境:

Ansible 运维自动化 ( 配置管理工具 )

简介:

当下有许多的运维自动化工具( 配置管理 ),例如:Ansible、SaltStack、Puppet、Fabric 等。

Ansible 一种集成 IT 系统的配置管理、应用部署、执行特定任务的开源平台,是 AnsibleWorks 公司名下的项目,该公司由 Cobbler 及 Func 的作者于 2012 年创建成立。

Ansible 基于 Python 语言实现,由 Paramiko 和 PyYAML 两个关键模块构建。

Ansible 特点:

>> 部署简单,只需在主控端部署 Ansible 环境,被控端无需做任何操作。
>> 默认使用 SSH(Secure Shell)协议对设备进行管理。
>> 主从集中化管理。
>> 配置简单、功能强大、扩展性强。
>> 支持 API 及自定义模块,可通过 Python 轻松扩展。
>> 通过 Playbooks 来定制强大的配置、状态管理。
>> 对云计算平台、大数据都有很好的支持。
>> 提供一个功能强大、操作性强的 Web 管理界面和 REST API 接口 ---- AWX 平台。

Ansible 与 SaltStack

>> 最大的区别是 Ansible 无需在被监控主机部署任何客户端代理,默认通过 SSH 通道进行远程命令执行或下发配置。
>> 相同点是都具备功能强大、灵活的系统管理、状态配置,都使用 YAML 格式来描述配置,两者都提供丰富的模板及 API,对云计算平台、大数据都有很好的支持。

一、安装 Ansible

shell > yum -y install ansible

二、配置 Ansible

shell > ls /etc/ansible   # ansible.cfg 是 Ansible 工具的配置文件;hosts 用来配置被管理的机器;roles 是一个目录,playbook 将使用它
ansible.cfg hosts roles

1、Ansible 管理机与被管理机做秘钥认证

shell > ssh-keygen        # 生成秘钥
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
ea:11:72:ea:d2:d1:fa:1c:e0:df:4f:b0:98:31:be:fe [email protected]host.localdomain
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| |
| |
| o.= S |
| ..*.B o |
| .ooB . . |
| ..o+ = . |
| ..oB.E.. |
+-----------------+

shell > ssh-copy-id -i ~/.ssh/id_rsa.pub "-p 22 [email protected]"     # 将公钥写入被管理机
The authenticity of host '192.168.12.129 (192.168.12.129)' can't be established.
RSA key fingerprint is f0:9e:01:73:a4:bf:14:10:ac:46:a9:48:cd:c5:d8:1c.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.12.129' (RSA) to the list of known hosts.
[email protected]192.168.12.129's password: 
Now try logging into the machine, with "ssh '-p 22 [email protected]'", and check in:

.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

2、hosts 文件添加被管理机

shell > > /etc/ansible/hosts
shell > vim /etc/ansible/hosts

[Client]

192.168.12.129

三、测试 Ansible

shell > ansible Client -m ping     # 操作 Client 组 ( all 为操作 hosts 文件中所有主机 ),-m 指定执行 ping 模块,下面是返回结果
192.168.12.129 | SUCCESS => {
"changed": false, 
"ping": "pong"
}

# -i          指定 hosts 文件位置
# -u username 指定 SSH 连接的用户名
# -k          指定远程用户密码
# -f          指定并发数
# -s          如需要 root 权限执行时使用 ( 连接用户不是 root 时 )
# -K          -s 时,-K 输入 root 密码

四、附加

1、/etc/ansible/hosts 文件

## Ansible 定义主机、组规则的配置文件

shell > vim /etc/ansible/hosts

www.abc.com     # 定义域名

192.168.1.100   # 定义 IP

192.168.1.150:37268   # 指定端口号

[WebServer]           # 定义分组

192.168.1.10
192.168.1.20
192.168.1.30

[DBServer]            # 定义多个分组

192.168.1.50
192.168.1.60

Monitor ansible_ssh_port=12378 ansible_ssh_host=192.168.1.200   # 定义别名

# ansible_ssh_host 连接目标主机的地址

# ansible_ssh_port 连接目标主机的端口,默认 22 时无需指定

# ansible_ssh_user 连接目标主机默认用户

# ansible_ssh_pass 连接目标主机默认用户密码

# ansible_ssh_connection 目标主机连接类型,可以是 local 、ssh 或 paramiko

# ansible_ssh_private_key_file 连接目标主机的 ssh 私钥

# ansible_*_interpreter 指定采用非 Python 的其他脚本语言,如 Ruby 、Perl 或其他类似 ansible_python_interpreter 解释器

[webservers]         # 主机名支持正则描述

www[01:50].example.com

[dbservers]

db-[a:f].example.com

2、Ansible 常用模块学习

shell > ansible-doc -l    # 列出 Ansible 支持的模块

shell > ansible-doc ping  # 查看该模块帮助信息

>> 远程命令模块( command / script / shell )

command 作为 Ansible 的默认模块,可以运行远程权限范围所有的 shell 命令,不支持管道符。

例:

shell > ansible Client -m command -a "free -m"               # 查看 Client 分组主机内存使用情况

script 的功能是在远程主机执行主控端存储的 shell 脚本文件,相当于 scp + shell 组合。

例:

shell > ansible Client -m script -a "/home/test.sh 12 34"    # 远程执行本地脚本

shell 的功能���执行远程主机上的 shell 脚本文件,支持管道符。

例:

shell > ansible Client -m shell -a "/home/test.sh"           # 执行远程脚本

>> copy 模块(实现主控端向目标主机拷贝文件,类似于 scp 功能)

例:

shell > ansible Client -m copy -a "src=/home/test.sh desc=/tmp/ owner=root group=root mode=0755"   # 向 Client 组中主机拷贝 test.sh 到 /tmp 下,属主、组为 root ,权限为 0755

>> stat 模块(获取远程文件状态信息,atime/ctime/mtime/md5/uid/gid 等信息)

例:

shell > ansible Client -m stat -a "path=/etc/syctl.conf"

>> get_url 模块(实现在远程主机下载指定 URL 到本地,支持 sha256sum 文件校验)

例:

shell > ansible Client -m get_utl -a "url=http://www.baidu.com dest=/tmp/index.html mode=0440 force=yes"

>> yum 模块(软件包管理)

例:

shell > ansible Client -m yum -a "name=curl state=latest"

>> cron 模块(远程主机 crontab 配置)

例:

shell > ansible Client -m cron -a "name='check dirs' hour='5,2' job='ls -alh > /dev/null'"

效果:

#Ansible: check dirs
* 5,2 * * * ls -alh > /dev/null

>> mount 模块(远程主机分区挂载)

例:

shell > ansible Client -m mount -a "name=/mnt/data src=/dev/sd0 fstype=ext4 opts=ro state=present"

>> service 模块(远程主机系统服务管理)

例:

shell > ansible Client -m service -a "name=nginx state=stoped"
shell > ansible Client -m service -a "name=nginx state=restarted"
shell > ansible Client -m service -a "name=nginx state=reloaded"

>> user 服务模块(远程主机用户管理)

例:

shell > ansible Client -m user -a "name=wang comment='user wang'"

shell > ansible Client -m user -a "name=wang state=absent remove=yes"    # 添加删除用户

五、Ansible-playbook

# 使用 Ansible-playbook 可以完成一组复杂的动作,例如部署环境、搭建服务、修改配置等。

简单示例:

shell > vim /etc/ansible/playbook.yml    # 将远程主机IP地址写入文件中保存

---
- hosts: Client
remote_user: root
tasks:
- name: Save IP To info.txt
shell: "ifconfig eth0 | awk -F '[ :]'+ '/inet addr/{print $4}' > ~/info.txt"

# hosts        指定执行操作主机
# remote_user  指定执行用户
# tasks        指明有哪些动作
# name         动作描述
# shell        模块,后面为具体指令

澳门新濠3559 1

Playbook 实战:

一、目录结构

澳门新濠3559 2

shell > cd /etc/ansible/ ; tree .
.
├── ansible.cfg
├── delete_zabbix_agent.yml
├── hosts
├── install_zabbix_agent.yml
└── roles
    ├── delete_zabbix_agent
    │   ├── tasks
    │   │   └── main.yml
    │   └── vars
    │       └── main.yml
    └── install_zabbix_agent
        ├── files
        │   └── zabbix-2.4.5.tar.gz
        ├── tasks
        │   └── main.yml
        ├── templates
        │   ├── zabbix_agentd
        │   └── zabbix_agentd.conf
        └── vars
             └── main.yml

## ansible.cfg  此文件为 ansible 的主配置文件
## hosts        用于定义主机组
## roles        定义不同的角色
## install_zabbix_agent.yml  用于安装 zabbix_agent 的引导文件
## delete_zabbix_agent.yml   删除已安装的 zabbix_agent 的引导文件

    └── install_zabbix_agent
        ├── files
        │   └── zabbix-2.4.5.tar.gz
        ├── tasks
        │   └── main.yml
        ├── templates
        │   ├── zabbix_agentd
        │   └── zabbix_agentd.conf
        └── vars
             └── main.yml

## 其中,install_zabbix_agent 为一个角色,用于安装 zabbix_agent

## file      目录:用于存放将要拷贝到远程主机的安装包等
## tasks     目录:将要执行的所有任务,如果比较复杂,可以单独定义不同的任务,最后在 main.yml 文件中引用即可
## templates 目录:模板目录,这里存放着一些可变的文件,即:每台主机上的这些文件中的内容都不完全相同
## vars      目录:用于存放变量

## 这是一个比较简单的结构,其实一个角色中还可以有 meta 、handlers 等

二、Playbook 安装软件需要的步骤

1、定义 hosts( 给哪些主机安装软件 )

shell > vim /etc/ansible/hosts

[mini]

129.139.153.78:16283
155.139.190.94:12573

2、定义入口文件 install_zabbix_agent.yml

shell > vim /etc/ansible/install_zabbix_agent.yml

---
- hosts: mini
  roles:
  - install_zabbix_agent

## 可以看到将要安装的主机组为 mini 组,角色为 install_zabbix_agent

3、定义角色 install_zabbix_agent

shell > tree /etc/ansible/roles/install_zabbix_agent/

├── files
│    └── zabbix-2.4.5.tar.gz
├── tasks
│    └── main.yml
├── templates
│    ├── zabbix_agentd
│    └── zabbix_agentd.conf
└── vars
      └── main.yml

## 建立 files     目录,存放编译安装过的 zabbix_agent 目录的压缩文件,用于拷贝到远程主机
## 建立 tasks     目录,用于编写将要执行的任务
## 建立 templates 目录,用于存放可变的模板文件
## 建立 vars      目录,用于存放变量信息

随着上线的服务器数量增多,如何批量有效的管理各个节点服务器正常运作是每个运维人员需要解决的难题。

作者:赵玉开,十年以上互联网研发经验,2013年加入京东,在运营研发部任架构师,期间先后主持了物流系统自动化运维平台、青龙数据监控系统和物流开放平台的研发工作,具有丰富的物流系统业务和架构经验。在此之前在和讯网负责股票基金行情系统的研发工作,具备高并发、高可用互联网应用研发经验。

简单来理解,自动化运维就是要通过机器的方式来简化整体的运维过程,特别是优化重复类型的工作,以提高运维效率,减少因人工而引起的失误操作。随着运维管理的复杂度和难度增大,自动化运维也基本成为了运维平台演进的必经之路。但如何落地自动化运维平台,不同的企业因为运维发展阶段和业务体量的不同,都有不一样的实现路径。

以京东为例,它的物流系统有很多分支机构, 比如仓库、分拨中心、转运中心等, 业务复杂的分支机构可能会有自己的信息系统, 这些信息系统往往分布式地部署到全国各地,那如何基于自动化运维平台管理好这些分支机构的服务器、 信息系统, 降低因为地域分布造成的运维维护成本呢?京东资深架构师赵玉开向 InfoQ 记者深入介绍了他们在自动化运维平台方面的一些探索和实践。另外,赵玉开也将会在 9 月 10 日举行的 CNUTCon 全球运维技术大会 上分享相关话题,欢迎关注。

InfoQ:可以先介绍下目前京东物流系统自动化运维平台的一些基本情况吗?

赵玉开: 京东物流系统自动化运维平台从 2014 年开始启动到现在已经历了三各阶段,到目前管理了 MySQL、JMQ、 Redis 及自研应用等多种实例。

众所周知,京东业务发展迅猛,每周都需要开仓,数量多达十几个。最初开仓过程特别冗长和复杂,开仓过程中涉及到研发人员部署系统、运营人员手动填写多种申请、运维人员不仅要负责中间件安装,还要负责整个流程中每个环节的进展确认及协调,这直接导致了开仓慢,且涉及到的各部门都需要投入大量的人力成本。

基于此,2014 年初我们启动了一期自动化运维平台研发的项目,2014 年 10 月项目一期上线时,已基本解决了开仓慢和人力成本的问题,也减少了开仓过程中运维同学的重复性工作内容,制定标准化模板,解放了研发人员的重复性部署工作。运营人员可通过模板直接设置,将之前一些繁琐的密码、JMQ Token 等数据实现自动化配置,大大减少了流程耗费的时间。

一期上线后,得到了流程中各环节涉及部门的赞赏,并在得到大家积极反馈后,迅速进入到二期项目。二期项目完成后,数据的初始化问题和研发日常批量部署问题也得到了解决,系统的自动化程度已可以满足日常的工作需求。

今年初,为接入更多物流作业单位,如分拣中心, 亚洲一号自动化物流中心等,我们开启了三期项目,目前项目还在持续前行中。

InfoQ:谈谈你们的自动化运维架构?以及具体涉及到的技术栈?

赵玉开: 我们的自动化运维的核心组件是 SaltStack, 我们基于 SaltStack 做了很多自定义的模块、Grains 和 Runner, 通过这些自定义的模块、Grains 以及 Runner 来支撑我们的开仓、部署、数据同步等功能。

如下图是一个指令执行过程图, 分为两个部分, 上面部分为部署在 IDC 的模块, 下半部分则是部署在库房机房的模块。

我们先逐个介绍部署在 IDC 部分的模块:

  1. Web 使用 Java 技术, 为用户提供操作界面, 控制操作权限, 使用 Activiti 工作流引擎驱动各种流程, 下发开仓过程中的自动化运维指令;
  1. Salt-API-Proxy 是 Salt-API 的代理层, 通过 Nginx 实现了反向代理, 在 Nginx 的配置中对发送指令的服务器 IP 做了限制, 另外可以通过配置指向工作的 Salt-API 服务器;
  1. Salt-API 负责和 Salt-Master 交互发送 SaltStack 的 Runner 与 Module 的 API 指令, Runner 指令是运行在 Salt-Master 服务器上的, 可以读取 master 配置, 也可以在一个 Runner 中协调执行多个 Module 运行结果;
  1. Salt-Master 有两个职责, 一是接受 salt-api 指令, runner 在本地执行, module 下发指令到对应的 salt-minion, 另一职责是运维同学手动下发指令, 完成一些非常见的 minion 配置工作;

  2. RsyncServer 负责中间件安装文件, 自研软件的文件存储和下发, RsyncServer 的文件存储是由 Salt-Master 发起的, Salt-Master 接受到 salt-api 的应用部署指令后, 会从部署指令中获得部署包下载地址, 然后下载到指定部署包存储目录, 并做解压操作; RsyncServer 的文件下发指令则是有 salt-minion 端的 Module 执行触发的。

仓库部门和 IDC 之间通过 VPN 联通, 每个仓库的服务器上都安装了 SaltStack 的 minion 端, minion 端是一个 Python 进程, 负责接收 Master 的 Module 指令, 并在本地执行。另外 minion 端在执行指令过程中需要将执行过程中的输出及时的输出给用户端, 让用户可以通过 Web 端查看执行过程的情况, 即运维的可视化, 我们是通过 minion 端的可视化模块, 将执行过程输出通过 HTTP POST 方式发送给 Web 端, Web 端将 POST 内容存储到任务执行过程输出表中, 前端通过轮询方式读取输出表中的增量消息显示给用户端。

我们采用的技术栈是 Java + Python。  前端界面展示、 工作流、权限控制、任务下发这些都是用的 Java 的 Spring MVC + MyBatis; 后端用的是 Python + Shell, Python 写了大量的 SaltStack 自定义模块。

InfoQ:为什么当初要选择 SaltStack 而没有选择 Ansible?

赵玉开: 不可否认 Ansible 也是一个非常好的自动化运维工具, 但是基于以下两点我们最终选择了 SaltStack:

  1. API 的易用性方面和 SaltStack 有差距, 我们的自动化运维系统一开始就有一个目标, 将开仓部署以及推广版本这些功能开放给物流运营人员, 所以必须做好前端用户体验, 这需要好用的 API, SaltStack 恰好有;
  1. 性能,标准 SSH 连接的时候比较耗时,ZeroMQ 传输的速度会快很多。

InfoQ:在应用部署自动化这块,你们是怎么做的?

赵玉开: 应用部署大致分为这么几个步骤: 打包、下发文件、更新配置、停止启动实例、备份部署版本, 具体如下。

  1. 我们使用的公司统一的打包系统, 打包系统打好包, 部署任务审批通过,自动化运维系统就可以通过 API 获得打包文件, 然后将部署包上传到版本服务器, 并解压缩,放到对应版本目录下;
  1. 通过 SaltStack 的 API 下发部署指令给部署目标服务器, 部署指令是一个 SaltStack 自定义模块, 该模块首先会执行 rsync 指令从版本服务器上同步变更文件;
  1. 文件下发之后更新配置, 通过 Web 接口请求自动化运维的 Web 端下发配置文件, 然后更新配置文件, 我们线上的配置文件是通过环境变量来配置的, 所以不管有多少个库房, 都不需要更新配置文件, 只有在特殊需求是设置环境变量, 就可以依据当前作业单位的不同改变下发的配置文件的内容;
  1. 调用应用的 stop.sh 脚本停止当前实例, 再调用 start.sh 脚本启动实例, 这里有一个约定, 不管是 Web 应用还是非 Web 应用必须在部署目录有一个 bin 目录下面有 start.sh 和 stop.sh 两个文件;

  2. 如果步骤 4 执行成功, 那么将此版本的文件备份到当前服务器上, 以备回滚使用。

InfoQ:自动化运维解决了你们哪些问题?没有解决哪些问题?

赵玉开: 自动化运维解决了我们开仓周期长,人力成本高的问题, 提升了全国部署推广的效率, 大大减少了运维同事的重复性工作, 把对成熟版本的推广工作交给了运营人员, 减少了研发同事在推广上线工作上的时间。

现阶段正在探索如何通过自动化运维技术快速排查问题, 另外就是我们未来会有一些自动化的物流作业单位,如何用自动化运维平台管理好这些自动化的设备和设备软件也是我们在探索的。

InfoQ:自动化运维平台上线了这么长时间,有做过复盘吗?有哪些经验可以分享给读者?未来有什么计划?

赵玉开: 做过一些复盘, 每一期开发结束下一迭代开始的时候都会做复盘, 对现有问题进行总结, 同时收集下一步的需求。  目前看最深刻的体会是做自动化运维系统一定要做好元数据的管理,元数据要管理好服务器信息属性、 应用信息、应用配置、实例管理以及作业单位, 这些元数据要在一开始就做好, 能自动化收集的要自动化收集, 动态的参数一定要动态控制, 比如 Redis、MySQL 都有主从关系, 元数据中要存储这个主从关系, 但是不能写死, 必须有机制来更新主从关系, 否则 Redis 哨兵程序更新了 Redis 主从关系, 或者 MySQL DBA 因为某些原因切换了 MySQL 的主从, 自动化运维系统的元数据没有做对应更新,再执行指令时就会出问题, 甚至发生事故。

未来计划有两个方面:

  1. 继续通过自动化运维系统来提升运维效率、 降低研发对应用运维的投入;
  1. 做自动化物流作业系统的自动化运维, 管好其中的设备和软件服务。

InfoQ:在 CNUTCon 全球运维技术大会 上,你将会为读者分享哪些技术点?

赵玉开: 这次大会我会给大家介绍下京东物流自动化运维平台的技术架构, 并详细介绍自动化开仓、批量部署的技术细节。


CNUTCon 全球运维技术大会将于 9 月 10-11 日在上海举行,大会以“智能时代的新运维”为主题,涵盖 AIOps、SRE、DevOps、运维监控与安全等专场,邀请了来自 Google、Uber、eBay、BAT、携程、京东等公司大咖分享他们在最新运维技术实践过程中遇到的坑与经验,现场为你解疑答惑,点击“阅读原文”了解更多精彩!9 折限时优惠,报名时输入 CNUTCon-KAITAO 还可再减 200 !

master:

节点node1:阿里云:121.42.195.15 centos6.6

  --------------------------------------分割线

shell > cat /etc/ansible/roles/install_zabbix_agent/tasks/main.yml

---
  - name: Install Software
    yum: name={{ item }} state=latest
    with_items:
      - libcurl-devel
  - name: Create Zabbix User
    user: name={{ zabbix_user }} state=present createhome=no shell=/sbin/nologin
  - name: Copy Zabbix.tar.gz
    copy: src=zabbix-{{ zabbix_version }}.tar.gz dest={{ zabbix_dir }}/src/zabbix-{{ zabbix_version }}.tar.gz owner=root group=root
  - name: Uncompression Zabbix.tar.gz
    shell: tar zxf {{ zabbix_dir }}/src/zabbix-{{ zabbix_version }}.tar.gz -C {{ zabbix_dir }}/
  - name: Copy Zabbix Start Script
    template: src=zabbix_agentd dest=/etc/init.d/zabbix_agentd owner=root group=root mode=0755
  - name: Copy Zabbix Config File
    template: src=zabbix_agentd.conf dest={{ zabbix_dir }}/zabbix/etc/zabbix_agentd.conf owner={{ zabbix_user }} group={{ zabbix_user }} mode=0644
  - name: Modify Zabbix Dir Permisson
    file: path={{ zabbix_dir }}/zabbix owner={{ zabbix_user }} group={{ zabbix_user }} mode=0755 recurse=yes
  - name: Start Zabbix Service
    shell: /etc/init.d/zabbix_agentd start
  - name: Add Boot Start Zabbix Service
    shell: chkconfig --level 35 zabbix_agentd on

什么是 saltstack

你要是 naive 地问:部署服务器,有什么好难的?不就写个脚本,再 one by one 地 ssh 这些服务器跑一遍吗?

服务器少还好办,几台、几十台一般人尚可承受但,再不济多配几个运维(貌似无意间黑了一下运维,嘻嘻)嘛~

但,假如你有成百上千台服务器需要部署,你会怎么做?想象一下你每次 one by one 地登陆这些服务器,在这些服务器中执行同样的命令并且编辑同一个配置文件,这他妈完全是重复性操作啊,人呐,重复性劳动做多了难免会犯错,要是稍微不留意手一抖配错了咋办?即使侥幸部署成功,将来需要更改配置,所有的线上环境都要同步变更,你再让我 one by one 地操作这些服务器?!

我的天呐~我疯了吗!

澳门新濠3559 3

技术人的自我修养之一:如果一条命令重复了两次,你就要交给机器去做。

那么,问题来了:

怎么样通过一个命令一次完成所有服务器的部署操作?

在这种情况下,一些批量部署的工具应运而生,比如 puppet,saltstack,chef 等等……

saltstack 是使用 python 编写的开源自动化部署与管理工具,它取 Puppet 和 Chef 二者之所长整合之,拥有良好的扩展性以及优秀的执行效率,配置简单,跨平台,适合大规模批量管理服务器。

minion:

节点node2:腾讯云:182.254.157.19 centos6.6

  --------------------------------------分割线

shell > cat /etc/ansible/roles/install_zabbix_agent/vars/main.yml

zabbix_dir: /usr/local
zabbix_version: 2.4.5
zabbix_user: zabbix
zabbix_port: 10050
zabbix_server_ip: 131.142.101.120

saltstack 原理

Saltstack 基于 C/S 架构,服务端 master 和客户端 minions。minion 与 master 之间通过 ZeroMQ 消息队列通信,使用了 ZeroMq 的 发布-订阅模式。。

master 监听 45054506 端口:

  • 4505 对应的是 ZMQ 的 PUB system,用来发送消息
  • 4506 对应的是 ZMQ 的 REP system,是来接受消息

minion 查看自身的 ID:

vdna@debian:~$ cat /etc/salt/minion_id
foo.domain.com

minion 需配置 /etc/salt/minionmaster 的地址,上线后与 master 端联系,把自己的 pub key 发过去,。

 14 # Set the location of the salt master server. If the master server cannot be
 15 # resolved, then the minion will fail to start.
 16 master: 192.168.10.52

这时 master 端通过 salt-key -L 命令就会看到 minionminion_id:

hxz@pc0170:/srv$ salt-key -L
Accepted Keys:
Denied Keys:
Unaccepted Keys:
foo.domain.com
Rejected Keys:

注意:

安全起见,在接受 minion 之前,master 和 minion 的公钥必须互相验证。

在 master 端运行 salt-key -F master

hxz@pc0170:/srv$ salt-key -F master
Password:
Local Keys:
master.pem:  00:cc:4f:6c:8e:63:4e:c3:66:33:e3:a9:28:01:6c:82
master.pub:  eb:7e:e1:5b:a8:f2:93:68:7c:17:aa:3e:fa:3a:53:e9

然后在 minion 端将输出来的 master.pub 值设为 /etc/salt/minion 中的 maste_finger。

486 # Fingerprint of the master public key to double verify the master is valid,
487 # the master fingerprint can be found by running "salt-key -F master" on the
488 # salt master.
489 master_finger: 'eb:7e:e1:5b:a8:f2:93:68:7c:17:aa:3e:fa:3a:53:e9'

在 master 端, 运行 salt-key -f minion-id 查看对应 minion 的公钥:

salt-key -f foo.domain.com
Unaccepted Keys:
foo.domain.com:  39:f9:e4:8a:aa:74:8d:52:1a:ec:92:03:82:09:c8:f9

在 minion 端,运行 salt-call key.finger --local 查看自身的公钥:

salt-call key.finger --local
local:
    39:f9:e4:8a:aa:74:8d:52:1a:ec:92:03:82:09:c8:f9

如果它们匹配的话,那么 master 可以通过运行 salt-key -a foo.domain.com 放心地接受这个 minion。

hxz@pc0170:/srv$ salt-key -a foo.domain.com
The following keys are going to be accepted:
Unaccepted Keys:
foo.domain.com
Proceed? [n/Y] y
Key for minion webserver_qa accepted.

好啦,master 和 minion 彼此都对上眼了,现在 master 可以发送任何指令让 minion 执行了,salt 有很多可执行模块,master 下发任务到匹配的 minion 上去,minion 执行模块函数,并返回结果。

一、saltstack快速配置

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

  2. saltstack相关网站


  3. saltstack三种运行方式

  4. 本地

  5. 客户端(奴才)运行
  6. saltstackSSH
  7. 运行的操作系统
  8. 特点
    (1)、部署简单、方便;
    (2)、支持大部分UNIX/Linux及Windows环境;
    (3)、主从集中化管理;
    (4)、配置简单、功能强大、扩展性强;
    (5)、主控端(master)和被控端(minion)基于证书认证,安全可靠;
    (6)、支持API及自定义模块,可通过Python轻松扩展。

安装:

  --------------------------------------分割线

shell > cat /etc/ansible/roles/install_zabbix_agent/templates/zabbix_agentd

#!/bin/bash
#
# chkconfig: - 90 10
# description:  Starts and stops Zabbix Agent using chkconfig
#                               Tested on Fedora Core 2 - 5
#                               Should work on all Fedora Core versions
#
# @name:        zabbix_agentd
# @author:      Alexander Hagenah <[email protected]>
# @created:     18.04.2006
#
# Modified for Zabbix 2.0.0
# May 2012, Zabbix SIA
#
# Source function library.
. /etc/init.d/functions

# Variables
# Edit these to match your system settings

        # Zabbix-Directory
        BASEDIR={{ zabbix_dir }}/zabbix

        # Binary File
        BINARY_NAME=zabbix_agentd

        # Full Binary File Call
        FULLPATH=$BASEDIR/sbin/$BINARY_NAME

        # PID file
        PIDFILE=/tmp/$BINARY_NAME.pid

        # Establish args
        ERROR=0
        STOPPING=0

#
# No need to edit the things below
#

# application checking status
if [ -f $PIDFILE  ] && [ -s $PIDFILE ]
        then
        PID=`cat $PIDFILE`

        if [ "x$PID" != "x" ] && kill -0 $PID 2>/dev/null && [ $BINARY_NAME == `ps -e | grep $PID | awk '{print $4}'` ]
        then
                STATUS="$BINARY_NAME (pid `pidof $APP`) running.."
                RUNNING=1
        else
                rm -f $PIDFILE
                STATUS="$BINARY_NAME (pid file existed ($PID) and now removed) not running.."
                RUNNING=0
        fi
else
        if [ `ps -e | grep $BINARY_NAME | head -1 | awk '{ print $1 }'` ]
                then
                STATUS="$BINARY_NAME (pid `pidof $APP`, but no pid file) running.."
        else
                STATUS="$BINARY_NAME (no pid file) not running"
        fi
        RUNNING=0
fi

# functions
start() {
        if [ $RUNNING -eq 1 ]
                then
                echo "$0 $ARG: $BINARY_NAME (pid $PID) already running"
        else
                action $"Starting $BINARY_NAME: " $FULLPATH
                touch /var/lock/subsys/$BINARY_NAME
        fi
}

stop() {
        echo -n $"Shutting down $BINARY_NAME: "
        killproc $BINARY_NAME
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$BINARY_NAME
        RUNNING=0
}


# logic
case "$1" in
        start)
                start
                ;;
        stop)
                stop
                ;;
        status)
                status $BINARY_NAME
                ;;
        restart)
                stop
                sleep 10
                start
                ;;
        help|*)
                echo $"Usage: $0 {start|stop|status|restart|help}"
                cat <<EOF

                        start           - start $BINARY_NAME
                        stop            - stop $BINARY_NAME
                        status          - show current status of $BINARY_NAME
                        restart         - restart $BINARY_NAME if running by sending a SIGHUP or start if not running
                        help            - this screen

EOF
        exit 1
        ;;
esac

exit 0

 

shell > cat /etc/ansible/roles/install_zabbix_agent/templates/zabbix_agentd.conf

# This is a config file for the Zabbix agent daemon (Unix)
# To get more information about Zabbix, visit http://www.zabbix.com

############ GENERAL PARAMETERS #################

### Option: PidFile
#       Name of PID file.
#
# Mandatory: no
# Default:
# PidFile=/tmp/zabbix_agentd.pid

### Option: LogFile
#       Name of log file.
#       If not set, syslog is used.
#
# Mandatory: no
# Default:
# LogFile=

LogFile=/tmp/zabbix_agentd.log

### Option: LogFileSize
#       Maximum size of log file in MB.
#       0 - disable automatic log rotation.
#
# Mandatory: no
# Range: 0-1024
# Default:
# LogFileSize=1

### Option: DebugLevel
#       Specifies debug level
#       0 - basic information about starting and stopping of Zabbix processes
#       1 - critical information
#       2 - error information
#       3 - warnings
#       4 - for debugging (produces lots of information)
#
# Mandatory: no
# Range: 0-4
# Default:
# DebugLevel=3

### Option: SourceIP
#       Source IP address for outgoing connections.
#
# Mandatory: no
# Default:
# SourceIP=

### Option: EnableRemoteCommands
#       Whether remote commands from Zabbix server are allowed.
#       0 - not allowed
#       1 - allowed
#
# Mandatory: no
# Default:
# EnableRemoteCommands=0

### Option: LogRemoteCommands
#       Enable logging of executed shell commands as warnings.
#       0 - disabled
#       1 - enabled
#
# Mandatory: no
# Default:
# LogRemoteCommands=0

##### Passive checks related

### Option: Server
#       List of comma delimited IP addresses (or hostnames) of Zabbix servers.
#       Incoming connections will be accepted only from the hosts listed here.
#       If IPv6 support is enabled then '127.0.0.1', '::127.0.0.1', '::ffff:127.0.0.1' are treated equally.
#
# Mandatory: no
# Default:
# Server=

Server={{ zabbix_server_ip }}

### Option: ListenPort
#       Agent will listen on this port for connections from the server.
#
# Mandatory: no
# Range: 1024-32767
# Default:
# ListenPort=10050
ListenPort={{ zabbix_port }}

### Option: ListenIP
#       List of comma delimited IP addresses that the agent should listen on.
#       First IP address is sent to Zabbix server if connecting to it to retrieve list of active checks.
#
# Mandatory: no
# Default:
# ListenIP=0.0.0.0

### Option: StartAgents
#       Number of pre-forked instances of zabbix_agentd that process passive checks.
#       If set to 0, disables passive checks and the agent will not listen on any TCP port.
#
# Mandatory: no
# Range: 0-100
# Default:
# StartAgents=3

##### Active checks related

### Option: ServerActive
#       List of comma delimited IP:port (or hostname:port) pairs of Zabbix servers for active checks.
#       If port is not specified, default port is used.
#       IPv6 addresses must be enclosed in square brackets if port for that host is specified.
#       If port is not specified, square brackets for IPv6 addresses are optional.
#       If this parameter is not specified, active checks are disabled.
#       Example: ServerActive=127.0.0.1:20051,zabbix.domain,[::1]:30051,::1,[12fc::1]
#
# Mandatory: no
# Default:
# ServerActive=

#ServerActive=127.0.0.1:10051

### Option: Hostname
#       Unique, case sensitive hostname.
#       Required for active checks and must match hostname as configured on the server.
#       Value is acquired from HostnameItem if undefined.
#
# Mandatory: no
# Default:
# Hostname=

Hostname={{ ansible_all_ipv4_addresses[1] }}

### Option: HostnameItem
#       Item used for generating Hostname if it is undefined. Ignored if Hostname is defined.
#       Does not support UserParameters or aliases.
#
# Mandatory: no
# Default:
# HostnameItem=system.hostname

### Option: HostMetadata
#       Optional parameter that defines host metadata.
#       Host metadata is used at host auto-registration process.
#       An agent will issue an error and not start if the value is over limit of 255 characters.
#       If not defined, value will be acquired from HostMetadataItem.
#
# Mandatory: no
# Range: 0-255 characters
# Default:
# HostMetadata=

### Option: HostMetadataItem
#       Optional parameter that defines an item used for getting host metadata.
#       Host metadata is used at host auto-registration process.
#       During an auto-registration request an agent will log a warning message if
#       the value returned by specified item is over limit of 255 characters.
#       This option is only used when HostMetadata is not defined.
#
# Mandatory: no
# Default:
# HostMetadataItem=

### Option: RefreshActiveChecks
#       How often list of active checks is refreshed, in seconds.
#
# Mandatory: no
# Range: 60-3600
# Default:
# RefreshActiveChecks=120

### Option: BufferSend
#       Do not keep data longer than N seconds in buffer.
#
# Mandatory: no
# Range: 1-3600
# Default:
# BufferSend=5

### Option: BufferSize
#       Maximum number of values in a memory buffer. The agent will send
#       all collected data to Zabbix Server or Proxy if the buffer is full.
#
# Mandatory: no
# Range: 2-65535
# Default:
# BufferSize=100

### Option: MaxLinesPerSecond
#       Maximum number of new lines the agent will send per second to Zabbix Server
#       or Proxy processing 'log' and 'logrt' active checks.
#       The provided value will be overridden by the parameter 'maxlines',
#       provided in 'log' or 'logrt' item keys.
#
# Mandatory: no
# Range: 1-1000
# Default:
# MaxLinesPerSecond=100

############ ADVANCED PARAMETERS #################

### Option: Alias
#       Sets an alias for an item key. It can be used to substitute long and complex item key with a smaller and simpler one.
#       Multiple Alias parameters may be present. Multiple parameters with the same Alias key are not allowed.
#       Different Alias keys may reference the same item key.
#       For example, to retrieve the ID of user 'zabbix':
#       Alias=zabbix.userid:vfs.file.regexp[/etc/passwd,^zabbix:.:([0-9]+),,,,1]
#       Now shorthand key zabbix.userid may be used to retrieve data.
#       Aliases can be used in HostMetadataItem but not in HostnameItem parameters.
#
# Mandatory: no
# Range:
# Default:

### Option: Timeout
#       Spend no more than Timeout seconds on processing
#
# Mandatory: no
# Range: 1-30
# Default:
Timeout=20

### Option: AllowRoot
#       Allow the agent to run as 'root'. If disabled and the agent is started by 'root', the agent
#       will try to switch to the user specified by the User configuration option instead.
#       Has no effect if started under a regular user.
#       0 - do not allow
#       1 - allow
#
# Mandatory: no
# Default:
# AllowRoot=0

### Option: User
#       Drop privileges to a specific, existing user on the system.
#       Only has effect if run as 'root' and AllowRoot is disabled.
#
# Mandatory: no
# Default:
# User=zabbix

### Option: Include
#       You may include individual files or all files in a directory in the configuration file.
#       Installing Zabbix will create include directory in /usr/local/etc, unless modified during the compile time.
#
# Mandatory: no
# Default:
# Include=

# Include=/usr/local/etc/zabbix_agentd.userparams.conf
# Include=/usr/local/etc/zabbix_agentd.conf.d/
# Include=/usr/local/etc/zabbix_agentd.conf.d/*.conf

####### USER-DEFINED MONITORED PARAMETERS #######

### Option: UnsafeUserParameters
#       Allow all characters to be passed in arguments to user-defined parameters.
#       0 - do not allow
#       1 - allow
#
# Mandatory: no
# Range: 0-1
# Default:
UnsafeUserParameters=1

### Option: UserParameter
#       User-defined parameter to monitor. There can be several user-defined parameters.
#       Format: UserParameter=<key>,<shell command>
#       See 'zabbix_agentd' directory for examples.
#
# Mandatory: no
# Default:
# UserParameter=

####### LOADABLE MODULES #######

### Option: LoadModulePath
#       Full path to location of agent modules.
#       Default depends on compilation options.
#
# Mandatory: no
# Default:
# LoadModulePath=${libdir}/modules

### Option: LoadModule
#       Module to load at agent startup. Modules are used to extend functionality of the agent.
#       Format: LoadModule=<module.so>
#       The modules must be located in directory specified by LoadModulePath.
#       It is allowed to include multiple LoadModule parameters.
#
# Mandatory: no
# Default:
# LoadModule=

4、执行安装

shell > ansible-playbook /etc/ansible/install_zabbix_agent.yml

PLAY [mini] *******************************************************************

GATHERING FACTS ***************************************************************
ok: [129.139.153.78]
ok: [155.139.190.94]

TASK: [install_zabbix_agent | Install Software] *******************************
changed: [155.139.190.94] => (item=libcurl-devel)
changed: [129.139.153.78] => (item=libcurl-devel)

TASK: [install_zabbix_agent | Create Zabbix User] *****************************
changed: [129.139.153.78]
changed: [155.139.190.94]

TASK: [install_zabbix_agent | Copy Zabbix.tar.gz] *****************************
changed: [129.139.153.78]
changed: [155.139.190.94]

TASK: [install_zabbix_agent | Uncompression Zabbix.tar.gz] ********************
changed: [129.139.153.78]
changed: [155.139.190.94]

TASK: [install_zabbix_agent | Copy Zabbix Start Script] ***********************
changed: [155.139.190.94]
changed: [129.139.153.78]

TASK: [install_zabbix_agent | Copy Zabbix Config File] ************************
changed: [129.139.153.78]
changed: [155.139.190.94]

TASK: [install_zabbix_agent | Modify Zabbix Dir Permisson] ********************
changed: [155.139.190.94]
changed: [129.139.153.78]

TASK: [install_zabbix_agent | Start Zabbix Service] ***************************
changed: [129.139.153.78]
changed: [155.139.190.94]

TASK: [install_zabbix_agent | Add Boot Start Zabbix Service] ******************
changed: [129.139.153.78]
changed: [155.139.190.94]

PLAY RECAP ********************************************************************
155.139.190.94               : ok=10   changed=9    unreachable=0    failed=0
129.139.153.78               : ok=10   changed=9    unreachable=0    failed=0

## 关注一下,启动脚本跟配置文件中变量的引用。
## 完成安装,可以去客户机检查效果了 !

附上:delete_zabbix_agent.yml 相关内容

shell > vim /etc/ansible/delete_zabbix_agent.yml

---
- hosts: mini
  roles:
  - delete_zabbix_agent

shell > vim /etc/ansible/roles/delete_zabbix_agent/tasks/main.yml

---
- name: Stop Zabbix_agent
  shell: pgrep zabbix_agentd | xargs kill
  ignore_errors: yes
- name: Delete Boot Start
  shell: chkconfig --del zabbix_agentd
- name: Delete Start Script
  shell: rm -rf /etc/init.d/zabbix_agentd
- name: Delete Install Dir
  shell: rm -rf {{ zabbix_dir }}/zabbix
- name: Delete Software
  shell: rm -rf {{ zabbix_dir }}/src/zabbix-{{ zabbix_version }}.tar.gz
- name: Delete Log File
  shell: rm -rf /tmp/zabbix_agentd.log
- name: Delete Zabbix User
  user: name={{ zabbix_user }} state=absent remove=yes

shell > vim /etc/ansible/roles/delete_zabbix_agent/vars/main.yml

zabbix_dir: /usr/local
zabbix_version: 2.4.5
zabbix_user: zabbix

# End

使用 Ansible 高效交付 Docker 容器 

使用Ansible批量管理远程服务器 

Ansible安装配置与简单使用 

在 CentOS 7 中安装并使用自动化工具 Ansible 

Ansible和Docker的作用和用法 

Ansible批量搭建LAMP环境

Ansible :一个配置管理和IT自动化工具 

Ansible 的详细介绍:请点这里
Ansible 的下载地址:请点这里

本文永久更新链接地址:

运维自动化 ( 配置管理工具 ) 简介: 当下有许多的运维自动化工具( 配置管理 ),例如:Ansible、SaltStack、Puppet、Fabric 等。 Ansible 一种...

举个栗子

salt '*' test.ping 具体步骤如下:

  • salt 命令,将 test.ping 命令从 salt.client.LocalClient.cmd_cli 发布到 master,获取一个 Jodid ,根据Jodid 获取命令执行结果。
  • master 接收到命令后,将要执行的命令发送给客户端 minion
  • minion 从消息总线上接收到要处理的命令,交给 minion._handle_aes 处理。
  • minion._handle_aes 发起一个本地线程调用 test 模块执行 ping 命令(不是那个 ICMP ping 命令,只是为了检测 minion 是否有响应)。线程执行完后,调用 minion._return_pub 方法,将执行结果通过消息总线返回给 master
  • master 接收到客户端返回的结果,调用 master._handle_aes 方法,将结果写到文件中。
  • salt.client.LocalClient.cmd_cli 通过轮询获取 Job 执行结果,将结果输出到终端。
hxz@pc0170:/srv$ salt "*" test.ping
foo.domain.com:
    True
1.master安装

节点:node1

#yum install salt-master -y

salt

salt 是最常用的一个命令,用法:

Usage: salt [options] '<target>' <function> [arguments]

salt '*' test.ping 为例:

  • '*' (这两个引号不能少,很蛋疼的)代表的是 target,是指在哪些 minion 上操作
  • test 是一个执行模块
  • ping 是执行模块下面的函数

关于 salt 有哪些可执行模块,模块下面有哪些函数,可以通过 sys.doc 命令查看帮助:

salt "*" sys.doc           ##查看所有执行模块的doc 
salt "*" sys.doc test      ##查看test模块的帮助 
salt "*" sys.doc test.ping ##查看test.ping函数的帮助
2.minion安装
#yum install salt-minion -y

实用命令

cmd 模块包含了许多和命令行相关的函数,比如 cmd.run 和 cmd.re_run

salt '*' cmd.run 'ls -l /etc'

pkg 模块会自动地将本地系统的包管理器映射到 salt 中,这意味着 pkg.install vim 将自动地在 Red Hat系统中调用 yum,在Debian系统中调用apt-get,在Osx系统中调用 brew 安装 vim

salt '*' pkg.install vim

network.interfaces 方法会列出 minion 中所有的网络接口,包括 IP 地址、子网掩码、MAC 地址等:

salt '*' network.interfaces
3.启动:
 [root@node1 ~]#/etc/init.d/salt-master start

salt-call

目前为止,介绍的大部分 master 端命令都是 salt,但有时为了查找、定位问题,使用 salt-call 直接登陆到 minion 是非常实用的,你可以查看当你在 master 端执行命令后 minion 端具体的 log 信息(其中有些信息你在 master 端是无法看到的)。更多关于 salt-call 的信息可以参考here

4.配置文件
[root@node1 ~]# ll /etc/salt/
total 36
-rw-r----- 1 root root 29543 Dec  2 05:06 master
drwxr-xr-x 3 root root  4096 Mar 13 17:20 pki

我是华丽的分隔符

[root@node2 ~]# ll /etc/salt/
total 28
-rw-r----- 1 root root 26229 Dec  2 05:06 minion

Grains

salt 通过系统调用的方式来收集 minion 端本机的数据信息,包括操作系统、CPU、内存等信息。它同样可以包含静态数据集,这使得 minions 可以方便的进行分组、管理。

通常的做法是将 grains 分配给 minions 并指定每个 minion 的角色。这些静态 grains 可以在 minon 的配置文件或通过 grains.setval 方法来设置。

5.minion修改配置文件连接到master
[root@node2 ~]# vim /etc/salt/minion
修改16行:ip地址为master的节点ip
16 master: 121.42.195.15
修改74行minion主机名,方便master管理
74 id: node2.minion
重启
/etc/init.d/salt-minion restart

master端查看要链接的minion

[root@node1 ~]# salt-key
Accepted Keys:
Denied Keys:
Unaccepted Keys:
centos66 #没修改之前的minion主机名
node2.minion #修改之后的minion主机名
Rejected Keys:

开始链接

[root@node1 ~]# salt-key -a node2.minion #salt-key -a命令 hostname
The following keys are going to be accepted:
Unaccepted Keys:
node2.minion
Proceed? [n/Y] y
Key for minion node2.minion accepted.

查看已经认证的minion列表:

[root@node1 ~]# salt-key
Accepted Keys: #已经认证的minion主机名
node2.minion
Denied Keys:
Unaccepted Keys: #等待认证的主机名
centos66
Rejected Keys:

查看链接是否正常

[root@node1 ~]# salt '*' test.ping
node2.minion:
True
*号代表所有主机
或:
[root@node1 ~]# salt 'node2.minion' test.ping
node2.minion:
True

防火墙:

iptables -I INPUT -m state --state new -m tcp -p tcp --dport 4505 -j ACCEPT
iptables -I INPUT -m state --state new -m tcp -p tcp --dport 4506 -j ACCEPT

Target

salt 有多种方式来指定哪些 minion 来执行 master 分发的命令,默认采用 minion_id * 匹配模式,比如:现有多个 minons 其 minion_id 分别为 larry1, larry2, curly1curly2, larry* 将会匹配到 larry1larry2, *1将会匹配到 larry1curly1

其他的匹配方式:

  • 正则匹配:利用正则表达式
  • Grains:利用 Grains 数据,参考:�here
  • Pillar:利用 Pillar 数据,参考:�here
  • IP:利用 IP地址、子网、区段等信息
  • Compound:在多个目标中建立逻辑关系,参考here
  • Nodegroup:参考here

6.配置管理

1.配置安装模板
修改master配置文件

#引入配置文件
12 default_include: master.d/*.conf
15 interface: 0.0.0.0
saltstack状态文件
406 file_roots:
407   base:   #开头两个空格   #基础环境
408     - /etc/salt/states  #开头四个空格 #基础环境目录
409   prod:   #生产环境
410     - /etc/salt/states/prod  #生产环境目录
329 state_top: top.sls #配置文件名 在base下的目录下 默认
保存退出
创建模板所在目录
[root@node1 ~]# mkdir /etc/salt/states/prod -p
重启master
[root@node1 ~]# /etc/init.d/salt-master restart
Stopping salt-master daemon:                               [  OK  ]
Starting salt-master daemon:                               [  OK  ]

日志文件:

[root@node1 ~]# tail /var/log/salt/master 

创建配置文件

[root@node1 ~]# cd /etc/salt/states/
[root@node1 states]# vim top.sls

内容如下

base:             #基本配置
 'node2.minion':  #对这个主机进行操作
   - init.pkg      #使用init目录下的pkg配置文件
保存退出

创建pkg配置文件

[root@node1 states]# mkdir init
[root@node1 states]# cd init/
[root@node1 init]# vim pkg.sls

写入如下内容(空格必须要正确 否则会失败)

pkg.init:  #配置文件名
  pkg.installed: #进行安装操作(2空格)
    - names:                #(4空格)
      - lrzsz     #软件包名  
      - htop      #软件包名
      - nmap      #软件包名
保存退出

总结:
定义base基础环境和prod生成环境目录
开启top.sls
salt工具会根据你定义的基础环境目录下的top.sls进行操作

使用此模板进行操作:

[root@node1 init]# salt '*' state.sls init.pkg
#state是模块 sls是state模块的方法 init.pkg是自定义的模板

运行结果:

node2.minion:
----------
          ID: pkg.init
Function: pkg.installed
    Name: nmap
  Result: True
 Comment: The following packages were installed/updated: nmap
 Started: 22:01:31.299862
Duration: 22179.522 ms
 Changes:   
          ----------
          nmap:
              ----------
              new:
                  5.51-4.el6
              old:
----------
      ID: pkg.init
Function: pkg.installed
    Name: lrzsz
  Result: True
 Comment: Package lrzsz is already installed.
 Started: 22:01:53.485854
Duration: 0.489 ms
 Changes:   
Summary
------------
Succeeded: 2 (changed=1)
Failed:    0
------------
Total states run:     2

方法案例2:管理文件
使用salt管理 /etc/security/limits.conf

[root@node1 salt]# cd /etc/salt/states/init/
[root@node1 init]# vim limit.sls

内容如下:

limit.conf.config:
  file.managed:
   - name: /etc/security/limits.conf
   - source: salt://init/files/limits.conf
   - user: root
   - group: root
   - mode: 644
保存退出

配置所需目录和文件

[root@node1 init]# mkdir files
[root@node1 init]# cp /etc/security/limits.conf .files/

在top.sls里增加

base:
 'node2.minion':
   - init.pkg
   - init.limit

执行命令

[root@node1 init]# salt '*' state.highstate

结果:

node2.minion:
----------
      ID: pkg.init
Function: pkg.installed
    Name: nmap
  Result: True
 Comment: Package nmap is already installed.
 Started: 22:51:09.699088
Duration: 568.249 ms
 Changes:   
----------
      ID: pkg.init
Function: pkg.installed
    Name: lrzsz
  Result: True
 Comment: Package lrzsz is already installed.
 Started: 22:51:10.267485
Duration: 0.409 ms
 Changes:   
----------
      ID: limit..conf.config
Function: file.managed
    Name: /etc/security/limits.conf
  Result: True
 Comment: File /etc/security/limits.conf updated
 Started: 22:51:10.269850
Duration: 138.081 ms
 Changes:   
          ----------
          diff:
              ---  
              +++  
              @@ -6,7 +6,7 @@
               #
               #Where:
               #<domain> can be:
              -#        - a user name
              +#        - an user name
               #        - a group name, with @group syntax
               #        - the wildcard *, for default entry
               #        - the wildcard %, can be also used with %group syntax,
              @@ -21,7 +21,7 @@
               #        - data - max data size (KB)
               #        - fsize - maximum filesize (KB)
               #        - memlock - max locked-in-memory address space (KB)
              -#        - nofile - max number of open file descriptors
              +#        - nofile - max number of open files
               #        - rss - max resident set size (KB)
               #        - stack - max stack size (KB)
               #        - cpu - max CPU time (MIN)
              @@ -48,11 +48,5 @@
               #@student        -       maxlogins       4

               # End of file
              -@users soft nofile 100001
              -@users hard nofile 100002
              -@root  soft nofile 100001
              -@root  hard nofile 100002
              -* soft nproc 65535
              -* hard nproc 65535
               * soft nofile 65535
               * hard nofile 65535

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

7.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发送指令了。
8.Master与Minion的连接
(1)、SaltStack master启动后默认监听4505和4506两个端口。4505(publish_port)为saltstack的消息发布系统,4506(ret_port)为saltstack客户端与服务端通信的端口。如果使用lsof 查看4505端口,会发现所有的minion在4505端口持续保持在ESTABLISHED状态。

9.基本使用

查看当前的salt key信息

salt-key

当/etc/salt/master没有配置auto_accept:True时,
需要通过salt-key命令来进行证书认证操作,具体操作如下:

  1. salt-key–L,显示已经或未认证的被控端id,
  2. salt-key–D,删除所有认证主机id证书
  3. salt-key-d id,删除单个id证书;
  4. salt-key–A,接受所有id证书请求;
  5. salt-key-a id,接受单个id证书请求。

测试被控主机的连通性

salt '*' test.ping

远程命令执行测试
cmd.run 这个命令可以执行所有linux下的命令
例:

[root@node1 ~]# salt '*' cmd.run 'df -h'
node2.minion:
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       7.9G  3.5G  4.1G  46% /

注:这个不建议使用。因为功能过大。可以通过删除这个模块或者acl策略

**显示被控主机的操作系统类型++

salt '*' grains.item os

远程代码执行测试

salt '*' cmd.exec_code python 'import sys; print sys.version'
结果:
node2.minion:
    2.6.6 (r266:84292, Jul 23 2015, 15:22:56) 
    [GCC 4.4.7 20120313 (Red Hat 4.4.7-11)]

10.常用模块介绍
下一章

Salt States

salt 中的配置管理模块, 下面这段是官方介绍的 state 总诀,我就不翻译了,保持原汁原味~

Salt states are based on data modeling and build on a low level data structure that is used to execute each state function. Then more logical layers are built on top of each other.

The high layers of the state system which this tutorial will cover consists of everything that needs to be known to use states, the two high layers covered here are the sls layer and the highest layer highstate.

Understanding the layers of data management in the State System will help with understanding states, but they never need to be used. Just as understanding how a compiler functions assists when learning a programming language, understanding what is going on under the hood of a configuration management system will also prove to be a valuable asset.

第一个 sls

state 系统是建立在 SLS 规则上面,salt 的文件服务器上的 sls 文件中定义了这些要应用的规则。下面来创建一个简单的 SLS 文件,在 /srv/salt 文件夹下创建一个 vim.sls 文件,下面的语句确保当启用这个 state 配置时 vim 已经在目标 minion 安装好。

/srv/sat/vim.sls:

vim:
  pkg.installed

现在,应用这个 SLS 配置方案,在 minions 上安装 vim

salt '*' state.apply vim

这条命令将触发 state 系统去执行这个 vim 配置方案。为了让这个 vim 方案更完善,可以加一个 vimrc 配置文件:

/srv/salt/vim.sls:

vim:
  pkg.installed: []

/etc/vimrc:
  file.managed:
    - source: salt://vimrc
    - mode: 644
    - user: root
    - group: root

现在,master 端需要将 vimrc 复制到 /srv/salt/vimrc,在 salt 中,所有的都是文件,因此不需考虑路径重定向问题。这个 vimrc 文件和 vim.sls 都在 /srv/salt/vim.sls 文件夹下面,同样执行上面那条命令,所有的 minions 除了会安装 vim 外,还会将 vimrc 文件拷贝到 /etc/vimrc

Adding Some Depth

很明显,只在 sls 文件服务器的根目录下维护这些 SLS 配置方案,很难扩展到大规模的部署场景,这就是为什么需要目录层次结构。让我们来配置一个 nginx 部署方案,首先创建一个 nginx 子目录,并在里面新建 init.sls 文件。

/srv/salt/nginx/init.sls:

nginx:
  pkg.installed: []
  service.running:
    - require:
      - pkg: nginx

这里引入了几个 SLS 规则中的新概念。

首先,service.running 声明语句确保 nginx 服务是运行的。

当然,nginx 服务运行前当然要先安装 nginx 软件,因此,require 语句为二者建立了依赖关系,require 确保被依赖的组件成功安装。

提示:

require 属于 requisites 选项族,它是一个功能强大的 state 组件,更多信息参考 here

可以看到,在 sls 根目录下面可以有 nginx 子目录,同样,vim 的配置也可以再灵活点,将 vim.slsvimrc 移动动到 edit 子目录下面,

/srv/salt/edit/vim.sls:

vim:
  pkg.installed

/etc/vimrc:
  file.managed:
    - source: salt://edit/vimrc
    - mode: 644
    - user: root
    - group: root

澳门新濠3559,只有 vimrc 文件的 source 目录稍微改动了点,现在 vim 配置方案引用名变成 edit.vim 因为 vim.sls 在根目录的 edit 子目录下面。除了 vim 配置文件,edit 子目录还可以包含 emacsnano 等其他编辑器等配置信息。

Next Reading

到这里,对 saltstack 算是有个初步的认识和应用了,但这只是 saltstack 里面九牛一毛,下一步要研究的是:

  • Salt States
  • Pillar

澳门新濠3559 4

编辑:服务器运维 本文来源:开始链接,那如何基于自动化运维平台管理好这

关键词: