# ansible / templating / jinja2

Dynamic Files with Jinja2

Jinja2 is a powerful templating engine used by Ansible. Instead of creating and maintaining dozens of static configuration files for different servers, you create one template, and Ansible dynamically injects the correct variables during execution.

See the Workflow →Jump to Syntax

Module: template✓

Inputconfig.j2

EngineJinja2 Renderer

Output/tmp/config.conf

StatusVariables Injected

Variables

{% %}

Logic

# the-problem

Why do we need Jinja2?

Suppose you manage three different environments (Dev, Test, Prod). Each requires a configuration file with slightly different ports and debug modes.

without jinja2

The Static Nightmare

You would need to create and maintain three completely separate files (dev.conf, test.conf, prod.conf). As the number of servers scales up to 100+, maintaining multiple static files becomes impossible.

Server Env	Port	Debug Mode
Dev	8080	true
Test	8081	true
Prod	9090	false

THE SOLUTION

With Jinja2, you maintain only one template file. Ansible automatically populates the correct Port and Debug status based on the target server.

# workflow

How Jinja2 Works

Step 1: Create a Template (config.j2)JINJA2

1 2 3

# The values inside {{ }} are variables
PORT={{ app_port }}
DEBUG={{ debug }}

Step 2: Define Variables (Inventory)INI

1 2 3 4 5

[dev]
devserver app_port=8080 debug=true

[prod]
prodserver app_port=9090 debug=false

Step 3: Use the Template ModuleYAML

1 2 3 4 5 6 7 8

---
- hosts: all
  tasks:
    - name: Generate configuration
      template:
        src: config.j2
        dest: /tmp/config.conf

The Output

The same template generates completely different files because Ansible provides different variable values for each server during execution.

Dev Output
PORT=8080
DEBUG=true
Prod Output
PORT=9090
DEBUG=false

# data-sources

Where do the values come from?

Jinja2 does not read values directly from the server. It relies entirely on variables passed to it by Ansible. These variables can come from:

Inventory files
group_vars and host_vars directories
vars: section inside a playbook
Extra variables passed via CLI (-e)
Ansible Facts

Ansible Facts in Templates

# Facts are system data automatically collected by Ansible

Hostname: {{ ansible_hostname }}

IP Address: {{ ansible_default_ipv4.address }}

OS: {{ ansible_distribution }}

# Example Output rendered on the server:

Hostname: prod-server

IP Address: 192.168.1.10

OS: Ubuntu

# syntax

Jinja2 Syntax & Logic

VariablesJINJA2

Employee Name: {{ empname }}

If ConditionsJINJA2

1 2 3 4 5

{% if environment == "production" %}
Debug=false
{% else %}
Debug=true
{% endif %}

For LoopsJINJA2

1 2 3 4

Users:
{% for user in users %}
- {{ user }}
{% endfor %}

Rendered Loop Output

Users:

- alice

- bob

- charlie

# comparison

Copy Module vs Template Module

Feature	Copy Module 📄	Template Module (Jinja2) ⚙️
Function	Copies the exact same static file to every server.	Generates a different, dynamic file for each server based on variables.
Source File	Usually a standard text file (`.conf`, `.txt`)	A Jinja2 template file (`.j2`)
Variables	Does not process variables inside the file.	Parses and replaces `{{ variables }}` and executes `{% logic %}`.
Code Example	`- copy: src: config.conf dest: /tmp/config.conf`	`- template: src: config.j2 dest: /tmp/config.conf`

# summary

Real-Time Usage & Interview Prep

real-world application

Common Use Cases

Jinja2 is heavily used in production environments to generate:

Application configuration files (Nginx, Apache)
Environment-specific properties (DB connections)
System configuration files
Custom shell scripts populated with server info

REMEMBER

Jinja2 does not automatically read values from a server. It strictly uses the variables supplied by Ansible during the playbook execution.