The Salt system is amazingly simple and easy to configure. The two components of the Salt system each have a respective configuration file. The salt-master is configured via the master configuration file, and the salt-minion is configured via the minion configuration file.
参见
参考:‘minion的示例配置文件<configuration-examples-minion>’
The Salt Minion configuration is very simple. Typically, the only value that needs to be set is the master value so the minion knows where to locate its master.
By default, the salt-minion configuration will be in /etc/salt/minion
.
A notable exception is FreeBSD, where the configuration will be in
/usr/local/etc/salt/minion
.
master
¶缺省:salt
主机名或者master的IPV4地址。
缺省:salt
master: salt
The option can can also be set to a list of masters, enabling multi-master mode.
master:
- address1
- address2
在 2014.7.0 版更改: The master can be dynamically configured. The master
value
can be set to an module function which will be executed and will assume
that the returning value is the ip or hostname of the desired master. If a
function is being specified, then the master_type
option
must be set to func
, to tell the minion that the value is a function to
be run and not a fully-qualified domain name.
master: module.function
master_type: func
In addition, instead of using multi-master mode, the minion can be
configured to use the list of master addresses as a failover list, trying
the first address, then the second, etc. until the minion successfully
connects. To enable this behavior, set master_type
to
failover
:
master:
- address1
- address2
master_type: failover
master_type
¶2014.7.0 新版功能.
Default: str
The type of the master
variable. Can be str
, failover
or
func
.
master_type: failover
If this option is set to failover
, master
must be a list of
master addresses. The minion will then try each master in the order specified
in the list until it successfully connects. master_alive_interval
must also be set, this determines how often the minion will verify the presence
of the master.
master_type: func
If the master needs to be dynamically assigned by executing a function instead
of reading in the static master value, set this to func
. This can be used
to manage the minion's master setting from an execution module. By simply
changing the algorithm in the module to return a new master ip/fqdn, restart
the minion and it will connect to the new master.
master_alive_interval
¶master_alive_interval: 30
Configures how often, in seconds, the minion will verify that the current master is alive and responding. The minion will try to establish a connection to the next master in the list if it finds the existing one is dead.
master_shuffle
¶2014.7.0 新版功能.
缺省:'False'
If master
is a list of addresses and :conf_minion`master_type` is failover
, shuffle them before trying to
connect to distribute the minions over all available masters. This uses
Python's random.shuffle
method.
master_shuffle: True
random_master
¶缺省:'False'
If master
is a list of addresses, shuffle them before trying to
connect to distribute the minions over all available masters. This uses
Python's random.randint
method.
random_master: True
retry_dns
¶Default: 30
Set the number of seconds to wait before attempting to resolve the master hostname if name resolution fails. Defaults to 30 seconds. Set to zero if the minion should shutdown and not retry.
retry_dns: 30
sudo_runas
¶Default: None
The user to run salt remote execution commands as via sudo. If this option is
enabled then sudo will be used to change the active user executing the remote
command. If enabled the user will need to be allowed access via the sudoers file
for the user that the salt minion is configured to run as. The most common
option would be to use the root user. If this option is set the user
option
should also be set to a non-root user. If migrating from a root minion to a non
root minion the minion cache should be cleared and the minion pki directory will
need to be changed to the ownership of the new user.
sudo_user: root
sudo_user
¶Default: ''
Setting sudo_user
will cause salt to run all execution modules under an
sudo to the user given in sudo_user
. The user under which the salt minion
process itself runs will still be that provided in user
above,
but all execution modules run by the minion will be rerouted through sudo.
sudo_user: saltadm
缺省:'/'
这个目录会返回以下选项: conf_minion:"pki_dir",conf_minion:"cachedir",conf_minion:"log_file",conf_minion:"sock_dir",conf_minion:"pidfile"
root_dir: /
缺省:"系统的主机名"
参见
参考:'salt的演示<minion-id-generation>'
强调:"设置一个salt minion" 部分包含关于如何确定主机名的详细信息。
Explicitly declare the id for this minion to use. Since Salt uses detached ids it is possible to run multiple minions on the same machine but with different ids.
id: foo.bar.com
append_domain
#附加域名¶缺省:"None"
添加一个域的主机名事件,它并不存在。这个对于在'socket.getfqdn()'函数得到的系统是很有用的,虽然在FQDN里面并没法解析出来结果(例如:Solaris)
append_domain: foo.org
缺省:'/var/cache/salt'
minion缓存数据的位置.
This directory may contain sensitive data and should be protected accordingly.
cachedir: /var/cache/salt
缺省:'True'
在启动的时候,验证和设置权限配置目录。
verify_env: True
注解
When marked as True the verify_env option requires WRITE access to the configuration directory (/etc/salt/). In certain situations such as mounting /etc/salt/ as read-only for templating this will create a stack trace when state.highstate is called.
缺省:'False'
Minion可以在本地缓存返回的数据发送给它的jobs,这可能对于跟踪子节点执行的过程是一个好的方法。缺省是禁用状态,可以启用设置cache_jobs为True。
cache_jobs: False
minion_pillar_cache
¶缺省:'False'
The minion can locally cache rendered pillar data under
cachedir
/pillar. This allows a temporarily disconnected minion
to access previously cached pillar data by invoking salt-call with the --local
and --pillar_root=:conf_minion:cachedir/pillar options. Before enabling this
setting consider that the rendered pillar may contain security sensitive data.
Appropriate access restrictions should be in place. By default the saved pillar
data will be readable only by the user account running salt. By default this
feature is disabled, to enable set minion_pillar_cache to True
.
minion_pillar_cache: False
grains_cache
¶缺省:'False'
The minion can locally cache grain data instead of refreshing the data
each time the grain is referenced. By default this feature is disabled,
to enable set grains_cache to True
.
grains_cache: False
grains_deep_merge
¶2016.3.0 新版功能.
缺省:'False'
The grains can be merged, instead of overridden, using this option.
This allows custom grains to defined different subvalues of a dictionary
grain. By default this feature is disabled, to enable set grains_deep_merge
to True
.
grains_deep_merge: False
For example, with these custom grains functions:
def custom1_k1():
return {'custom1': {'k1': 'v1'}}
def custom1_k2():
return {'custom1': {'k2': 'v2'}}
Without grains_deep_merge
, the result would be:
custom1:
k1: v1
With grains_deep_merge
, the result will be:
custom1:
k1: v1
k2: v2
当主键变化的时候,minion将试图重新认证本身来接收新的主键.在较大的环境下,master上可能会导致一个syn-flood,因为所有的minion立刻进行重新认证。为了防止这一点,有一个minion等待一个随机时间,使用这个可选参数。之间的等待时间将是一个随机的秒数(0到定义的值)。
random_reauth_delay: 60
缺省:"None"
等待和master进行重新连接的最大秒数。如果设置了,这个等待将增加acceptance_wait_time秒每个迭代。
acceptance_wait_time_max: None
recon_default
¶Default: 1000
The interval in milliseconds that the socket should wait before trying to reconnect to the master (1000ms = 1 second).
recon_default: 1000
recon_max
¶Default: 10000
The maximum time a socket should wait. Each interval the time to wait is calculated by doubling the previous time. If recon_max is reached, it starts again at the recon_default.
recon_max: 10000
recon_randomize
¶缺省:'True'
Generate a random wait time on minion start. The wait time will be a random value between recon_default and recon_default and recon_max. Having all minions reconnect with the same recon_default and recon_max value kind of defeats the purpose of being able to change these settings. If all minions have the same values and the setup is quite large (several thousand minions), they will still flood the master. The desired behavior is to have time-frame within all minions try to reconnect.
recon_randomize: True
return_retry_timer
¶Default: 5
The default timeout for a minion return attempt.
return_retry_timer: 5
return_retry_timer_max
¶缺省:"10"
The maximum timeout for a minion return attempt. If non-zero the minion return
retry timeout will be a random int beween return_retry_timer
and
return_retry_timer_max
return_retry_timer_max: 10
cache_sreqs
¶缺省:'True'
The connection to the master ret_port is kept open. When set to False, the minion
creates a new connection for every return to the master.
environment, set this value to False
.
cache_sreqs: True
缺省:"ipc"
windows平台缺乏POSIX IPC,必须依靠慢缓慢的TCP,进程之间通信。在这种系统下,ipc_mode设置.为“tcp‘.
ipc_mode: ipc
transport
¶Default: zeromq
Changes the underlying transport layer. ZeroMQ is the recommended transport
while additional transport layers are under development. Supported values are
zeromq
, raet
(experimental), and tcp
(experimental). This setting has
a significant impact on performance and should not be changed unless you know
what you are doing! Transports are explained in Salt Transports.
transport: zeromq
缺省:"[]"(默认所有的模块都是启用的)
该事件可能会出现在其中,管理员希望minion不能执行特定模块。系统模块内置在minion里面,不能被禁用。
This setting can also tune the minion, as all modules are loaded into ram disabling modules will lower the minion's ram footprint.
disable_modules:
- test
- solr
缺省:"[]" (所有返回的minion都是默认启用的)
如果认证的返回节点想禁用,可以在这个地方设置。
disable_returners:
- mongo_return
grains_dirs
¶缺省:'[]'
A list of extra directories to search for Salt grains
grains_dirs:
- /var/lib/salt/grains
cython_enable
¶缺省:'False'
将这个值设置为true将会开启自动加载和编译``.pyx``模块,这个设置依赖于``gcc``和``cython``已经在minion安装
cython_enable: False
enable_zip_modules
¶2015.8.0 新版功能.
缺省:'False'
Set this value to true to enable loading of zip archives as extension modules. This allows for packing module code with specific dependencies to avoid conflicts and/or having to install specific modules' dependencies in system libraries.
enable_zip_modules: False
providers
¶默认: (空)
A module provider can be statically overwritten or extended for the minion via
the providers
option. This can be done on an individual basis in an
SLS file, or globally here in the minion config, like
below.
providers:
service: systemd
renderer
¶Default: yaml_jinja
The default renderer used for local state executions
renderer: yaml_jinja
state_verbose
¶缺省:'False'
state_verbose allows for the data returned from the minion to be more
verbose. Normally only states that fail or states that have changes are
returned, but setting state_verbose to True
will return all states that
were checked
state_verbose: True
state_output
¶Default: full
The state_output setting changes if the output is the full multi line output for each changed state if set to 'full', but if set to 'terse' the output will be shortened to a single line.
state_output: full
autoload_dynamic_modules
¶缺省:'True'
autoload_dynamic_modules Turns on automatic loading of modules found in the
environments on the master. This is turned on by default, to turn of
auto-loading modules when states run set this value to False
autoload_dynamic_modules: True
缺省:'True'
clean_dynamic_modules keeps the dynamic modules on the minion in sync with
the dynamic modules on the master, this means that if a dynamic module is
not on the master it will be deleted from the minion. By default this is
enabled and can be disabled by changing this value to False
clean_dynamic_modules: True
environment
¶缺省:"None"
Normally the minion is not isolated to any single environment on the master when running states, but the environment can be isolated on the minion side by statically setting it. Remember that the recommended way to manage environments is to isolate via the top file.
environment: None
file_client
¶Default: remote
The client defaults to looking on the master server for files, but can be
directed to look on the minion by setting this parameter to local
.
file_client: remote
use_master_when_local
¶缺省:'False'
When using a local file_client
, this parameter is used to allow
the client to connect to a master for remote execution.
use_master_when_local: False
file_roots
¶Default:
base:
- /srv/salt
When using a local file_client
, this parameter is used to setup
the fileserver's environments. This parameter operates identically to the
master config parameter
of the same name.
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
¶Default: md5
The hash_type is the hash to use when discovering the hash of a file on the local fileserver. The default is md5, but sha1, sha224, sha256, sha384, and sha512 are also supported.
hash_type: md5
pillar_roots
¶Default:
base:
- /srv/pillar
When using a local file_client
, this parameter is used to setup
the pillar environments.
pillar_roots:
base:
- /srv/pillar
dev:
- /srv/pillar/dev
prod:
- /srv/pillar/prod
pillarenv
¶缺省:"None"
Isolates the pillar environment on the minion side. This functions the same as the environment setting, but for pillar instead of states.
pillarenv: None
open_mode
¶缺省:'False'
Open mode can be used to clean out the PKI key received from the Salt master, turn on open mode, restart the minion, then turn off open mode and restart the minion to clean the keys.
open_mode: False
master_finger
¶Default: ''
Fingerprint of the master public key to validate the identity of your Salt master before the initial key exchange. The master fingerprint can be found by running "salt-key -F master" on the Salt master.
master_finger: 'ba:30:65:2a:d6:9e:20:4f:d8:b2:f3:a7:d4:65:11:13'
verify_master_pubkey_sign
¶缺省:'False'
Enables verification of the master-public-signature returned by the master in auth-replies. Please see the tutorial on how to configure this properly Multimaster-PKI with Failover Tutorial
2014.7.0 新版功能.
verify_master_pubkey_sign: True
If this is set to True
, master_sign_pubkey
must be also set
to True
in the master configuration file.
master_sign_key_name
¶Default: master_sign
The filename without the .pub suffix of the public key that should be used for verifying the signature from the master. The file must be located in the minion's pki directory.
2014.7.0 新版功能.
master_sign_key_name: <filename_without_suffix>
always_verify_signature
¶缺省:'False'
If verify_master_pubkey_sign
is enabled, the signature is only verified,
if the public-key of the master changes. If the signature should always be verified,
this can be set to True
.
2014.7.0 新版功能.
always_verify_signature: True
缺省:'True'
If multiprocessing is enabled when a minion receives a publication a new process is spawned and the command is executed therein. Conversely, if multiprocessing is disabled the new publication will be run executed in a thread.
multiprocessing: True
log_file
¶Default: /var/log/salt/minion
The minion log can be sent to a regular file, local path name, or network
location. See also log_file
.
Examples:
log_file: /var/log/salt/minion
log_file: file:///dev/log
log_file: udp://loghost:10514
log_level
¶Default: info
The level of messages to send to the console. See also log_level
.
log_level: warning
log_level_logfile
¶Default: info
The level of messages to send to the log file. See also
log_level_logfile
. When it is not set explicitly
it will inherit the level set by log_level
option.
log_level_logfile: warning
log_datefmt
¶Default: %H:%M:%S
The date and time format used in console log messages. See also
log_datefmt
.
log_datefmt: '%H:%M:%S'
log_datefmt_logfile
¶Default: %Y-%m-%d %H:%M:%S
The date and time format used in log file messages. See also
log_datefmt_logfile
.
log_datefmt_logfile: '%Y-%m-%d %H:%M:%S'
log_fmt_console
¶Default: [%(levelname)-8s] %(message)s
The format of the console logging messages. See also
log_fmt_console
.
注解
Log colors are enabled in log_fmt_console
rather than the
color
config since the logging system is loaded before the
minion config.
Console log colors are specified by these additional formatters:
%(colorlevel)s %(colorname)s %(colorprocess)s %(colormsg)s
Since it is desirable to include the surrounding brackets, '[' and ']', in the coloring of the messages, these color formatters also include padding as well. Color LogRecord attributes are only available for console logging.
log_fmt_console: '%(colorlevel)s %(colormsg)s'
log_fmt_console: '[%(levelname)-8s] %(message)s'
log_fmt_logfile
¶Default: %(asctime)s,%(msecs)03.0f [%(name)-17s][%(levelname)-8s] %(message)s
The format of the log file logging messages. See also
log_fmt_logfile
.
log_fmt_logfile: '%(asctime)s,%(msecs)03.0f [%(name)-17s][%(levelname)-8s] %(message)s'
log_granular_levels
¶Default: {}
This can be used to control logging levels more specifically. See also
log_granular_levels
.
zmq_monitor
¶缺省:'False'
To diagnose issues with minions disconnecting or missing returns, ZeroMQ supports the use of monitor sockets to log connection events. This feature requires ZeroMQ 4.0 or higher.
To enable ZeroMQ monitor sockets, set 'zmq_monitor' to 'True' and log at a debug level or higher.
A sample log event is as follows:
[DEBUG ] ZeroMQ event: {'endpoint': 'tcp://127.0.0.1:4505', 'event': 512,
'value': 27, 'description': 'EVENT_DISCONNECTED'}
All events logged will include the string ZeroMQ event
. A connection event
should be logged as the minion starts up and initially connects to the
master. If not, check for debug log level and that the necessary version of
ZeroMQ is installed.
failhard
¶缺省:'False'
Set the global failhard flag, this informs all states to stop running states at the moment a single state fails
failhard: False
default_include
¶Default: minion.d/*.conf
The minion can include configuration from other files. Per default the minion will automatically include all config files from minion.d/*.conf where minion.d is relative to the directory of the minion configuration file.
include
¶Default: not defined
The minion can include configuration from other files. To enable this, pass a list of paths to this option. The paths can be either relative or absolute; if relative, they are considered to be relative to the directory the main minion configuration file lives in. Paths can make use of shell-style globbing. If no files are matched by a path passed to this option then the minion will log a warning message.
# Include files from a minion.d directory in the same
# directory as the minion config file
include: minion.d/*.conf
# Include a single extra file into the configuration
include: /etc/roles/webserver
# Include several files and the minion.d directory
include:
- extra_config
- minion.d/*
- /etc/roles/webserver
These options control how salt.modules.saltutil.update()
works with esky
frozen apps. For more information look at https://github.com/cloudmatrix/esky/.
update_url
¶Default: False
(Update feature is disabled)
The url to use when looking for application updates. Esky depends on directory listings to search for new versions. A webserver running on your Master is a good starting point for most setups.
update_url: 'http://salt.example.com/minion-updates'
update_restart_services
¶Default: []
(service restarting on update is disabled)
A list of services to restart when the minion software is updated. This would typically just be a list containing the minion's service name, but you may have other services that need to go with it.
update_restart_services: ['salt-minion']
重要
To use these config options, the minion must be running in masterless mode
(set file_client
to local
).
winrepo_dir
¶在 2015.8.0 版更改: Renamed from win_repo
to winrepo_dir
. Also, this option did not
have a default value until this version.
Default: C:\salt\srv\salt\win\repo
Location on the minion where the winrepo_remotes
are checked
out.
winrepo_dir: 'D:\winrepo'
winrepo_cachefile
¶在 2015.8.0 版更改: Renamed from win_repo_cachefile
to winrepo_cachefile
. Also,
this option did not have a default value until this version.
Default: winrepo.p
Path relative to winrepo_dir
where the winrepo cache should be
created.
winrepo_cachefile: winrepo.p
winrepo_remotes
¶在 2015.8.0 版更改: Renamed from win_gitrepos
to winrepo_remotes
. Also, this option did
not have a default value until this version.
2015.8.0 新版功能.
Default: ['https://github.com/saltstack/salt-winrepo.git']
List of git repositories to checkout and include in the winrepo
winrepo_remotes:
- https://github.com/saltstack/salt-winrepo.git
To specify a specific revision of the repository, prepend a commit ID to the URL of the the repository:
winrepo_remotes:
- '<commit_id> https://github.com/saltstack/salt-winrepo.git'
Replace <commit_id>
with the SHA1 hash of a commit ID. Specifying a commit
ID is useful in that it allows one to revert back to a previous version in the
event that an error is introduced in the latest revision of the repo.