Ansible 模板完全指南：Jinja2 动态配置
Ansible 模板用 Jinja2 引擎在运行时渲染配置：变量插值、条件、循环、过滤器，同一份模板给不同环境/角色主机生成定制文件。本文从语法基础到部署策略与安全注意事项。
直接回答：Ansible 模板是带动态元素的配置文件——用 Jinja2 语法写变量（{{ }}）、条件（{% if %}）、循环（{% for %}），在控制端渲染后由 template 模块传送到目标机。解决配置管理的核心矛盾：整体结构统一、局部参数因环境/角色而异。
Jinja2 语法速览
# 变量与过滤器
listen {{ http_port | default(80) }};
# 条件
{% if env == "production" %}
worker_processes {{ ansible_processor_vcpus }};
{% else %}
worker_processes 2;
{% endif %}
# 循环：按组内主机生成 upstream
upstream backend {
{% for host in groups['appservers'] %}
server {{ hostvars[host]['ansible_host'] }}:{{ app_port }};
{% endfor %}
}
{{ }} 输出、{% %} 逻辑、| 过滤器（default/join/upper 等）。主机事实需先 gather_facts 或 setup，清单变量也必须存在；上面的 Nginx 指令分属不同上下文，是语法片段，不能整段直接当 nginx.conf。
部署与验证
- name: 渲染 Nginx 配置
ansible.builtin.template:
src: nginx.conf.j2
dest: /etc/nginx/nginx.conf
validate: '/usr/sbin/nginx -t -c %s' # 渲染后先验证再落位
backup: true
owner: root
group: root
mode: '0644'
notify: reload nginx
示例需提权并在 playbook 定义 reload nginx handler；src 必须是一份完整有效配置，不能直接使用前面的语法片段。含密钥时收紧 mode、设 no_log: true 与 diff: false。
validate 是关键防线——模板渲染出的配置先经程序自检（nginx -t、sshd -t），坏了不落盘；配 handler 通知，配置变化才重载服务。
语法检查通过后，还要验证实际请求。先在一小批主机上重载，检查关键接口的状态码和响应内容，确认正常后再扩大范围；保留旧配置以便回退。已有观测云 HTTP 拨测任务时，可在同一发布窗口核对响应断言与运行结果，检查配置是否改变了接口行为。
策略与安全
- 模板放 role 的
templates/目录，变量走 defaults/vars 分层 - 别把密钥写进模板——引用 Vault 加密变量；渲染结果仍为明文，必须限制文件权限与备份访问
- 复杂逻辑宁放 playbook 预处理成简单变量，别让模板长成程序
常见问题（FAQ）
Q：模板里 Jinja2 语法和配置文件自身语法冲突怎么办？
A：如 Nginx 的 {} 与 Jinja 不冲突，但 Helm/Prometheus 这类用 {{ }} 的配置要转义：{{ '{{' }} raw {{ '}}' }} 或 {% raw %} 块。
Q：渲染结果怎么预览？
A：非敏感配置可用 --check --diff；含密钥配置禁用 diff；或本地 ansible-playbook -c local 渲染到临时路径人工检查。
Q：模板和 copy/lineinfile 怎么分工？
A：静态文件用 copy；单点修改共享文件用 lineinfile；整文件归你管且需按主机/环境变化用 template——这是默认首选。
官方参考
本文依据官方文档整理，示例未在本文中进行运行验证。生产部署需按所用版本、权限和实际负载验证。
