Join Log in
Score:0
avatar Server

File of tasks, with shared directives

co flag
bignose

How can I set directives shared between all tasks in the file, in an Ansible playbook fragment file that only contains tasks?

# ansible/inventory/roles/os_packages/tasks/main.yaml

- name: "APT: Update available packages from Debian repositories"
  gather_facts: false
  become: true
  become_user: root
  apt:
    update_cache: true
- name: "APT: Install required packages"
  gather_facts: false
  become: true
  become_user: root
  apt:
    name:
      - foo
      - bar

Those repeated directives — gather_facts, become, etc. — should be stated one time in that file. But where, since there is (currently?) no file representing the role or play?

# ansible/inventory/roles/os_packages/tasks/main.yaml

# This doesn't work because Ansible is expecting only tasks.
gather_facts: false
become: true
become_user: root

- name: "APT: Update available packages from Debian repositories"
  apt:
    update_cache: true
- name: "APT: Install required packages"
  apt:
    name:
      - foo
      - bar

The file needs to consist only of a sequence of tasks; the “role” level or “play” level don't appear to have an appropriate place in this recommended directory structure.

If the entire playbook was in one file, each play would have its own separate name and I'd set the directives on the play. But these tasks files are being gathered and compiled, and there's no place where the play exists for me to write those directives.

Where should the directives that apply to all tasks in a role get defined?

73
3 + 0
Score:0
Mikael H avatar Server
br flag
Mikael H

My typical directory structure:

├── deploy-something.yml
├── README.md
├── inventories
│   ├── prod
│   │   ├── group_vars
│   │   │   └── all
│   │   │       ├── vars.yml
│   │   │       └── vault.yml
│   │   ├── host_vars
│   │   │   ├── host1.yml
│   │   │   ├── host2.yml
│   │   │   └── localhost
│   │   │       ├── vars.yml
│   │   │       └── vault
│   │   └── inventory.yml
│   ...
└── roles
    ├── role1
    │   ├── ...
    ...

In this case, I put such directives in the top-level play deploy-something.yml:

- hosts: all
  remote_user: ansible
  become: yes
  become_method: sudo
  any_errors_fatal: true
  serial: true
  order: reverse_inventory
  roles:
  - role1
  - role2
0 + 1
co flag
bignose
“I put such directives in the top-level” — if I understand your example, that file represents the entire *playbook*. I'm attempting to apply these directives to an individual play or role; when the play or the role is represented by directory structure.
0
Reply
Score:0
flowerysong avatar Server
th flag
flowerysong

gather_facts is not meaningful (or possible) to set for anything other than a play, because it only affects the play-level decision of whether to gather facts.

become and become_user are valid block- or task-level keywords, so you can use a block to apply them to a list of tasks (within a role or otherwise):

- become: true
  become_user: root
  block:
    - name: "APT: Update available packages from Debian repositories"
      apt:
        update_cache: true
    - name: "APT: Install required packages"
      apt:
        name:
          - foo
          - bar

Many keywords can also be applied when calling roles:

- hosts: all
  roles:
    - name: foo
      become: true
  tasks:
    - import_role:
        name: bar
      become: true

    - include_role:
        name: baz
        apply:
          become: true
0 + 0
jan avatar
ar flag
jan
Are you sure that `include_role` can become be applied to? Also see my question regarding this not working: https://stackoverflow.com/questions/74853083/how-do-i-use-a-ansible-galaxy-role-in-a-task-that-requires-root-privileges
0
Reply
Score:-1
avatar Server
br flag
Vladimir Botka

Q: "Where should the directives that apply to all tasks in a role get defined?"

A: Short answer is: Outside a role.

Where exactly you should put the keywords depends on how you use the role. There are more options

  • roles:
  • import_role:
  • include_role:

It's out of scope to explain all details here. Generally, put such keywords on the (indentation) level of a role. In the case of include_role you can also apply keywords. Be aware that not all keywords can be applied everywhere. See Playbook Keywords that apply to roles. For example, the keyword gather_facts can be applied to a playbook only. One of the options on how to solve your problem might be the structure of the play below

- hosts: all
  gather_facts: false
  roles:
    - role: os_packages
      become: true
      become_user: root

Q: "How to do that (apply such keywords on the level of a role), when there is no config file (only a role directory) representing the role?"

A: If there is only the role directory, representing the role, you can apply keywords to the blocks and tasks inside the role only. You can't apply keywords to a role inside this role. There is no such thing as a config file for a role.

In the previous answer, by level I mean the indentation level, for example in the code above, gather_facts apply to the play while both become and become_user apply to the role.

0 + 2
co flag
bignose
“Apply such keywords on the level of a role” — yes, that's exactly what the question is asking: How to do that, when there is no config file (only a role directory) representing the role?
0
Reply
br flag
Vladimir Botka
You're probably looking for something that does not exist.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.