轻松使用SaltStack管理成千上万台服务器（入门教程）

目录树 引言：一个”非专职运维人员“的烦恼 Salt快速入门 1. 安装配置 2. 安装管理端(master) 3. 安装被管理端(minion) 4. 接受minion的托管请求 5. 测试 Salt的强大功能 1. 批量操做(targeting) 2. 节点分组（nodegroups） 3. 命令执行（execution） 4. 节点信息(grains) 5. 配置管理（state) 6. 小结 Salt state实例解析 1. 目录结构 2. apache/init.sls 3. ssh/init.sls 4. ssh/server.sls 5. ssh/custom-server.sls 引言：一个”非专职运维人员“的烦恼加入到某证券公司的IT部门，尽管所在的部门挂了一个“研发部”的名字，可是我发现有大概40%的时间是在作运维工做。 这来自两种状况： 1. 自主开发的应用，须要持续的改进，不断的更新、发布、部署、调整配置，这不是运维部门喜欢的状态。 2. 软件商提供的“产品”没法知足运维部门的要求：没法经过简单的 Q&A 文档保证系统的正常运行，常常须要有必定技术能力的人员解决系统运行过程当中各类稀奇古怪的问题。 这种状况下只能本身作一个“非专职运维人员”，须要频繁的登陆各类服务器，执行一些命令来查看状态或者更改配置（包括配置文件的变动和软件包的安装部署）。不少操做都是不断的重复，日复一日，让人厌烦。 ”重复的工做应该交给程序去作“，因此我本身写过一些脚本。为了不将脚本上传到几十台服务器而且不时进行更改，我使用Fabric来进行服务器的批量操做。 尽管避免了”批量的人工操做“，但我仍是在进行”人工的批量操做“。远远没有实现自动管理。将有限的生命解放出来，投入到更有意义的编码工做是一个奔四程序员应有的追求，因此我又睁大红肿的眼睛，迷茫的搜索这个世界。 我发现了Puppet，Chef和CFEngine，可是并不满意。直到我发现了Salt,个人眼前一亮：这正是我所须要的东西。 若是说Salt有什么独特之处打动了我，那就是： 简单：多是源于python的简约精神，Salt的安装配置和使用简单到了使人发指的地步。任何稍有经验的linux使用者能够在10分钟以内搭建一个测试环境并跑通一个例子（相比之下，puppet可能须要30--60分钟）。 高性能：Salt使用大名鼎鼎的ZeroMQ做为通信协议，性能极高。能够在数秒钟以内完成数据的传递 可伸缩：基于ZeroMQ通讯，具有很强的扩展性；能够进行分级管理，可以管理分布在广域网的上万台服务器。 尽管twitter、豆瓣、oracle、等著名网站的运维团队都在使用puppet，可是我相信，他们切换到salt只是一个时间问题。毕竟不是全部的人都喜欢操纵傀儡(puppet)，可是谁又能离开盐(salt)呢？ 关于Salt和Puppet的对比，能够参考这里，或者看看中文版。 Salt快速入门Salt的体系结构中将节点区分为: master, minion, syndic。 1. master: 老大，管理端 2. minion: 马仔，被管理端 3. syndic: 头目，对于老大来讲是马仔，对于马仔来讲是老大 在入门阶段，先不考虑syndic。 1. 安装配置若是将操做系统区分为： *NIX Linux Solaris HP Unix FreeBSD OS X windows 理论上来讲，Salt能够安装在任何*NIX系统上，包括master和minion。除了源代码以外， 还能够经过Salt提供的安装脚本，或者PyPI进行安装。 对于Linux，尤为是企业环境中经常使用的RHEL,CentOS,Ubuntu，能够经过包管理器很是容易的安装master 和/或 minion。 好比: yum(须要先配置EPEL), apt(须要增长http://debian.madduck.net/repo/库)，yaourt，ports。 Mac OS X 先使用HomeBrew解决依赖包：brew install swig zmq，而后用PyPI安装：pip install salt。 对于windows，只能安装minion（windows只适合作马仔）。从官方网站下载合适的安装包。安装过程当中能够指定master地址和本机名称。 安装后须要本身启动Salt服务。配置文件在C:\salt\conf\minion。 具体的各操做系统下的安装能够参考官方文档。这里为了简单，只考虑经常使用的RHEL/CentOS 和 windows。 在下面的例子中，使用一台RHEL/CentOS做为master， 另一台RHEL/CentOS和一台windows 2003 Server做为 minion。 2. 安装管理端(master)# 安装EPEL,注意选择合适的版本 rpm -ivh http://mirrors.sohu.com/fedora-e ... ease-6-8.noarch.rpm yum update  # 安装master yum install salt-master        # 修改配置 vim /etc/salt/master  # 最基本的设定服务端监听的IP(好比使用VIP作master的高可用时)： # interface: 服务端监听IP # 其余配置参考[官方文档](http://docs.saltstack.com/ref/configuration/master.html)  # 启动服务(如下命令等效) salt-master -d /etc/init.d/salt-master start service salt-master start3. 安装被管理端(minion)# 安装EPEL,注意选择合适的版本 rpm -ivh http://mirrors.sohu.com/fedora-e ... ease-6-8.noarch.rpm yum update  # 安装minion yum install salt-minion     # 修改配置 vim /etc/salt/minion  # 最基本的设定是指定master地址，以及本机标识符： # master: master的主机名或IP地址 # id: 本机标识符 # 其余配置参考[官方文档](http://docs.saltstack.com/ref/configuration/minion.html)   # 启动服务(如下命令等效) salt-minion -d /etc/init.d/salt-minion start service salt-minion start4. 接受minion的托管请求minion向master投诚后，还须要master接受才行。这个过程叫作“授信”。 Salt底层使用公钥-私钥证书来保证通讯信道的安全。具体的机制能够参考ZeroMQ的相关内容。Salt已经屏蔽了底层的细节，只须要使用封装好的命令： # 在master上运行 # 查看全部minion salt-key -L  Accepted Keys: windows bond_app_server_main mac_os_vm salt-master Unaccepted Keys: minion1 minion2 Rejected Keys:  #其中Unaccepted Keys是未许可的minion。可使用下面的命令经过认证： salt-key -a minion15. 测试安装配置好以后，首先要测试一下联通性：salt '*' test.ping。salt会列出每一个认证过的minion的联通状态(true 或 false)。 再举一些例子： # 查询主机运行了多长时间 sudo salt '*' cmd.run "uptime"   # 批量重启服务 salt '*' cmd.run "service httpd restart"  # 让多台机器一块儿，使用Apache Bench进行压力测试 salt '*' cmd.run "ab -n 10 -c 2 http://www.google.com/"注意，默认状况下master和minion之间使用如下端口进行通讯： 1. 4505(publish_port): salt的消息发布系统 2. 4506(ret_port):salt客户端与服务端通讯的端口 网络的设置须要保证这些端口能够访问。 Salt的强大功能上面的例子都是用Salt进行批量操做。可是Salt的功能不只如此。 认真分析一下个人“非专职运维工做”的内容，发现能够分为如下三个方面： 1. 变动操做：根据须要对节点中某个资源的某种状态进行调整，并检验变动的结果 2. 配置管理：让上述行为变得“可管理”，支持“有关人士”对上述行为的标记、控制、识别、报告、跟踪和归档甚至审批和审计 3. 状态监控：随时掌握状态，发现异常。尽可能在系统用户发现问题以前解决麻烦 Salt对上述三个方面提供了完美的支持，事实上，Salt提供的功能比我须要的还要多。下图是Salt的主要功能：     若是想对Salt的功能和使用有一个初步的了解，最好参考官方文档：Salt Stack Walkthrough。 1. 批量操做(targeting)再回顾一下上文中的例子: # 测试连通性 salt '*' test.ping  # 查询主机运行了多长时间 sudo salt '*' cmd.run "uptime"   # 批量重启服务 salt '*' cmd.run "service httpd restart"  # 让多台机器一块儿，使用Apache Bench进行压力测试 salt '*' cmd.run "ab -n 10 -c 2 http://www.google.com/"上面的例子都是对多个节点进行批量操做：使用通配符"'*'"对全部注册的节点进行操做。Salt支持多种方式对节点id(minion id)进行匹配。包括： 默认：通配符(globbing)) * E：正则表达式(Regular Expression) * L：列表 * N: 分组(group) * C：复合匹配 先看一下通配符、正则表达式和列表的例子： # 通配符是最经常使用的匹配方式。Salt使用[linux风格的通配符](http://docs.python.org/2/library/fnmatch.html) salt '*' test.ping salt '*.example.net' test.ping salt '*.example.*' test.ping salt 'web?.example.net' test.ping salt 'web[1-5]' test.ping salt 'web-[x-z]' test.ping  # 正则表达式能够适应更复杂的状况。使用[python的re模块](http://docs.python.org/2/library/re.html#module-re)进行匹配 salt -E 'web1-(prod|devel)' test.ping  # 最直接的方式是本身指定多个minion，即列表 salt -L 'web1,web2,web3' test.ping复合匹配(Compound matchers)有点复杂，后续会在其余文章中专门介绍。 2. 节点分组（nodegroups）好吧，批量操做确实很爽。可是每次都输入匹配规则有点麻烦，对于复杂的匹配规则更是如此。 salt的 nodegroups功能能够将经常使用的匹配规则保存下来（称之为minion的分组）。批量操做是，只须要使用L标记指定要操做的group名字便可。 groups定义在master的配置文件/etc/salt/master中。 group 的定义可使用各类匹配规则，好比： group1: 'L@foo.domain.com, bar.domain.com,baz.domain.com or bl*.domain.com'group2: 'G@os:Debian and foo.domain.com'3. 命令执行（execution）Salt生来就有命令编排的功能。听说，Salt最早实现的是远程执行技术，而后才添加的配置管理功能。Salt使用ZeroMQ来处理命令执行的请求和响应消息，安装配置简单，而且性能很是高。 Salt便可以批量执行命令，也能够单机执行。一般单机执行用于测试： 1. 单机（当即）执行。 使用salt-call命令单机执行操做 2. 批量(当即)执行。最经常使用的操做。使用salt命令，对匹配的minion节点执行操做 Salt能够执行的命令也能够分为两种： 1. 系统命令，使用cmd.run执行 2. Salt模块，将经常使用的命令/批处理封装到内置的Salt模块(module)，使用模块名.功能名的方式执行。 好比： # 执行系统命令 salt '*' cmd.run 'hostname'  # 执行Salt模块 salt '*' disk.usage使用Salt模块的好处是可以作到一致。好比一样是查看磁盘使用状况，salt '*' cmd.run "df -h"只能用于NIX节点，而salt '*' disk.usage对NIX和Windows都适用，而且采用相同结构返回数据，便于批量处理。 Salt已经内置了大量的模块，这些模块涵盖了平常管理任务的主要任务，包括： 1. 通用的管理任务，好比apt, at, cp, cron, disk, extfs, file, grains, hosts, iptables, mount, network, pam, parted, pkg, ps, selinux, shadow, ssh, test等 2. 针对特定软件的任务，好比apache, cassandra, djangomod, git, mongodb, mysql, nginx, nova, postgres, solr, sqlite3, 和tomcat 并且，本身开发Salt模块也很是简单，很容易将实际管理操做中的一些经验经过自定义的模块固化下来，并方便分享。 在开发和调试模块的时候，可使用test=True参数进行模拟执行(Dry run)。好比： salt 'minion1.example.com' state.highstate -v test=True4. 节点信息(grains)grains是Salt内置的一个很是有用的模块。在用salt进行管理客户端的时候或者写state的时候均可以引用grains的变量。 grains的基本使用举例以下： # 查看grains分类 salt '*' grains.ls    # 查看grains全部信息 salt '*' grains.items  # 查看grains某个信息 salt '*' grains.item osrelease5. 配置管理（state)配置管理是Salt中很是重要的内容之一。Salt经过内置的state模块支持配置管理所需的功能。关于这部份内容，官方文档有很详细的描述，能够参考 part 1，part 2和 part 3。 Salt中能够定义节点的目标状态，称之为state。state对应配置管理中的配置，能够对其进行标识、变动控制、变动识别、状态报告、跟踪和归档以及审计等一些的管理行为。 状态描述 Salt使用SLS文件（SaLt State file）描述状态。SLS使用YAML格式进行数据序列化，所以简单明了，可读性也很高。 基本描述(yaml) 下边是一个简单的SLS文件例子: apache:   pkg:     - installed   service:     - running     - require:       - pkg: apache 该文件描述一个ID为apache的配置状态： 1. 软件包（pkg)已经安装 2. 服务应该处于运行中 3. 服务的运行依赖于apache软件包的安装 state文件中的全部YAML变量名来自Salt的state模块。 Salt内置了大量的state模块，好比cron, cmd, file, group, host, mount, pkg, service, ssh_auth，user等。 详细清单参考这里。 还能够开发本身的state模块。 扩展描述(jinja) state可使用jinja模板引擎进行扩展，其语法能够参考这里。 下面是一个更复杂的例子： vim:  pkg:        { % if grains['os_family'] == 'RedHat' % }     - name: vim-enhanced        { % elif grains['os'] == 'Debian' % }    - name: vim-nox        { % elif grains['os'] == 'Ubuntu' % }    - name: vim-nox        { % endif % }    - installed     该state增长了判断逻辑：若是是redhard系列的就安装 vim-enhanced，若是系统是Debian或者Ubuntu就安装vim-nox。 逻辑关系 state之间能够有逻辑关系。常见的关系举例以下： 1. require：依赖某个state，在运行此state前，先运行依赖的state，依赖能够有多个 httpd:   pkg:     - installed   file.managed:     - name: /etc/httpd/conf/httpd.conf     - source: salt://httpd/httpd.conf     - require:       - pkg: httpd watch：在某个state变化时运行此模块 redis:  pkg:    - latest  file.managed:    - source: salt://redis/redis.conf    - name: /etc/redis.conf    - require:      - pkg: redis    service.running:      - enable: True      - watch:      - file: /etc/redis.conf      - pkg: redis watch除具有require功能外，还增了关注状态的功能 3. order：优先级比require和watch低，有order指定的state比没有order指定的优先级高 vim:  pkg.installed:    - order: 1 想让某个state最后一个运行，能够用last 保存状态 状态描述文件(SLS)要保存在master节点中，并经过指令分发到minion节点。 1. 路径设置 Salt master的配置文件(/etc/salt/master)中能够经过file_roots参数指定状态文件的保存路径。能够为不一样的环境（如开发环境、UAT环境、生产环境、灾备环境等）分别指定路径，以下所示： file_roots:  base:    - /srv/salt/  dev:    - /srv/salt/dev/services    - /srv/salt/dev/states  prod:    - /srv/salt/prod/services    - /srv/salt/prod/states 其中,base环境是必须的。 2. 入口文件 file_roots中必须指定“base”环境的路径，由于该路径中存在Salt state的入口文件: top.sls。 Top文件创建配置环境、节点和状态配置之间的映射关系。好比一个简单的top.sls文件： base:  '*':    - serversdev:  '*nodb*':    - mongodb 该文件指定了： - 全部节点使用base环境的servers配置 - nodb节点使用dev环境的mongodb配置 结合第一部分的file_roots配置，该top配置意味存在如下的配置文件： /srv/salt/servers.sls/srv/salt/dev/mongodb.sls 注：这里也可使用文件夹/srv/salt/servers/和/srv/salt/dev/mongodb/，在文件夹中放置一组状态文件和配置文件，便于创建复杂的状态配置。 top.sls中的可配置内容很是丰富，具体内容能够参考官方文档。 状态生效（State Enforcement） master上对状态进行定义，最终这些状态要传递到minion节点上。在本节的例子中，若是定义好了状态文件/srv/salt/dev/mongodb.sls： mongodb:  pkg:    - installed 可使用命令salt "minion1" state.highstate -v使得全部针对"minion1"的state生效； 在执行状态以前先进行测试是个好主意，须要指定参数test=True。好比，salt "minion1" state.highstate -v test=True。 关于state模块的更多用法，能够参考state模块说明，或官方文档。 更多 Salt的state模块的功能不只如此，还可使用模板和变量，以及定义状态的定时自动生效。 6. 小结本文介绍Salt的主要功能和基本使用，包括minion节点的管理，批量操做，以及很是重要的配置管理。 掌握了这些内容，可使用Salt极大提升运维的效率（事实上，Salt对于开发阶段也能提供很大的帮助，开发和运维的界限正在逐渐模糊）。 后续会介绍一些使用案例以及Salt的高级功能。 Salt state实例解析在Salt的官方教程中，以apache和sshd的state配置做为例子。掌握这两个例子，就可以举一反三，处理平常工做中大部分的配置管理问题。 本文对这两个例子进行详细的分析和注释。 1. 目录结构文档 中的例子包含了多个文件。这些文件之间互相引用和关联。目录结构及文件清单以下：   apache/init.sls apache/httpd.conf   ssh/init.sls   ssh/server.sls ssh/banner ssh/ssh_config ssh/sshd_config ssh/custom-server.sls   两个配置分别放在了apache和ssh文件夹。一个Salt状态可使用单个的SLS文件，或者使用一个文件夹。后者更加灵活方便。 2. apache/init.sls apache:    pkg:      - installed    service:      - running      - watch:        - pkg: apache        - file: /etc/httpd/conf/httpd.conf        - user: apache    user.present:      - uid: 87      - gid: 87      - home: /var/www/html      - shell: /bin/nologin      - require:        - group: apache    group.present:      - gid: 87      - require:        - pkg: apache   /etc/httpd/conf/httpd.conf:    file.managed:      - source: salt://apache/httpd.conf      - user: root      - group: root      - mode: 644      - template: jinja      - context:        custom_var: "override"      - defaults:        custom_var: "default value"        other_var: 123说明： 1. sls文件使用YAML格式定义，最外面的层级定义配置项。 2. 一个sls文件中能够有多个配置项，配置项的ID能够起任意的名字。本例中包含ID为apache和/etc/httpd/conf/httpd.conf两个配置项。 3. 配置项内是一系列的状态声明。全部的状态项来自Salt状态模块。便可以使用Salt内置的状态模块，也能够编写自定义的状态模块 4. 状态声明内部指定状态函数的调用。状态函数是每一个Salt状态模块中定义的函数。 5. apache配置项 1) pkg模块，使用操做系统的包管理器(如yum, apt-get)安装软件包 salt.states.pkg.installed函数, 验证软件包是否安装以及是否为指定的版本 2) service模块管理服务/守护进程(daemon)的启动或中止     salt.states.service.running函数检查服务是否已经启动     service模块定义了salt.states.service.mod_watch函数，可使用watch要素监控其余的模块是否知足。这里监控如下状况：         apache软件包(pkg)是否已安装         /etc/httpd/conf/httpd.conf文件(file)是否存在         apache用户(user)是否存在     user.present是简写形式，直接调用user模块的present函数检查是否存在以下属性的apache用户：         uid=87         gid=87         home目录为/var/www/html         登陆脚本为/bin/nologin         检查依赖项：apache用户组     group.present是简写形式，直接调用group模块的present函数检查是否存在以下属性的apache用户组：         gid=87         检查依赖项：apache软件包 6. /etc/httpd/conf/httpd.conf配置项 file.managed是简写形式，直接调用file模块的managed方法根据须要从master获取文件并可能会经过模板系统(templating system)进行渲染。文件要知足以下要求：   使用master上面的apache/httpd.conf文件 user=root group=root mode=644 使用jinja模板渲染 上下文变量： custom_var="override" 默认值: custom_var="default value" other_var=123   3. ssh/init.slsopenssh-client:    pkg.installed   /etc/ssh/ssh_config:    file.managed:      - user: root      - group: root      - mode: 644      - source: salt://ssh/ssh_config      - require:        - pkg: openssh-client4. ssh/server.sls include:    - ssh  openssh-server:   pkg.installed  sshd:   service.running:     - require:       - pkg: openssh-client       - pkg: openssh-server       - file: /etc/ssh/banner       - file: /etc/ssh/sshd_config  /etc/ssh/sshd_config:   file.managed:     - user: root     - group: root     - mode: 644     - source: salt://ssh/sshd_config     - require:       - pkg: openssh-server  /etc/ssh/banner:   file:     - managed     - user: root     - group: root     - mode: 644     - source: salt://ssh/banner     - require:       - pkg: openssh-server说明： 1. include语句将别的state添加到当前文件中，使得state能够跨文件引用。 使用include至关于把被引用的内容文件添加到自身，能够require、watch或extend被引用的SLS中定义的内容。 这里引用了sshstate。 2. openssh-server配置项 3. sshd 4. /etc/ssh/sshd_config配置项 5. /etc/ssh/banner配置项 5. ssh/custom-server.slsinclude:   - ssh.server  extend:   /etc/ssh/banner:     file:       - source: salt://ssh/custom-banner说明： 1. 引用sshstate的server配置项 2. extend能够复用已有的state，在原来的基础上进行扩展，增长新的配置或修改已有的配置。     将/etc/ssh/banner配置项的文件修改成salt://ssh/custom-banner