
Conflicts: - doc/ref/configuration/master.rst - doc/ref/modules/all/index.rst - doc/topics/grains/index.rst - doc/topics/releases/2016.3.4.rst - doc/topics/spm/spm_formula.rst - doc/topics/tutorials/cron.rst - doc/topics/tutorials/index.rst - doc/topics/tutorials/stormpath.rst - salt/engines/slack.py - salt/log/handlers/fluent_mod.py - salt/modules/cyg.py - salt/modules/junos.py - salt/modules/namecheap_dns.py - salt/modules/namecheap_domains.py - salt/modules/namecheap_ns.py - salt/modules/namecheap_ssl.py - salt/modules/namecheap_users.py - salt/modules/reg.py - salt/modules/tomcat.py - salt/modules/vault.py - salt/modules/win_file.py - salt/modules/zpool.py - salt/output/highstate.py - salt/renderers/pass.py - salt/runners/cache.py - salt/states/boto_apigateway.py - salt/states/boto_iam.py - salt/states/boto_route53.py - salt/states/msteams.py - salt/states/reg.py - salt/states/win_iis.py - tests/integration/modules/test_cmdmod.py - tests/integration/states/test_user.py - tests/support/helpers.py - tests/unit/cloud/clouds/test_openstack.py - tests/unit/fileserver/test_gitfs.py - tests/unit/modules/test_junos.py - tests/unit/pillar/test_git.py - tests/unit/states/test_win_path.py - tests/unit/test_pillar.py - tests/unit/utils/test_format_call.py - tests/unit/utils/test_utils.py - tests/unit/utils/test_warnings.py
5.2 KiB
Renderers
The Salt state system operates by gathering information from common data types such as lists, dictionaries, and strings that would be familiar to any developer.
SLS files are translated from whatever data templating format they are written in back into Python data types to be consumed by Salt.
By default SLS files are rendered as Jinja templates and then parsed as YAML documents. But since the only thing the state system cares about is raw data, the SLS files can be any structured format that can be dreamed up.
Currently there is support for Jinja + YAML
,
Mako + YAML
, Wempy + YAML
,
Jinja + json
, Mako + json
and
Wempy + json
.
Renderers can be written to support any template type. This means that the Salt states could be managed by XML files, HTML files, Puppet files, or any format that can be translated into the Pythonic data structure used by the state system.
Multiple Renderers
A default renderer is selected in the master configuration file by
providing a value to the renderer
key.
When evaluating an SLS, more than one renderer can be used.
When rendering SLS files, Salt checks for the presence of a Salt-specific shebang line.
The shebang line directly calls the name of the renderer as it is
specified within Salt. One of the most common reasons to use multiple
renderers is to use the Python or py
renderer.
Below, the first line is a shebang that references the
py
renderer.
#!py
def run():
'''
Install the python-mako package
'''
return {'include': ['python'],
'python-mako': {'pkg': ['installed']}}
Composing Renderers
A renderer can be composed from other renderers by connecting them in
a series of pipes(|
).
In fact, the default Jinja + YAML
renderer is
implemented by connecting a YAML renderer to a Jinja renderer. Such
renderer configuration is specified as: jinja | yaml
.
Other renderer combinations are possible:
yaml
i.e, just YAML, no templating.
mako | yaml
pass the input to the
mako
renderer, whose output is then fed into theyaml
renderer.jinja | mako | yaml
This one allows you to use both jinja and mako templating syntax in the input and then parse the final rendered output as YAML.
The following is a contrived example SLS file using the
jinja | mako | yaml
renderer:
#!jinja|mako|yaml
An_Example:
cmd.run:
- name: |
echo "Using Salt ${grains['saltversion']}" \
"from path {{grains['saltpath']}}."
- cwd: /
<%doc> ${...} is Mako's notation, and so is this comment. </%doc>
{# Similarly, {{...}} is Jinja's notation, and so is this comment. #}
For backward compatibility, jinja | yaml
can also be
written as yaml_jinja
, and similarly, the
yaml_mako
, yaml_wempy
,
json_jinja
, json_mako
, and
json_wempy
renderers are all supported.
Keep in mind that not all renderers can be used alone or with any other renderers. For example, the template renderers shouldn't be used alone as their outputs are just strings, which still need to be parsed by another renderer to turn them into highstate data structures.
For example, it doesn't make sense to specify
yaml | jinja
because the output of the YAML renderer is a
highstate data structure (a dict in Python), which cannot be used as the
input to a template renderer. Therefore, when combining renderers, you
should know what each renderer accepts as input and what it returns as
output.
Writing Renderers
A custom renderer must be a Python module placed in the renderers
directory and the module implement the render
function.
The render
function will be passed the path of the SLS
file as an argument.
The purpose of the render
function is to parse the
passed file and to return the Python data structure derived from the
file.
Custom renderers must be placed in a _renderers
directory within the file_roots
specified by the master config
file.
Custom renderers are distributed when any of the following are run:
state.apply <salt.modules.state.apply_>
saltutil.sync_renderers <salt.modules.saltutil.sync_renderers>
saltutil.sync_all <salt.modules.saltutil.sync_all>
Any custom renderers which have been synced to a minion, that are named the same as one of Salt's default set of renderers, will take the place of the default renderer with the same name.
Examples
The best place to find examples of renderers is in the Salt source code.
Documentation for renderers included with Salt can be found here:
salt/renderers
Here is a simple YAML renderer example:
import salt.utils.yaml
from salt.utils.yamlloader import SaltYamlSafeLoader
from salt.ext import six
def render(yaml_data, saltenv='', sls='', **kws):
if not isinstance(yaml_data, six.string_types):
= yaml_data.read()
yaml_data = salt.utils.yaml.safe_load(yaml_data)
data return data if data else {}
Full List of Renderers
all/index