【基本介绍】
这里介绍master的配置文件。salt系统的配置很简单salt-master是通过一个名为master的文件配置,salt-minion是通过一个名为minion的文件配置。
【配置解析】
interface
默认值:0.0.0.0(所有的网络地址接口)
绑定到本地的某个网络地址接口
interface: 192.168.0.1
publish_port
默认值:4505
设置master与minion的认证通信端口
publish_port: 4505
user
默认值:root
运行salt进程的用户
user: root
max_open_files
默认值:100000
每一个minion连接到master,至少要使用一个文件描述符,如果足够多的minion连接到master上,你将会从控制台上看到salt-master crashes:
Too many open files (tcp_listener.cpp:335)
Aborted (core dumped)
默认值这个值取决于ulimit -Hn的值,即系统的对打开文件描述符的硬限制
如果你希望重新设置改值或者取消设置,记住这个值不能超过硬限制,提高硬限制取决于你的操作系统或分配,一个好的方法是internet找到对应操作系统的硬限制设置,比如这样搜索:
raise max open files hard limit debian
max_open_files: 100000
worker_threads
默认值:5
启动用来接收或应答minion的线程数。如果你有很多minion,而且minion延迟你的应答,你可以适度的提高该值.
在点对点的系统环境中使用时,该值不要被设置为3以下,但是可以将其设置为1
worker_threads: 5
ret_port
默认值:4506
这个端口是master用来发送命令或者接收minions的命令执行返回信息
ret_port: 4506
pidfile
默认值:/var/run/salt-master.pid
指定master的pid文件位置
pidfile: /var/run/salt-master.pid
root_dir
默认值:/
指定该目录为salt运行的根目录,改变它可以使salt从另外一个目录开始运行,好比chroot
root_dir: /
pki_dir
默认值:/etc/salt/pki
这个目录是用来存放pki认证秘钥
pki_dir: /etc/salt/pki
cachedir
默认值:/var/cache/salt
这个目录是用来存放缓存信息,特别是salt工作执行的命令信息
cachedir: /var/cache/salt
keep_jobs
默认值:24
设置保持老的工作信息的过期时间,单位小时
job_cache
默认值:True
设置master维护的工作缓存,这是一个很好的功能,当你的Minons超过5000台时,他将很好的承担这个大的架构,关闭这个选项,之前的工作执行以及工作系统将无法被利用,一般不推荐关掉改选项,开启改选项将会是很明智的,他将使master获得更快的IO系统
ext_job_cache
默认值:”
对所有的minions使用指定的默认值returner,当使用了这个参数来指定一个returner并且配置正确,minions将会一直将返回的数据返回到returner,这也会默认值禁用master的本地缓存
ext_job_cache: redis
minion_data_cache
默认值:True
minion data cache是关于minion信息存储在master上的参数,这些信息主要是pillar 和 grains数据.这些数据被缓存在cachedir定义的目录下的minion目录下以minion名为名的目录下并且预先确定哪些minions将从执行回复
minion_cache_dir: True
enforce_mine_cache
默认值:False
默认情况下当关闭了minion_data_cache,mine将会停止工作,因为mine是基于缓存数据,通过启用这个选项,我们将会显示的开启对于mine系统的缓存功能
enforce_mine_cache: False
sock_dir
默认值:/tmp/salt-unix
指定unix socket主进程通信的socket创建路径
#######################
master的安全配置
open_mode
默认值:False
open_mode是一个危险的安全特性,当master遇到pki认证系统,秘钥混淆和身份验证失效时,打开open_mode,master将会接受所有的身份验证。这将会清理掉pki秘钥接受的minions。通常情况下open_mode不应该被打开,它只适用于短时间内清理pki keys,若要打开它,可将值调整为True
open_mode: False
auto_accept
默认值:False
开启auto_accept。这个设置将会使master自动接受所有发送公钥的minions
auto_accept: False
autosign_file
默认值:/etc/salt/autosign.conf
如果autosign_file的值被指定,那么autosign_file将会通过该输入允许所有的匹配项,首先会搜索字符串进行匹配,然后通过正则表达式进行匹配。这是不安全的
autosign_file: /etc/salt/autosign.conf
client_acl
默认值:{}
开启对系统上非root的系统用户在master上执行特殊的模块,这些模块名可以使用正则表达式进行表示
client_acl:
fred:
- test.ping
- pkg.*
client_acl_blacklist
默认值:{}
黑名单用户或模块
这个例子表示所有非sudo用户以及root都无法通过cmd这个模块执行命令,默认情况改配置是完全禁用的
client_acl_blacklist:
users:
- root
- '^(?!sudo_).*$' # all non sudo users
modules:
- cmd
external_auth
默认值:{}
salt的认证模块采用外部的认证系统用来做认证和验证用户在salt系统中的访问区域
external_auth:
pam:
fred:
- test.*
token_expire
默认:43200
新令牌生成的时间间隔,单位秒,默认是12小时
token_expire: 43200
file_recv
默认值:False
允许minions推送文件到master上,这个选项默认是禁用的,出于安全考虑
file_recv: False
#######################
master模块管理
runner_dirs
默认值:[] 设置搜索runner模块的额外路径
runner_dirs: []
cython_enable
默认值:False
设置为true来开启对cython模块的编译
cython_enable: False
#######################
master状态系统设置
state_verbose
默认:False
state_verbose允许从minions返回更多详细的信息,通常清空下只返回失败或者已经更改,但是将state_verbose设置为True,将会返回所有的状态检查
state_verbose: True
state_output
默认值:full
state_output的设置将会改变信息输出的格式,当被设置为”full”时,将全部的输出一行一行的显示输出;当被设置为”terse“时,将会被缩短为一行进行输出;当被设置为”mixed”时,输出样式将会是简洁的,除非状态失败,这种情况下将会全部输出;当被设置为”change”时,输出将会完全输出除非状态没有改变
state_output: full
state_top
默认值:top.sls
状态系统使用一个入口文件告诉minions在什么环境下使用什么模块,这个状态入口文件被定义在基础环境的相对根路径下
state_top: top.sls
external_nodes
默认值:None
这个外部节点参数允许salt来收集一些数据,通常被放置在一个入口文件或外部节点控制器.外部节点的选择是可执行的,将会返回ENC数据,记住如果两者都启用的话salt会将外部节点和入口文件的结果进行综合汇总。
external_nodes: cobbler-ext-nodes
renderer
默认值:yaml_jinja
使用渲染器用来渲染minions的状态数据
renderer: yaml_jinja
failhard
默认值:False
设置一个全局的failhard表示,当单个的状态执行失败后,将会通知所有的状态停止运行状态
failhard: False
test
默认值:False
如果真的要作出改变或者仅仅通知将要执行什么改变时设置所有的状态调用为test
test: False
#######################
master文件服务器设置
fileserver_backend
默认值:
fileserver_backend:
- roots
salt支持模块化的后端文件系统服务器,它允许salt通过第三方的系统来管理收集文件并提供给minions使用,可以配置多个后端文件系统,这里支持gitfs、hgfs、roots、s3fs文件调用的搜索顺序按照后台文件系统的配置顺序来搜索,默认的设置只开启了标准的后端服务器roots,具体的根选项配置通过file_roots参数设置
fileserver_backend:
- roots
- gitfs
file_roots
默认值:
base:
- /srv/salt
salt运行一个轻量级的文件服务器通过ZeroMQ对minions进行文件传输,因此这个文件服务器是构造在master的守护进程中,并且不需要依赖于专用的端口
文件服务器的工作环境传递给master,每一个环境可以有多个跟目录,但是相同环境下多个文件的子目录不能相同,否则下载的文件将不能被可靠的保证,一个基础环境依赖于主的入口文件,如:
file_roots:
base:
- /srv/salt
dev:
- /srv/salt/dev/services
- /srv/salt/dev/states
prod:
- /srv/salt/prod/services
- /srv/salt/prod/states
hash_type
默认值:md5
hash_type是用来当发现在master上需要对一个文件进行hash时的hash使用的算法,默认是md5.但是它也支持sha1,sha224,shar256,shar384,shar512
hash_type: md5
file_buffer_size
默认值:1048576
文件服务器的缓存区大小
file_buffer_size: 1048576
#######################
pillar配置
pillar_roots
默认值:
base:
- /srv/pillar
设置不同的环境对应的存放pillar数据的目录,这个配置和file_roots参数配置一样
pillar_roots:
base:
- /srv/pillar
dev:
- /srv/pillar/dev
prod:
- /srv/pillar/prod
ext_pillar
当进行pillar数据收集时,这个ext_pillar参数允许调用任意数量的外部pillar接口,这个配置是基于ext_pillar函数,你可以从这个找到这个函数https://github.com/saltstack/salt/blob/develop/salt/pillar
默认情况下,这个ext_pillar接口没有配置运行
默认值:None
ext_pillar:
- hiera: /etc/hiera.yaml
- cmd_yaml: cat /etc/salt/yaml
- reclass:
inventory_base_uri: /etc/reclass
【参考引用】
http://blog.coocla.org/301.html
分享到:
相关推荐
在prod下面创建了一个modules的目录,所有的安装配置都放在这个目录下面了,里面分别又对应创建了对应的软件目录,每个软件目录下面的files目录用来存放的是软件包或者配置文件模板pkg基础包安装源码编译所需要用到...
- **Master-Slave架构**:SaltStack采用主从架构设计,其中Salt Master作为中心节点负责下发命令和配置文件到各个Salt Minion节点。 - **事件驱动**:SaltStack的核心特性之一是其事件驱动模型,这使得它可以快速...
6. Master 监控端口默认为 4505(传输协议)和 4506(加密通信),配置文件位于 `/etc/salt/master`。 在实际使用中,运维人员可以利用 SaltStack 的状态系统 (States) 定义服务器的期望状态,比如安装软件、配置...
此外,还会涉及SaltStack的配置文件解析,让你理解如何定制化你的SaltStack部署。 在SaltStack的核心功能部分,书籍会讲解如何利用States(状态管理)实现配置管理,通过声明式的方式定义系统的期望状态,确保系统...
【压缩包子文件的文件名称列表】:master-minion-salt-vagrant-master 暗示这是整个项目的主要分支或最新版本,包含 SaltStack Master 的配置和相关的 Vagrant 配置文件。 **详细知识点** 1. **SaltStack Master-...
- **Master**: SaltStack的管理中心,用于发布命令、配置文件等。 - **Minion**: 被管理的节点,接收并执行Master发来的命令或配置。 #### 三、SaltStack部署流程 ##### 3.1 Master端部署 **环境准备** - 操作...
配置文件示例(Configuration file examples)提供了一种方便的查看和学习配置文件的方法,这些配置文件对Salt Master和Minion的运行至关重要。 在SaltStack中,存储作业结果到外部系统(Storing Job Results in an...
"saltstack-kodi-formula" 提供了一个结构化的框架,通过 Salt 的状态文件(通常为 .sls 文件)来定义如何安装和配置 Kodi。这些状态文件使用 Salt 的 YAML 风格语法编写,可以指定软件源、版本、依赖关系以及所需的...
这通常包括安装SaltStack的master和minion组件,设置必要的网络配置,以及可能的初始配置文件或状态(states)。 LXC容器在宿主机操作系统上运行,因此它们共享同一内核,这使得LXC比完整的虚拟机更高效。对于快速...
在实际应用中,SaltStack 可以用于执行远程命令、分发配置文件、执行状态变更(State)以保持服务器状态的一致性,甚至可以集成到持续集成/持续部署(CI/CD)流程中。其丰富的模块(如 file, cmd, service 等)和...
在 SaltStack-salt-0183809 压缩包中,可能包含了 SaltStack 的源代码、文档、示例配置文件等资源,可以帮助学习和实践 SaltStack 的各项功能。通过深入理解和实践,可以有效提升 IT 运维效率,降低管理复杂度,确保...
SaltStack安装配置 SaltStack是一个基于Python的自动化工具,用于管理和配置服务器集群。下面将详细介绍SaltStack的安装配置过程。 SaltStack安装 在CentOS 6.5 x86 64操作系统上安装SaltStack需要满足以下条件:...
### SaltStack 安装配置与使用详解 #### 一、SaltStack 基础介绍 ##### SaltStack 简介 SaltStack 是一种高效的基础设施管理工具,它提供了一个集中的平台来管理大量的服务器集群。SaltStack 的核心优势在于其快速...
在源码包中,你将看到与Master相关的配置文件和脚本。 2. **Minion**: Minions是连接到Master的远程节点,它们执行Master发送的命令并返回结果。在解压后的文件中,Minion的配置和执行引擎的源代码都可以被研究。 ...
通过部署SaltStack环境,用户能够在数千乃至数万台服务器上批量执行命令、根据不同的业务特性进行配置集中化管理、分发文件、采集服务器数据、操作系统基础及软件包管理等。这使得SaltStack成为运维人员提高工作效率...
6. **Jinja2**:SaltStack 使用 Jinja2 模板语言来编写配置文件,允许动态和复杂的逻辑处理,提高了配置的灵活性。 7. **Modules**:提供了一系列预定义的命令,用于执行各种任务,如文件管理、包管理、服务管理等...
1. **解析启动参数**:在启动 SaltStack Master 时,会解析命令行参数,这些参数通常包括配置文件路径、监听接口、端口号等关键信息。 2. **加载配置文件**:根据解析出的参数,读取相应的配置文件(通常是 `/etc/...