Jinja2 for better Ansible

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:

- hosts:
    - vars.yml
    - name: Checking the IP address
        msg: "IP address {{ ip }}"
    - name: Checking OS name
        msg: "OS NAME {{ os_name }}"

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:

- hosts:
    - vars.yml

This templating will helpful for many automation. It can be used to create a dynamic configuration for MySQL, Nagios depend upon the resources.


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,

mysql_innodb_buffer_pool_size: "{{ (ansible_memtotal_mb * 0.7) | int }}M"


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:

ansible --connection=local -m setup

To get stats about the remote system from the inventory file:

ansible -i inventory_file group_name -m setup

This can be disabled by adding the “gather_facts: no” in the respected host.


- hosts: all
  gather_facts: no

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 connection settings.

mysql_port: "3306"
mysql_data_dir: "/var/lib/mysql"
mysql_pid_file: "{{ mysql_data_dir }}/mysqld.pid"
mysql_socket: "{{ mysql_data_dir }}/mysql.sock"

# Slow query log settings.
mysql_slow_query_log_enabled: yes
mysql_slow_query_time: "2"
mysql_slow_query_log_file: "{{ mysql_data_dir }}/mysql-slow.log"

# Based on resources

mysql_max_connections: "{{ (ansible_memtotal_mb // 12) | int }}"
# Set .._buffer_pool_size up to 70% of RAM but beware of setting too high.
mysql_innodb_buffer_pool_size: "{{ (ansible_memtotal_mb * 0.7) | int }}M"
# Set .._log_file_size to 25% of buffer pool size.
mysql_innodb_log_file_size: '{{ ((mysql_innodb_buffer_pool_size | string | replace("M", "") | int) * 0.25) | int }}M'

When we have the variable definition ready we need to apply it for generating the configuration file with required fields.

mysql_conf.j2: (template)

# {{ ansible_managed }}

port = {{ mysql_port }}
socket = {{ mysql_socket }}
port = {{ mysql_port }}
datadir = {{ mysql_data_dir }}
socket = {{ mysql_socket }}
pid-file = {{ mysql_pid_file }}

# Slow query log configuration.

{% if mysql_slow_query_log_enabled %}
slow_query_log = 1
slow_query_log_file = {{ mysql_slow_query_log_file }}
long_query_time = {{ mysql_slow_query_time }}
{% endif %}

# InnoDB settings.

innodb_buffer_pool_size = {{ mysql_innodb_buffer_pool_size }}
innodb_log_file_size = {{ mysql_innodb_log_file_size }}

# Setting max connections

{% if mysql_max_connections | int > 3000 %}
max_connections = 3000
thread_cache_size = {{ (3000 * 0.15) | int }}
{% elif mysql_max_connections | int < 150 %}
max_connections = 150
thread_cache_size = {{ (150 * 0.15) | int }}
{% else %}
max_connections = {{ mysql_max_connections }}
thread_cache_size = {{ (mysql_max_connections | int * 0.15) | int }}
{% endif %}

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.


- hosts:
    - mysql_conf.yml
    - name: Creating my.cnf with respected resources
      src: mysql_conf.j2
      dest: my.cnf

Command to generate my.cnf using the template:

ansible-playbook playbook.yml


Mydbops-MacBook-Air:jinja dhanasekar$ ansible-playbook playbook.yml

PLAY [] **********************************************

TASK [Gathering Facts] ****************************************
ok: []

TASK [Creating my.cnf with respected resources] ***************
changed: []

PLAY RECAP ****************************************************                  : ok=2    changed=1    unreachable=0    failed=0

my.cnf: (OUTPUT)

# Ansible managed

port = 3306
socket = /var/lib/mysql/mysql.sock

port = 3306
datadir = /var/lib/mysql
socket = /var/lib/mysql/mysql.sock
pid-file = /var/lib/mysql/mysqld.pid
# Slow query log configuration.
slow_query_log = 1
slow_query_log_file = /var/lib/mysql/mysql-slow.log
long_query_time = 2

# InnoDB settings.
innodb_buffer_pool_size = 5734M
innodb_log_file_size = 1433M
# Setting max connections
max_connections = 682
thread_cache_size = 102

The above cnf was generated using the template. I hope it will give you a better idea about templating using Jinja2.

Key takeaways:

  1. Easy to debug. Line numbers of exceptions directly point to the correct line in the template even with the column number.
  2. Configurable syntax with respected the yaml files.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s