// learn · linux · rhce · 10 min

Ansible templates.

One Jinja2 `.j2` file, a tailored config on every host. The template module renders the file with each machine's own variables and facts before it lands — so a single `nginx.conf.j2` becomes a correct, host-specific config everywhere.

Ansible templates animated tutorial. The ansible.builtin.template module renders a Jinja2 .j2 file with each host's variables and facts and copies the result, unlike copy which ships bytes verbatim. Covers expression tags with double braces, control structures for and if with statement tags, whitespace trimming, filters including default, upper, lower, join, and password_hash, the ansible_managed header, and reading hostvars and groups so one template produces a per-host config. RHCE EX294 ready.
// ansible · templates (jinja2)

One `.j2` file, a tailored config on every host. Watch the same template render into different concrete files for servera and serverb as we spotlight the template module, expressions, control structures, filters, and per-host facts.

// before you start
you should know
  • ·Ansible playbook basics (tasks, modules, vars)
  • ·Comfortable with the copy module
  • ·Know what facts and group/host vars are
by the end you'll

Render Jinja2 templates per host with the template module: insert values with {{ }}, branch and loop with {% %}, transform with filters, and use facts so one .j2 produces a correct file on every machine.

pace: 10 minutes

ansible — step 1 / 5 · template
🧬templates/nginx.conf.j2jinja2 source
1# {{ ansible_managed }}
2server_name {{ inventory_hostname }};
3listen {{ http_port | default(80) }};
4worker_processes {{ ansible_facts['processor_vcpus'] }};
template module→renders per host
🖥️serverarendered
1# Ansible managed
2server_name servera;
3listen 80;
4worker_processes 2;
🖥️serverbrendered
1# Ansible managed
2server_name serverb;
3listen 8080;
4worker_processes 8;

The template module

`ansible.builtin.template` renders a Jinja2 `.j2` file on the control node and copies the RESULT to dest — unlike `copy`, which ships the bytes verbatim. You still set owner, group, and mode just like copy, and you can add `validate:` to run a syntax check on the rendered file before it replaces the live one. By convention the source `.j2` files live in a `templates/` directory beside your playbook, so Ansible finds them with a bare filename.

$ansible.builtin.template:\n src: httpd.conf.j2\n dest: /etc/httpd/conf/httpd.conf\n mode: '0644'
$validate: "httpd -t -f %s"
$templates/httpd.conf.j2
// key insight

`copy` ships bytes; `template` ships a Jinja2 file that is RENDERED with each host's variables and facts first. That one difference means a single `nginx.conf.j2` becomes a correct, host-specific config on every machine — no per-host files to maintain.

// exam-ready · template module & jinja2
$ansible.builtin.template src=X.j2 dest=Y
$mode / owner / group
$validate: "cmd %s"
$templates/ dir
${{ var }}
${% if %}…{% endif %}
${% for x in list %}…{% endfor %}
${%- … -%}
$| default(X)
$| upper / | lower
$| join(',')
$| password_hash('sha512')
${{ ansible_managed }}
$hostvars[h] / groups['grp']
// check yourself
4 quick questions
Q1

When should you use the `template` module instead of `copy`?

Q2

What's the difference between `{{ }}` and `{% %}` in a Jinja2 template?

Q3

A variable might be undefined and you want a sensible fallback in the rendered file. Which filter?

Q4

How can one template file produce a different nginx config on every web server?

These aren't graded — they're just for active recall, which is what actually makes the lesson stick.

🔔
// next: react to change

Ansible handlers & notifications

A template only matters if the service picks up the change. Use `notify` and handlers to restart a service only when its config actually changed — never on an unchanged run.

open →

Read this lesson as text5 chapters · quiz answers

  1. 01The template module

    ansible.builtin.template renders a Jinja2 .j2 file on the control node and copies the RESULT to dest — unlike copy, which ships the bytes verbatim. You still set owner, group, and mode just like copy, and you can add validate: to run a syntax check on the rendered file before it replaces the live one. By convention the source .j2 files live in a templates/ directory beside your playbook, so Ansible finds them with a bare filename.

    • $ ansible.builtin.template:\n src: httpd.conf.j2\n dest: /etc/httpd/conf/httpd.conf\n mode: '0644' — render → copy result to dest
    • $ validate: "httpd -t -f %s" — check before replacing live file
    • $ templates/httpd.conf.j2 — convention: .j2 in templates/ dir

  2. 02Jinja2 expressions — {{ }}

    A {{ }} tag inserts a value into the output: a variable, a fact, arithmetic, or a dict/list lookup. This is the exact same templating engine you already use inside playbooks — nothing new to learn. Whatever the expression evaluates to for THIS host gets dropped into the rendered file at that spot.

    • $ ServerName {{ inventory_hostname }} — a magic var
    • $ Listen {{ http_port }} — a play/group var
    • $ worker_processes {{ ansible_facts['processor_vcpus'] }}; — a gathered fact

  3. 03Control structures — {% %}

    Statement tags use {% %} and produce no direct output — they drive logic. {% for x in list %}…{% endfor %} repeats a block once per item, and {% if cond %}…{% endif %} (with optional {% else %}) emits a block conditionally. Remember the split: {{ }} OUTPUTS a value, {% %} is CONTROL FLOW. Add a dash to trim surrounding whitespace — {%- … -%} — so loops don't leave blank lines in the rendered file.

    • $ {% for h in groups['webservers'] %}\nserver {{ h }};\n{% endfor %} — loop emits one line per host
    • $ {% if tls_enabled %}…{% else %}…{% endif %} — conditional block
    • $ {%- for x in xs -%}…{%- endfor -%} — trim whitespace around tags

  4. 04Filters — transform values

    Pipe a value through a filter to transform it before it lands in the output: | default(X) supplies a fallback when undefined, | upper/| lower change case, | join(',') flattens a list, | to_nice_yaml pretty-prints, and | password_hash('sha512') produces a crypt hash. Filters chain left-to-right, so {{ name | lower | trim }} applies each in turn. They're the everyday glue that turns raw vars into config-ready strings.

    • $ {{ name | default('localhost') }} — fallback for undefined
    • $ {{ admins | join(', ') }} — list → comma string
    • $ {{ pw | password_hash('sha512') }} — crypt-style hash

  5. 05Facts make each host different

    Because a template is rendered with THIS host's own facts and vars, one .j2 file becomes a tailored config on every machine. A load-balancer template can list every web server by walking groups['webservers'] and reading each one's IP from hostvars. Always drop {{ ansible_managed }} at the top as a header so humans know the file is generated and shouldn't be hand-edited.

    • $ {% for h in groups['webservers'] %}\nserver {{ hostvars[h]['ansible_facts']['default_ipv4']['address'] }};\n{% endfor %} — walk the group, read each IP
    • $ # {{ ansible_managed }} — do-not-edit header
    • $ {{ ansible_facts['fqdn'] }} — this host's own fact

Quiz — answers

When should you use the template module instead of copy?
→When the file contains Jinja2 variables or logic that must be rendered per host — copy ships the file unchanged, byte for byte.template renders the .j2 through Jinja2 with the target host's vars and facts, then copies the RESULT. copy ships the bytes verbatim with no substitution. Both can set owner/group/mode.
What's the difference between {{ }} and {% %} in a Jinja2 template?
→{{ }} outputs the value of an expression; {% %} is a statement / control structure (for, if) that produces no direct output.Expression tags {{ }} emit a value into the file. Statement tags {% %} drive control flow (loops, conditionals) and render nothing themselves.
A variable might be undefined and you want a sensible fallback in the rendered file. Which filter?
→| default(value){{ myvar | default('localhost') }} substitutes the given value whenever myvar is undefined, so the template still renders cleanly.
How can one template file produce a different nginx config on every web server?
→It's rendered with each host's own facts and vars (and can read hostvars/groups), so the output differs per host.Templating runs once per target with that host's facts/vars in scope, and it can reach across the fleet via hostvars and groups — so a single .j2 yields a host-specific file everywhere.
// more in systems

keep going — these pair well with what you just learned.

see all systems →
🛰️

Ansible control node & inventory

Ansible is agentless — one control node pushes work to a fleet over SSH. Install ansible-core, write an inventory with groups, ping the fleet, and fire ad-hoc commands. RHCE-ready.

10 min · interactiveopen →
📜

Ansible playbooks & YAML

Plays, tasks, and idempotency. Watch a playbook run task-by-task — ok, changed, skipped — then run it again and watch everything go green with 0 changed. RHCE-ready.

12 min · interactiveopen →
🧩

Ansible core modules

file, user, copy, dnf, service — the modules that do the real work. Declare the desired state and let Ansible converge to it, idempotently. RHCE-ready.

10 min · interactiveopen →

See also

back to RHCSA / RHCE trackall lessons