You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

Ansible跨Playbook共享pfSense备份配置文件名变量求助

Persisting Ansible Variables for pfSense Backup/Restore Workflows

Hey there! I totally get where you're coming from—when you're new to Ansible, variable persistence across separate playbooks can feel tricky. Let's fix this issue where your conf variable disappears after the backup playbook finishes, and get your backup/restore workflow working independently like you want.

Why Your Current set_fact Approach Isn't Sticking

First, let's clarify: even with cacheable: true, Ansible's default fact cache is in-memory only. That means when your backup playbook finishes running, all those cached variables get cleared. The only way cacheable would persist across playbooks is if you've configured a persistent fact cache (like Redis or a file-based cache), but since you want a static file you can reference anytime, we'll focus on writing those variables to a local YAML file instead.

Step 1: Export Backup Filenames to a Static YAML File in Your pfbackup Role

After you've set the conf variable for each pfSense node, add a task that collects all those filenames and writes them to a manifest file on your control machine. This file will act as a persistent record of the latest backup files for each node.

Add this task to your pfbackup role (run it once from your control machine):

- name: Create persistent backup manifest file
  copy:
    content: |
      pfsense_backups:
      {% for host in groups['pfSense_nodes'] %}  # Replace with your actual inventory group name
        - hostname: {{ host }}
          config_file: {{ hostvars[host].conf | default('') }}
      {% endfor %}
    dest: "{{ playbook_dir }}/pfsense_backup_manifest.yml"
  delegate_to: localhost
  run_once: true
  • This uses a Jinja2 loop to iterate over all your pfSense nodes, pulling the conf variable you set earlier.
  • The file gets saved to your playbook directory (you can adjust the path to wherever makes sense for your project).

Step 2: Import the Manifest File in Your pfsrestore Role

When you're ready to run the restore playbook, load the manifest file as variables so you can reference the latest backup paths for each node.

Add this task to your pfsrestore role:

- name: Load backup manifest file
  include_vars:
    file: "{{ playbook_dir }}/pfsense_backup_manifest.yml"
    name: backup_info

- name: Restore latest config to each pfSense node
  copy:
    src: "{{ item.config_file }}"
    dest: /tmp/config.xml  # Adjust to pfSense's expected restore path
  loop: "{{ backup_info.pfsense_backups }}"
  delegate_to: "{{ item.hostname }}"
  when: item.config_file != ''  # Skip if no backup file was recorded

# Add your restore and reboot tasks here (e.g., using pfSense's API or CLI to apply the config)
  • include_vars loads the YAML file into a variable named backup_info, which you can then loop through to target each node with its specific backup file.

Bonus: Validate the Manifest File

If you want to double-check the manifest was created correctly, you can add a debug task in either playbook:

- name: Show backup manifest contents
  debug:
    var: backup_info.pfsense_backups
  delegate_to: localhost

Why This Works

By writing the variables to a static file, you're decoupling the backup and restore playbooks—you only need to run the backup once, and the manifest file will hold the latest backup paths until you run the backup again (which will overwrite the manifest with fresh paths). This keeps your restore functionality independent, just like you wanted.

内容的提问来源于stack exchange,提问作者TheAdvanced

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.05.07 19:02:33