Jinja2 is a modern and designer-friendly templating language for Python frameworks. It is fast, reliable and widely used for dynamic file generation based on its parameter. In this blog, I like to share how and where jinja2 template language used in Ansible and how we can create better Ansible playbook.
How it works
The Jinja variables and expressions indicated using the default delimiters as follows:
- {% … %} for control statements (conditions)
- {{ … }} for expressions (variables)
- {# … #} for comments (describe the task)
Here’s an example Jinja expressions:
Variable definitions are needed for Jinja to resolve expressions. In the above example, definitions are required for ip and os_name.
In Ansible, more then 21 places we can declare or define variable or value to the variable, below we have shared three important places:
- Role defaults d
- Passing a YAML or JSON file with the –vars-file option
- Environment variables
Variable files (vars_file or vars)
Pass the path to a file containing variable definitions using the –vars-file option. The file path must be one of the following:
- Absolute file path
- Relative to the project path
- Relative to the ansible folder
When –vars-file is passed, Ansible Container checks if the path is an absolute path to a file. If not, it checks for the file relative to the project path, which is the current working directory. If the file is still not found, it looks for the file relative to the ansible folder within the project path.
Variable files can also be specified using the vars_files directive under settings in container.yml. For example:
This templating will helpful for many automation. It can be used to create a dynamic configuration for MySQL, Nagios depend upon the resources.
Example:
MySQL innodb_buffer_pool have to be 70% of total RAM for better performance. So it’s easy to make it from ansible variables like,
Breakdown:
ansible_memtotal_mb will be retrieved from the setup module. Basically, it will return the system stats and assigned it to respected variables.
Command to get complete stats about the system.
To get stats about the local system:
To get stats about the remote system from the inventory file:
This can be disabled by adding the “gather_facts: no” in the respected host.
Sample:
Auto generated variable definitions using the ansible stats (system resources). Based on the condition it will revert the values for the respected variables.
Below is the sample yaml file which has the syntax and the variables.
mysql_conf.yml:
When we have the variable definition ready we need to apply it for generating the configuration file with required fields.
mysql_conf.j2: (template)
Above will have the condition mapping along with the variable precedence. If the condition matches it will return the values with respect to the resource or it will keep the default value.
Playbook:
Command to generate my.cnf using the template:
ansible-playbook playbook.yml
Output:
my.cnf: (OUTPUT)
The above cnf was generated using the template. I hope it will give you a better idea about templating using Jinja2.
Key takeaways:
- Easy to debug. Line numbers of exceptions directly point to the correct line in the template even with the column number.
- Configurable syntax with respected the yaml files.
Don't settle for static configurations. Embrace Jinja2's power with Mydbops! Contact us today for a free consultation and unlock the potential of dynamic Ansible playbooks for your MySQL environment.
{{cta}}