Jinja 2 is a templating language used in pyhton. It allows use code blocks to serve files with dynamic content. There are 2 ways to use jinja 2 templates in Salt state files. The first type is variable wherein a variable is enclosed within a set of double curly braces. For example, {{ myvar }}. We can use basic conditional statements in jinja 2 templates providing some conditional flow control. Syntax for using conditional statement is using % symbol at beginning & end of the curly braces like {{% some_condition %}}. This can help make our state files platform agnostic.
Consider the apache state file that was used in the previous article. We know that apache is installed as httpd in RedHat OS variants & as apache2 in Debian variants. Let's use jinja 2 to modify the state file such that httpd is installed for RedHat & apache2 for Debian variants respectively.
install_apache:
pkg.installed
{{% if grains['os_family'] == 'RedHat' %}}
- name: httpd
{{% elif grains['os_family'] == 'Debian' %}}
- name: apache2
{{% endif %}}
ensure apache is started:
service.running:
{{% if grains['os_family'] == 'RedHat' %}}
- name: httpd
{{% elif grains['os_family'] == 'Debian' %}}
- name: apache2
{{% endif %}}
- enable: True
- require:
- pkg: install apache
Understanding pillars:
Using pillars is a means of providing access to certain data to selected minions only so that the data is 'need to know basis only' for the minions. We define our pillar files in /srv/pillar directory with the .sls extension. Once we've defined pillar in .sls files, we need to write a topfile top.sls to inform the salt master which minions will have access to which pillar data. Given below is an example topfile:
base:
'*':
- pill1
'os_family:debian':
- match: grain
- pill2
The above top file states that all minions will have access to data in pillar file pill1 but only minions running debian OS variant will have access to date in pill2. Pillar data distributed in this manner can be used in state files in combination with jinja 2 templates.
To sync pillar data across minions we use saltutil.refresh_pillar command like the example below:
salt '*' pillar.refresh_pillar
To view pillar items distributed accross the minions use pillar.items command:
salt '*' pillar.items
Highstates:
The concept of highstates allows us to apply different state state files to different minions together in one go thereby exetending the different desired state of configurations across multiple minions via the execution of a single salt command.
To apply a highstate configuration we use the state.highstate module.
salt '*' state.highstate
The state.highstate command executes the declared desired configuration state as described in the top file which is also used for distributing pillar data.
So, to implement a highstate an example top file is shown below:
base:
'*":
- state1
'os_family:RedHat':
- state2
When we run the highstate, the state1 configuration is applied across all minions & the state2 configuration is applied only on minions running a RedHat OS variant.
Consider the apache state file that was used in the previous article. We know that apache is installed as httpd in RedHat OS variants & as apache2 in Debian variants. Let's use jinja 2 to modify the state file such that httpd is installed for RedHat & apache2 for Debian variants respectively.
install_apache:
pkg.installed
{{% if grains['os_family'] == 'RedHat' %}}
- name: httpd
{{% elif grains['os_family'] == 'Debian' %}}
- name: apache2
{{% endif %}}
ensure apache is started:
service.running:
{{% if grains['os_family'] == 'RedHat' %}}
- name: httpd
{{% elif grains['os_family'] == 'Debian' %}}
- name: apache2
{{% endif %}}
- enable: True
- require:
- pkg: install apache
Understanding pillars:
Using pillars is a means of providing access to certain data to selected minions only so that the data is 'need to know basis only' for the minions. We define our pillar files in /srv/pillar directory with the .sls extension. Once we've defined pillar in .sls files, we need to write a topfile top.sls to inform the salt master which minions will have access to which pillar data. Given below is an example topfile:
base:
'*':
- pill1
'os_family:debian':
- match: grain
- pill2
The above top file states that all minions will have access to data in pillar file pill1 but only minions running debian OS variant will have access to date in pill2. Pillar data distributed in this manner can be used in state files in combination with jinja 2 templates.
To sync pillar data across minions we use saltutil.refresh_pillar command like the example below:
salt '*' pillar.refresh_pillar
To view pillar items distributed accross the minions use pillar.items command:
salt '*' pillar.items
Highstates:
The concept of highstates allows us to apply different state state files to different minions together in one go thereby exetending the different desired state of configurations across multiple minions via the execution of a single salt command.
To apply a highstate configuration we use the state.highstate module.
salt '*' state.highstate
The state.highstate command executes the declared desired configuration state as described in the top file which is also used for distributing pillar data.
So, to implement a highstate an example top file is shown below:
base:
'*":
- state1
'os_family:RedHat':
- state2
When we run the highstate, the state1 configuration is applied across all minions & the state2 configuration is applied only on minions running a RedHat OS variant.
No comments:
Post a Comment