Cuando Ansible despliega una aplicación en tres ambientes distintos — desarrollo, staging, producción — y cada uno necesita una configuración diferente, no genera tres archivos a mano. Usa un template y lo renderiza con los datos de cada ambiente.
Ese motor de templates es Jinja2.
Qué es Jinja2
Jinja2 es una librería de Python que toma un archivo de texto con marcadores y lo convierte en el archivo final reemplazando esos marcadores con datos reales. El formato de salida puede ser cualquier cosa: HTML, YAML, JSON, archivos de configuración de Nginx, scripts de shell — lo que sea texto.
El concepto es simple: el template define la estructura, los datos definen el contenido.
from jinja2 import Template
template = Template("Hola, {{ nombre }}. Tu entorno es {{ entorno }}.")
resultado = template.render(nombre="Elias", entorno="producción")
print(resultado)
# Hola, Elias. Tu entorno es producción.
La sintaxis tiene tres delimitadores: {{ }} para variables, {% %} para lógica de control, y {# #} para comentarios. Todo lo demás pasa sin modificación al archivo de salida.
Lógica dentro del template
Jinja2 no es solo sustitución de variables. Soporta condiciones y loops directamente en el template.
{% if entorno == "produccion" %}
DEBUG = False
LOG_LEVEL = WARNING
{% else %}
DEBUG = True
LOG_LEVEL = DEBUG
{% endif %}
SERVIDORES_PERMITIDOS = [
{% for servidor in servidores %}
"{{ servidor }}",
{% endfor %}
]
Un solo template genera configuraciones distintas dependiendo de los datos que recibe. Sin duplicación, sin archivos por ambiente mantenidos por separado.
Por qué importa en DevOps
Ansible usa Jinja2 nativo. Cada archivo de configuración que Ansible despliega puede ser un template Jinja2 — las variables se pasan desde el inventario o los playbooks, y el archivo final que llega al servidor ya tiene los valores correctos para ese host específico.
# playbook de Ansible
- name: Configurar nginx
template:
src: nginx.conf.j2
dest: /etc/nginx/nginx.conf
vars:
puerto: 8080
workers: 4
# nginx.conf.j2
worker_processes {{ workers }};
server {
listen {{ puerto }};
server_name {{ ansible_hostname }};
}
El mismo template se despliega en diez servidores con el hostname correcto de cada uno. Sin edición manual.
Este patrón — template + datos = archivo final — es lo que hace que IaC pueda manejar variabilidad entre ambientes sin duplicar código. La infraestructura cambia, el template no.
Más allá de Ansible
Jinja2 aparece en más lugares de los que parecería:
Flask y Django lo usan para renderizar HTML del lado del servidor. Las páginas con datos dinámicos son templates Jinja2 que el framework renderiza con los datos del request.
Cookiecutter, la herramienta para generar proyectos desde templates, usa Jinja2 para sustituir el nombre del proyecto, el autor, y la configuración inicial en todos los archivos del template.
Helm, el package manager de Kubernetes, usa una sintaxis basada en Go templates que comparte la misma lógica conceptual con Jinja2 — templates de manifiestos YAML con variables por entorno.
El patrón es consistente en todos los casos: un archivo con marcadores, datos que lo completan, un motor que los une.
Lo mínimo para arrancar
Tres cosas para entender Jinja2:
{{ variable }} — inserta el valor de una variable.
{% if %} / {% for %} — lógica de control dentro del template.
| filtros — transformaciones aplicadas a una variable antes de insertarla.
{{ nombre | upper }} {# ELIAS #}
{{ lista | join(", ") }} {# a, b, c #}
{{ numero | default(0) }} {# 0 si numero es None #}
Los filtros son lo que hace a Jinja2 más expresivo que un simple find-and-replace. Podés formatear fechas, convertir tipos, aplicar transformaciones de texto — todo dentro del template, sin lógica extra en el código que lo renderiza.
Si trabajás con Ansible, ya estás usando Jinja2 aunque no lo sepas. Entender la sintaxis explícita hace que los playbooks más complejos dejen de ser magia.