版权所有(C) mcsrainbow，保留所有原创日志的权利。转载请注明出处： 。这篇文章发表于
02:27，属于
分类。 你可以通过
来跟踪这篇文章。
你还可以对它进行 。
标签云(Tags)
WP Cumulus Flash tag cloud by
新浪微博(Sina Weibo)
友情链接(Blogroll)
文章归档(Archives)
功能(Meta)
网站安全监测(Webscan)
Google +1 (Plusone Button)
广告(Google Adsense)
Fusion theme by
| powered by系统自动化配置和管理工具：SaltStack
查看: 1338|
评论: 0|来自: 51CTO
摘要: 我们的服务器由 Puppet 配置管理工具来管理，服务器上线后由 puppet 完成初始化和配置等一系列工作（比如，静态 IP 配置，DNS 设置，NFS/SAN 挂载，LDAP/Kerberos 登录，安全加固配置，内核参数优化，防火墙规则配置 ...
我们的服务器由 Puppet 配置管理工具来管理，服务器上线后由 puppet 完成初始化和配置等一系列工作（比如，静态 IP 配置，DNS 设置，NFS/SAN 挂载，LDAP/Kerberos 登录，安全加固配置，内核参数优化，防火墙规则配置等等），等初始化完成后开始运行，运行一段时间后会有一些需要自动和手动操作的任务（比如升级、重启、 备份等），这时候我们使用 Fabric 来批量执行这些临时任务。所以从这里可以看到 Puppet 和 Fabric 其实是两个不同性质的工具，看下面的归类可能会更清楚一些。Puppet 和 Fabric 两个的工作其实可以由一个工具 SaltStack（或 AnsibleWorks）完成，减少一个工具的使用会减轻一点负担（学习工具的人力成本、安装和配置工具的时间成本等等）。&操作系统和软件的安装、配置、初始化等；（Puppet, Chef, CFEngine, AnsibleWorks, SaltStack）自动执行任务，比如定期备份、清除日志等；（Fabric, AnsibleWorks, SaltStack）手动执行任务，比如部署应用、升级、重启、检查和校验文件系统、增加用户等。（Fabric, Rake, AnsibleWorks, SaltStack）SaltStack 采用 zeromq 消息队列进行通信，和 Puppet/Chef 比起来，SaltStack 速度快得多。还有一点我们喜欢 SaltStack 的地方是它是 Python 写的，比 Puppet/Chef 这些 Ruby 工具更接近我们的能力圈。安装主控服务器（salt master）和大多数类似工具一样，SaltStack 需要在一台机器（主控）上安装服务器端软件（SaltStack 称之为 salt master），在多台机器（受控）上安装客户端软件（SaltStack 称之为 salt minion）。在主控机器上给下属（受控）发命令，在受控机器上接受和执行上级（主控）的命令。在 Ubuntu 上安装 salt master：$&sudo&add-apt-repository&ppa:saltstack/salt&$&sudo&apt-get&update&$&sudo&apt-get&install&salt-master&在 CentOS 6.x 上安装 salt master：#&rpm&-Uvh&http://ftp.linux.ncsu.edu/pub/epel/6/i386/epel-release-6-8.noarch.rpm&#&yum&update&#&yum&install&salt-master&安装受控客户端（salt minion）在 Ubuntu 上安装 salt minion：$&sudo&add-apt-repository&ppa:saltstack/salt&$&sudo&apt-get&update&$&sudo&apt-get&install&salt-minion&在 CentOS 6.x 上安装 salt minion：#&rpm&-Uvh&http://ftp.linux.ncsu.edu/pub/epel/6/i386/epel-release-6-8.noarch.rpm&#&yum&update&#&yum&install&salt-minion&安装完 salt minion 后记得修改配置文件，让 salt minion 指向 salt master 服务器地址：$&sudo&vi&/etc/salt/minion&...&#&Set&the&location&of&the&salt&master&server,&if&the&master&server&cannot&be&#&resolved,&then&the&minion&will&fail&to&start.&master:&&...&$&sudo&restart&salt-minion&在 master 上执行 salt-key list 就会看到有个
请求加入受控，执行 -a 接受请求后，主控和受控之间的信任关系就建立起来了，主控就可以任意 “摆布” 受控了：#&salt-key&list&Accepted&Keys:&Unaccepted&Keys:&&Rejected&Keys:&#&salt-key&-a&&The&following&keys&are&going&to&be&accepted:&Unaccepted&Keys:&&Proceed?&[n/Y]&执行命令的例子在主控机器上执行一个命令，让所有受控机器执行 hostname 命令：#&salt&'*'&cmd.run&"hostname"&:&&在主控机器上执行一个命令，让所有受控机器上执行内建 test.ping 命令：#&salt&'*'&test.ping&:&True&还有一些内建命令可以尝试：#&salt&'*'&disk.usage&#&salt&'*'&network.interfaces&执行状态的例子开头的时候我们说了 SaltStack = Fabric + Puppet，上面 “执行命令的例子” 演示了 Fabric 类似的功能，这里要演示的是 Puppet 类似的功能，在主控上定义好系统配置应该有的状态，然后受控自动完成相应的操作和配置。首先确定状态定义的文件应该放在什么地方，以下操作都在主控（salt master）上执行。检查 /etc/salt/master 文件的 file_roots 条目，默认是在 /srv/salt 下，如果没有这个目录还需要手动创建一个：#&vi&/etc/salt/master&...&#file_roots:&#&&base:&#&&&&-&/srv/salt&...&#&mkdir&/srv/salt&比如我们想在所有受控机器上安装 vim 软件包，并使用自己定义的 vimrc 文件：#&vi&/srv/salt/vim.sls&vim:&pkg.installed&/etc/vimrc:&file.managed:&-&source:&salt://vimrc&-&mode:&644&-&user:&root&-&group:&root&#&vi&/srv/salt/vimrc&syntax&enable&set&textwidth=79&set&shiftwidth=4&set&tabstop=4&set&expandtab&set&softtabstop=4&set&shiftround&set&fileencodings=utf-8&set&encoding=utf8&set&tenc=utf8&强制执行这个状态：#&salt&'*'&state.sls&vim&再来一个例子，参考 “安装和使用系统监控工具 Glances” 一文，我们想在所有受控机器上安装 Glances，如何实现呢？#&vi&/srv/salt/glances.sls&python-pip:&pkg.installed&build-essential:&pkg.installed&python-dev:&pkg.installed&glances:&pip.installed:&-&require:&-&pkg:&python-pip&强制执行这个状态：#&salt&'*'&state.sls&glances&...&:&----------&State:&-&pip&Name:&&&&&&glances&Function:&&installed&Result:&&&&True&Comment:&&&Package&was&successfully&installed&Changes:&&&Glances==1.7.1:&Installed&...&
快毕业了，没工作经验，
找份工作好难啊？
赶紧去人才芯片公司磨练吧!!自动化运维工具SaltStack详细部署
原文：http://sofar./6960
========================================================================================== 1、简介 SaltStack是一个服务器基础架构集中化管理平台，具备配置管理、远程执行、监控等功能，一般可以理解为简化版的puppet和加强版的func。SaltStack基于Python语言实现，结合轻量级消息队列（ZeroMQ）与Python第三方模块（Pyzmq、PyCrypto、Pyjinjia2、python-msgpack和PyYAML等）构建。
========================================================================================== 1、依赖组件说明
python-2.7.8进行编译安装即可解决以上问题。
========================================================================================== 一些学习资料：
您可能也会对以下文章感兴趣
QQ : 341470
Friend Link
New Member12345678910
&Salt ID&:&& # target的id，类似于minion配置文件中"id"字段选项&&&&host:&&&&# 远程主机的IP地址或者域名&&&&user:&&&&# 登陆远程主机的用户名&&&&passwd:&&# 对于用户名的面膜&&&&&# 可选参数&&&&port:&&&&# 远程主机的ssh端口&&&&sudo:&&&&# 通过sudo命令运行命令&&&&priv:&&&&# ssh的私钥文件的路径, 默认是salt-ssh.rsa&&&&timeout: # ssh等待响应的超时时间
简单的创建roster文件，默认文件/etc/salt/roster
web1: 192.168.42.1
上面是一个十分基本的roster文件，包含salt id对应的ip地址。一个包含更多信息的roster文件如下：
web1:&&host: 192.168.42.1 # IP或者域名&&user: fred&&&&&&&& # 远程命令执行的用户身份&&passwd: foobarbaz&&# ssh登陆密码，如果省略将会使用秘钥登陆&&sudo: True&&&&&&&& # 是否sudo到root，默认不开启web2:&&host: 192.168.42.2
CALLING SALT SSH
salt-ssh命令可以很容易执行相同的salt命令
salt-ssh '*' test.ping
salt-ssh和salt遵循相同的命令语法，并且可以使用标准的函数，输出内容和salt一样，并且许多相同的flags是可用的，具体可以查看/ref/cli/salt-ssh.html 可用的选项。
Raw Shell Calls
默认salt-ssh在远程系统上运行salt远程支持模块。但是salt-ssh也可以运行原始的shell命令：
salt-ssh '*' -r 'ifconfig'
STATES VIA SALT SSH
salt-ssh也可以运行salt state。当使用salt-ssh时，state系统抽象出和salt相同的接口。定义标准的salt公式的目的是将salt-ssh和salt进行无缝的工作，反之亦然。
标准的salt states walkthroughs函数只需简单的用salt-ssh命令代替salt命令
TARGETING WITH SALT SSH
事实上salt-ssh于salt的目标匹配方法不同，在写的时候只支持glob和regex，其他的匹配模式也将逐步实现
RUNNING SALT SSH AS NON-ROOT USER
默认情况下，salt读取/etc/salt下的所有配置文件，如果使用普通用户运行salt ssh或者需要改变一些目录的权限，那么将会返回一个“没有权限”的消息。你必须修改两个参数：pki_dir，cachedir。这些都应该是这个普通用户具有写权限的完整路径。
作者： CooCla
(C) Fly-Dream 2013版权所有 ALL Rights酷勤网 C 程序员的那点事！
当前位置： >
浏览次数：次
配置管理作为基础使现代基础设施成为可能。在任何运维团队的工具箱中，都需要那些实现配置管理的工具，甚至对于很多开发团队也是如此。尽管所有的工具旨在解决同样的基本问题集，但它们遵循了不同的看法，并表现出不同的特点。问题在于如何选出适合各个组织具体情况的最佳工具。
本文作为的一部分，旨在介绍当前市场上存在的部分配置工具，以及各个工具背后的原理，和使它们彼此脱颖而出的原因。您可以在订阅此系列新文章的提醒。
协会当前状态
几个月前，在蒙特利尔Python和DevOps用户组的联合会议上，我做了以下报告：。不论是自己开发，还是从开源中获取，亦或是商业购买来的，大多数系统管理员、开发人员和IT运维专家都用到一些工具用于自动化基础设施和配置所有方面以确保各技术完成我们所期待的工作。在该报告中，我试图为那些最流行的选项提供客观的看法。但这也取决于你的咨询对象及其思维方式，还有他们的管理对象，几乎每个人都有自己的偏好。
在以往的计算日子里，一般公司只需维护少量服务器，IT人员通过频繁地手动调整及重新调整这些服务器就可以保证其LOLcats网站正常平稳地运行。
但自此之后很多情况都发生了变化，尤其最近这几年变化特别大。现在大型数据中心和向外拓展的服务器集群占据了主导地位，手动管理各个服务器已不再可能。各种配置管理工具不断涌现，尽管如此，即使是在过去十年里设计的一些工具也不能适应目前这种规模等级的发展。
SaltStack因此应运而生。尽管也有一些爱好将SaltStack master运用在Raspberry Pi，或利用它管理几台在自己地下室的服务器所组成的家庭网络，但SaltStack的真正目标是速度和规模。这就是为什么LinkIn、WikiMedia和都利用它来管理由数以万计服务器构成的大型基础架构。市场需要的并非是另外一个配置管理工具，它需要的是能适合现代Web大规模基础设施的配置管理工具。这篇文章中，我将重点放在使用SaltStack来进行配置管理上。
首先是一个快速远程执行平台
最初SaltStack被设计为一个特别快速、具有可拓展性和强大的远程执行引擎，目的是为了有效控制分布式基础架构、代码和数据。随后，在远程执行引擎上层构建了配置管理，并使用了相同的内核功能。
&SaltStack能做到这点&是Salt社区最常见的评论。对于Salt用户来说，SaltStack就是数据中心的瑞士军刀。持续却轻量级的SaltStack master/minion拓扑为所有环境带来了广泛的控制和功能性，而所有这些都是来自单一平台，不带有第三方依赖。
Salt master是管理Salt minions的守护进程。同样Salt minions也是守护进程，运行于受控系统上，用于接收来自Salt master的命令。按SaltStack的设计，每个master能处理一万个minion进程，但这也只是保守估计。这一规模可以通过异步、并行指令、对实时管理的控制以及与任何数据中心系统的沟通来实现。
对于不需要实时控制或极端速度及规模的轻量级用例，SaltStack同样也提供了Salt SSH&无代理&模式的系统管理。
此外，远程执行和配置管理结合在一起会更好。因为彼此都需要对方在某一时刻开始为其提供真正的基础设施自动化和控制。SaltStack平台为类似持续代码部署或自动拓展资源等事件驱动行为提供了系统。
想要基本理解则需要先理解SaltStack reactor系统。事件系统是本地PUB接口，用于触发SaltStack事件。该事件总线是个开放系统，用于给SaltStack和其它系统发送针对各个操作的提示信息。该事件系统所触发的事件带有十分特定的标准。所有事件都带有标签。该事件标签允许对事件进行快速的顶层过滤。除了标签，所有事件还拥有数据结构。该数据结构是一个包含该事件信息的目录。
SaltStack reactor系统处理SaltStack事件，并基于逻辑引擎执行命令，从而允许事件触发行为。SaltStack能处理和响应来自本身和其它类似Jenkins等系统的事件。
近期Hearbleed漏洞就是个很好的例子，它展示了我们的客户如何通过使用SaltStack控制基础架构的所有点点滴滴。SaltStack以毫秒速度跨越整个大型基础架构，被用于。比如：来自WebPlatform.org和WikiMedia的这些推文强调了SaltStack在作出这些修正时的简单性：
以下SaltStack命令使得评估和修复Heartbleed漏洞成为可能：
基础设施即数据，而非代码
通过实施&基础设施即数据&方法，SaltStack的配置管理学习和采用曲线已降低。在不牺牲任何功能和性能的情况下，该方法相对传统&基础设施即代码&方法大大降低了复杂度。&基础架构即代码&通常要求用户能够理解复杂的机器代码语言或领域特定语言。而SaltStack方法可人工阅读，当然也能轻松地被机器解读。
尽管SaltStack是用Python语言编写，但其配置管理是语言无关的，且使用了简单、人类可读的YAML文件和Jinja模板。
DevOps和可扩展的WebIT要求速度、敏捷性和通信。学习曲线越短，其竞争优势就越大。尽管在&基础设施即代码&上投资显著，但其实并不需要，因为它阻碍了创新和部署，本来部署就应以快速为原则尽可能快地将服务器及其上面运行的软件调整到稳定、可重用和生产就绪的状态。何必坐着航天飞机到街角市场，明明走路或骑自行车更容易？
极具灵活性
SaltStack由多个不同模块层组成的，全部都利用了相同的快速通信总线，这允许了其与尽可能多的服务器进行并行通信以通知服务器应该做什么。这些命令、例行程序和功能所组成的层为整个计算基础架构和所有数据中心内容提供了广泛的控制。我们的很多用户都通过SaltStack通知Puppet manifest应该做什么，因为SaltStack可以用于管理软件、云或虚拟化的其它任意部分。
在过去几年里对于选择声明式还是命令式方式来配置管理，一直存有纷争。而我们，则&往该纷争中插了个叉子&。SaltStack不仅可使用声明式配置管理，也可以用于命令式。至于怎么用，就取决于你怎么想，以及你的系统如何被管理。
SaltStack配置管理可以以命令式方式执行，所有事务将按给定顺序执行。也可以以声明式方式执行，系统决定如何执行对象间匹配有关联的各事务。
命令式排序是有限的，普遍被认为比较容易编写。声明式排序则强大很多，也更灵活，但往往比较难写。
SaltStack的创建就是为了最好地使用这两种配置方式。状态以有限顺序评估，保证了所有状态总是按同样的顺序执行，而状态运行时确是声明式的，使得Salt能完全意识到关联。Salt总是以有限方式执行状态，这意味着不论运行系统怎样，它们都将以相同的顺序执行。尽管如此，SaltStack近期添加了这一选项，使得状态能按其在Salt状态文件中所定义的顺序被评估。
评估顺序允许我们简单地获知状态将以什么顺序执行，但值得注意的是，在必要时系统会覆盖文件中定义的排序。下面将要描述的排序选项也可以覆盖Salt状态文件中所定义的状态顺序。
当SaltStack提供（比如：&on fail&或&on change&）到声明式路径中时，其架构所蕴含的能量允许往配置管理运行过程中插入例行程序，这样即使第一次失败了，也可能在换种方式尝试后成功。SaltStack的先决条件就是其中一个例子。先决条件只有当系统中将来有其他事情发生时才会对系统产生该事件。它是个幂等方式内嵌预测分析。它会问这个问题：&我是否即将要部署代码了？确定？那就把服务器从负载平衡器上卸下来，或者将Apache关闭吧。但所有这些操作只有当我对系统有所修改时发生。&或者SaltStack&fail hard&标识会进一步为命令式配置管理提供能量：相对于放弃例行程序，它会通知流程关于事情部署的情况。
使用SaltStack在Red Hat上安装LAMP Stack
一个简单的SaltStack配置管理场景是安装LAMP stack。尽管在GitHub上有关于更完整采用SaltStack方案的组织实例（），但本例应能充分地展示了基本的方案，它是某一指定资源配置管理的预编写Salt状态。SaltStack方案和状态可以用于类似、：安装软件包、配置和启动一个服务、设置用户或权限以及其他常见任务。
由于该例子是为基于Linux的Red Hat环境设计的，其中包含了Python 2.6为现有基础安装的一部分，其Linux和Python部分已经完成了。所有需要做的就是配置一个Web应用程序并使用Apache Web服务器和MySQL数据库服务器。
开始前，我们要确保/srv/salt/目录存在于服务器中。
因为Web应用程序需要在使用前安装数据库服务器，我们将首先定义数据库服务器。
由于该例子除了声明外，并不包含其它任何文件。我们可以简单地将其保存为:/srv/salt/mysql.sls。但是Apache的安装比较复杂，因为它包含了一个配置文件。该文件通过使用file.managed功能被拷贝到web服务器上，支持了像templating这样加强的功能。为了适应这种情况，我们通过在/srv/salt/目录下创建apache/子目录，并创建以下文件：
由于更多的文件将添加到该方案中，我们创建另外一个目录来保存它们。该目录在包含一个init.sls文件的同时，也包含被管理的httpd.conf文件副本。这些文件现在会与top.sls文件绑定在一起。
该文件就像胶水一样将这些状态连接在一起，定义了每个服务器上所应用的状态。需要注意的是该文件并没有涉及任何具体路径。因为top.sls定义了这类信息，因此SaltStack会到top.sls目录下查找。当SaltStack在top.sls中找到所需名称，接下来它会查找与其名称相对应的.sls文件（比如：mysql.sls）或者目录，该目录包含一个init.sls文件（比如：apache/init.sls）。
该定义确保了所有名字以&web&为开头的服务器（比如：web01，甚至是）都会有指定的Apache状态，还有任何名字以&db&开头的服务器（比如：db01或）都会有指定的MySQL状态。
将这些状态应用到所有服务器上，我们需要开始运行一个highstate命令:
Highstate是状态数据的结合（程序包、服务和文件等），它将应用到目的系统中。
然而，它也提出了另一个挑战。正如我上面所说的，这些web服务器如果没有可工作的数据库服务器的话，基本上是派不上什么用场。该场景在两者都存在的情况下可以正常工作，我们只要往组合中添加服务器就可以了。但对于一个干净的环境，没有任何服务器的情况该怎么办？
这时候就该轮到SaltStack流程引擎上场了。可以通过定义状态执行顺序来定义机器部署顺序：
这个文件定义了我们之前定义的web状态只有在我们所定义的数据库状态执行完后才能执行。启动该状态，可以执行：
注意：在salt 0.17.x里，该命令为：
寻址配置漂移
上述场景对初始配置一组服务器是可行的。如果按计划执行的话，它会通过配置漂移缓解问题：如果服务器上httpd.conf文件被修改了，SaltStack会将其放置回它需要在的地方，然后汇报给用户都要做那些修改，以回到正确的状态。但程序包的版本怎么办呢？
当pkg.installed状态被声明后，SaltStack会检测底层包管理器来查看该程序包是否已经安装。如果是，那么该状态就已经实现了，不需要任何进一步行为。然而，如果该程序包还没被安装的话，SaltStack也会通知包管理器安装该程序包，通常会检测该程序包(依具体环境而异)的最新可用版本，然后安装。
但随着时间的推移，这会造成一些服务器上的程序包所带版本不一样，由此产生的问题也将难以定位。其解决方案就是使用pkg.lastes状态取而代之，这样可以一直保证所有服务器上运行的程序包版本都是最新的。
尽管如此，这也可能产生问题。只要有新版本出来，所有服务器都会试图下载安装。如果你没有预料到会有新版本，且还没有时间执行内部测试的话，这会造成很严重的问题。所以最好还是锁定某一特定版本的程序包比较好：
这保证了只有在状态声明中明确更新时，安装包才会被升级。
SaltStack测试模式
另外一个重要特性是提前知道即将发生的变化。这点简单到只要往highstate命令添加一个选项就可以：
当运行于测试模式时，那些已各就各位的状态将显示为绿色，而那些还未执行的状态将显示为黄色。很多用户觉得在实际执行前，能够看到所需执行的变化特别重要。
当然，测试模式也可以用在业务流程引擎中：
该命令会按myorchestration.sls文件中定义的顺序评估highstate；与此同时，如果命令在测试模式以外运行的话，也会以相同的方式显示将做出的修改。
SaltStack在配置管理上有明显的重点突破，但我们也不敢打包票。SaltStack学习和运行起来都很简单，我们的社区也非常有活力和帮助，可以一路帮助那些自己动手的人；对于需要帮助的公司，SaltStack Enterprise提供了相应的SaltStack服务和支持团队。
Joseph Hall已经是个老手了，他曾从事过技术支持、QA工程师、web程序员、Linux讲师、系统管理员、主管和云计算工程师。与此同时，他还是个训练有素的厨师和调酒师。他是第二个往Salt项目中提交代码的人，目前他是SaltStack的一名核心开发人员，致力于领导Salt的云开发。
配置管理作为基础使现代基础设施成为可能。在任何运维团队的工具箱中，都需要那些实现配置管理的工具，甚至对于很多开发团队也是如此。尽管所有的工具旨在解决同样的基本问题集，但它们遵循了不同的看法，并表现出不同的特点。问题在于如何选出适合各个组织具体情况的最佳工具。
本文作为的一部分，旨在介绍当前市场上存在的部分配置工具，以及各个工具背后的原理，和使它们彼此脱颖而出的原因。您可以在订阅该系列新文章的提醒。
& 相关主题：}