I have an ansible playbook add_dns_record.yml that register the A record and relative PTR of an host to our MS DNS server.

- hosts: my_ad_dns
  remote_user: "{{ lookup('env', 'USER') }}@MYDOMAIN.COM"
  gather_facts: false
  - name: Create A record
      computer_name: "{{ inventory_hostname }}"
      name: "{{ dns_a_name }}"
      type: "A"
      value: "{{ dns_ip_address }}"
      zone: "MYDOMAIN.COM"
      state: present

  - name: Create PTR

I have another playbook debian_base.yml used to prepare debian servers:

- hosts: debian

    - name: install python
      raw: test -e /usr/bin/python || (apt -y update && apt install -y python-minimal)

    - name: Set hostname
        name: "{{ inventory_hostname }}"

    - name: Update repositories cache and install pre-requirements
        name: "{{ packages}}"
        update_cache: yes
        - sudo
        - apt-transport-https
        - cloud-guest-utils
        - open-vm-tools
        - screen
        - dirmngr
        - openjdk-8-jdk-headless
        - dos2unix

I want that every debian server deployed using the playbook debian_base.yml get registered on the MS DNS.

I had a look to import_playbook but it doesn't accept variables.

What are the best practices to achieve that?

2 Answers 2


This looks like you are trying to solve a problem (how express a desired state using appropriate OS-specific strategies), but selecting the "wrong" approach.

I would suggest that instead of maintaining separate playbooks (one for Windows, one for Debian, etc), you should write an OS-independent role. The role will use facts from the target machines to apply the relevant configuration. This can be done in a few ways :

  1. Set OS-specific variables and include them in the tasks using a include_vars: "{{ ansible_os_family }}.yml" which will pick up a Debian.yml set of vars e.g.. You could then write when conditions on tasks to execute OS-specific tasks
  2. Write OS-specific tasks to be included in the tasks/main.yml e.g.
# tasks/main.yml
- import_tasks: "{{ ansible_os_family }}.yml"

This will afford you some benefits:

  1. You will be able to test the role independently for different scenarios (using molecule e.g.
  2. You will be able to maintain the configuration (vars, tasks, etc) independently in separate files for respective OS's.
  3. You won't have to maintain two separate playbooks
  4. Your role will be easier to re-use

See writing re-usable playbooks on the Ansible documentation.


the best way I think is to create a var yml file and include it in your ansible-books:

    - name: Include vars of stuff.yaml into the 'stuff' variable (2.2).
        file: stuff.yaml
        name: stuff

see include_vars_module

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.