# Playbook structure **URL:** \ **Category:** Ansible Project\ **Created:** [May 9, 2022, 8:06pm UTC](https://forum.ansible.com/t/playbook-structure/36607 "2022-05-09T20:06:59Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Marc\_Haber](https://avatars.discourse-cdn.com/v4/letter/m/a3d4f5/32.png) [@Marc\_Haber](https://forum.ansible.com/u/Marc_Haber)\ **Post date:** [May 9, 2022, 8:06pm UTC](https://forum.ansible.com/t/playbook-structure/36607/1 "2022-05-09T20:06:59Z")
Hi, after using ansible for quite a while, my project to manage my own servers has grown to a respectable size. I was a puppet user before, so I have a single big playbook containing everything. I have the feeling this is like holding ansible wrong, and I also have the feeling that I have my playbook structured wrong. Judging from the single "name" setting, I took the wrong turn in the very beginning. The playbook does what it is intended to do, however. Here is an excerpt from my playbook. ---
**Author:** ![Dick\_Visser](https://avatars.discourse-cdn.com/v4/letter/d/d9b06d/32.png) [@Dick\_Visser](https://forum.ansible.com/u/Dick_Visser)\ **Post date:** [May 10, 2022, 6:30am UTC](https://forum.ansible.com/t/playbook-structure/36607/2 "2022-05-10T06:30:13Z")
> Hi, > > after using ansible for quite a while, my project to manage my own > servers has grown to a respectable size. I was a puppet user before, so > I have a single big playbook containing everything. I have the feeling > this is like holding ansible wrong, and I also have the feeling that I > have my playbook structured wrong. Judging from the single "name" > setting, I took the wrong turn in the very beginning. The playbook does > what it is intended to do, however. > > Here is an excerpt from my playbook. > > --- > - name: apply common configuration >   hosts: all >   remote\_user: zgansible >   become: "yes" What is the reason for quoting this boolean? It is usually done to force it to be a string, but AFAIK this parameter requires a boolean. >   tasks: >   ⦙ - name: install ansible dependencies >   ⦙ ⦙ apt: >   ⦙ ⦙ ⦙ name: ['python3', 'python3-apt'] >   ⦙ ⦙ ⦙ state: present >   ⦙ - name: get package facts >   ⦙ ⦙ package\_facts: >   ⦙ ⦙ ⦙ manager: "auto" >   ⦙ ⦙ tags: always >   ⦙ - name: print facts >   ⦙ ⦙ debug: >   ⦙ ⦙ ⦙ var: ansible\_facts >   ⦙ ⦙ tags: [never, debug, printfacts] >   ⦙ - name: print package facts >   ⦙ ⦙ debug: >   ⦙ ⦙ ⦙ var: ansible\_facts.packages >   ⦙ ⦙ tags: [never, debug, printpackagefacts] >   ⦙ - include\_role: >   ⦙ ⦙ ⦙ name: clean-motd >   ⦙ ⦙ ⦙ apply: >   ⦙ ⦙ ⦙ ⦙ tags: >   ⦙ ⦙ ⦙ ⦙ ⦙ - clean-motd >   ⦙ ⦙ ⦙ ⦙ ⦙ - clean-all >   ⦙ ⦙ ⦙ ⦙ ⦙ - never >   ⦙ ⦙ tags: >   ⦙ ⦙ ⦙ - clean-motd >   ⦙ ⦙ ⦙ - clean-all >   ⦙ ⦙ ⦙ - never >   ⦙ - include\_role: >   ⦙ ⦙ ⦙ name: sysctl >   ⦙ ⦙ ⦙ apply: >   ⦙ ⦙ ⦙ ⦙ tags: >   ⦙ ⦙ ⦙ ⦙ ⦙ - sysctl >   ⦙ ⦙ tags: >   ⦙ ⦙ ⦙ - sysctl > (LOTS of other include\_role stanzas defining roles that are on all machines) > > - name: apply configuration for bind9 servers >   hosts: >   ⦙ - alemana >   ⦙ - cadencia >   ⦙ - gancho >   ⦙ - impetus >   ⦙ - lasso >   ⦙ - torres >   ⦙ - dns1 >   remote\_user: zgansible >   become: "yes" >   vars: >   ⦙ bind\_role: "{{ (bind|default({}))|combine(bind\_group|default({}), recursive=true, list\_merge='append') }}" >   tasks: >   ⦙ - include\_role: >   ⦙ ⦙ ⦙ name: bind9 >   ⦙ ⦙ ⦙ apply: >   ⦙ ⦙ ⦙ ⦙ tags: >   ⦙ ⦙ ⦙ ⦙ ⦙ - bind9 >   ⦙ ⦙ tags: >   ⦙ ⦙ ⦙ - bind9 > \> - name: apply configuration for DHCP servers >     hosts: >    ⦙ - chasse >    ⦙ - cadencia >    remote\_user: zgansible >    become: "yes" >    tasks: >    ⦙ - include\_role: >    ⦙ ⦙ ⦙ name: isc-dhcp-server >    ⦙ ⦙ ⦙ apply: >    ⦙ ⦙ ⦙ ⦙ tags: >    ⦙ ⦙ ⦙ ⦙ ⦙ - isc-dhcp-server >    ⦙ ⦙ tags: >    ⦙ ⦙ ⦙ - isc-dhcp-server > > Is this the way to do it? Any comments will be appreciated. I don't see anything totally wrong with the above approach. Perhaps try to avoid the inline lists but that's cosmetics. > In the other news, where would I correctly place (and activate) this handler: > > --- > - name: apt update >    command: "apt-get update" > > if I intend to notify this handler from any role that might use the apt > provider to install packages? What is the use case for this? If you want to make sure this is always run prior to any package task, then you should use the update\_cache parameters of the apt module: [https://docs.ansible.com/ansible/latest/collections/ansible/builtin/apt\_module.html#parameter-update\_cache](https://docs.ansible.com/ansible/latest/collections/ansible/builtin/apt_module.html#parameter-update_cache) Dick ---
**Author:** ![Marc\_Haber](https://avatars.discourse-cdn.com/v4/letter/m/a3d4f5/32.png) [@Marc\_Haber](https://forum.ansible.com/u/Marc_Haber)\ **Post date:** [May 12, 2022, 10:57am UTC](https://forum.ansible.com/t/playbook-structure/36607/3 "2022-05-12T10:57:28Z")
Hi Dirk, > \> after using ansible for quite a while, my project to manage my own > \> servers has grown to a respectable size. I was a puppet user before, so > \> I have a single big playbook containing everything. I have the feeling > \> this is like holding ansible wrong, and I also have the feeling that I > \> have my playbook structured wrong. Judging from the single "name" > \> setting, I took the wrong turn in the very beginning. The playbook does > \> what it is intended to do, however. > \> > \> Here is an excerpt from my playbook. > \> > \> --- > \> - name: apply common configuration > \> hosts: all > \> remote\_user: zgansible > \> become: "yes" > > What is the reason for quoting this boolean? It is usually done to force it > to be a string, but AFAIK this parameter requires a boolean. Historical reasons, fixed. I probably didnt know any better, and it's still a matter of try-and-err whether to find out whether ansible wants/insists on things being quoted or not. [snip] > I don't see anything totally wrong with the above approach. > Perhaps try to avoid the inline lists but that's cosmetics. How would I write them any better? > \> In the other news, where would I correctly place (and activate) this handler: > \> > \> --- > \> - name: apt update > \> command: "apt-get update" > \> > \> if I intend to notify this handler from any role that might use the apt > \> provider to install packages? > > What is the use case for this? > If you want to make sure this is always run prior to any package task, then > you should use the update\_cache parameters of the apt module: > > [https://docs.ansible.com/ansible/latest/collections/ansible/builtin/apt\_module.html#parameter-update\_cache](https://docs.ansible.com/ansible/latest/collections/ansible/builtin/apt_module.html#parameter-update_cache) updating the package lists after fiddling with things in /etc/apt, for example preparing a release upgrade or adding an external repository (docker \*cough\*). Doing an apt update right before any check whether any required package is already installed seems overkill, but I need to ponder about that. Greetings Marc ---
**Author:** ![racke](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/racke/32/4767_2.png) [@racke](https://forum.ansible.com/u/racke)\ **Post date:** [May 12, 2022, 1:08pm UTC](https://forum.ansible.com/t/playbook-structure/36607/4 "2022-05-12T13:08:18Z")
> Hi, > > after using ansible for quite a while, my project to manage my own > servers has grown to a respectable size. I was a puppet user before, so > I have a single big playbook containing everything. I have the feeling > this is like holding ansible wrong, and I also have the feeling that I > have my playbook structured wrong. Judging from the single "name" > setting, I took the wrong turn in the very beginning. The playbook does > what it is intended to do, however. My two cents: - host name / remote user should be in the inventory and not in the playbook - consider using import\_role instead of include\_role Regards         Racke ---
**Author:** ![racke](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/racke/32/4767_2.png) [@racke](https://forum.ansible.com/u/racke)\ **Post date:** [May 12, 2022, 1:19pm UTC](https://forum.ansible.com/t/playbook-structure/36607/5 "2022-05-12T13:19:54Z")
> Hi Dirk, > > > > after using ansible for quite a while, my project to manage my own > > > servers has grown to a respectable size. I was a puppet user before, so > > > I have a single big playbook containing everything. I have the feeling > > > this is like holding ansible wrong, and I also have the feeling that I > > > have my playbook structured wrong. Judging from the single "name" > > > setting, I took the wrong turn in the very beginning. The playbook does > > > what it is intended to do, however. > > > > > > Here is an excerpt from my playbook. > > > > > > --- > > > - name: apply common configuration > > >    hosts: all > > >    remote\_user: zgansible > > >    become: "yes" > > > > What is the reason for quoting this boolean? It is usually done to force it > > to be a string, but AFAIK this parameter requires a boolean. > > Historical reasons, fixed. I probably didnt know any better, and it's > still a matter of try-and-err whether to find out whether ansible > wants/insists on things being quoted or not. > > [snip] > > > I don't see anything totally wrong with the above approach. > > Perhaps try to avoid the inline lists but that's cosmetics. > > How would I write them any better? > > > > In the other news, where would I correctly place (and activate) this handler: > > > > > > --- > > > - name: apt update > > >     command: "apt-get update" > > > > > > if I intend to notify this handler from any role that might use the apt > > > provider to install packages? > > > > What is the use case for this? > > If you want to make sure this is always run prior to any package task, then > > you should use the update\_cache parameters of the apt module: > > > > [https://docs.ansible.com/ansible/latest/collections/ansible/builtin/apt\_module.html#parameter-update\_cache](https://docs.ansible.com/ansible/latest/collections/ansible/builtin/apt_module.html#parameter-update_cache) > > updating the package lists after fiddling with things in /etc/apt, for > example preparing a release upgrade or adding an external repository > (docker \*cough\*). Doing an apt update right before any check whether any > required package is already installed seems overkill, but I need to > ponder about that. You can add/modify/delete the external repo with Ansible and run the apt update only when the repo changed. The equivalent for "apt-get update" is:      - name: Update APT cache        apt:          update\_cache: yes Regards         Racke ---
**Author:** ![dnmvisser](https://avatars.discourse-cdn.com/v4/letter/d/8e8cbc/32.png) [@dnmvisser](https://forum.ansible.com/u/dnmvisser)\ **Post date:** [May 12, 2022, 8:21pm UTC](https://forum.ansible.com/t/playbook-structure/36607/6 "2022-05-12T20:21:07Z")
stylistic nit pick > > tasks: > > ⦙ - name: install ansible dependencies > > ⦙ ⦙ apt: > > ⦙ ⦙ ⦙ name: ['python3', 'python3-apt'] > > ⦙ ⦙ ⦙ state: present    - name: install ansible dependencies      apt:      name:       - python3       - python3-apt     state: present ---
**Author:** ![Marc\_Haber](https://avatars.discourse-cdn.com/v4/letter/m/a3d4f5/32.png) [@Marc\_Haber](https://forum.ansible.com/u/Marc_Haber)\ **Post date:** [May 13, 2022, 10:24am UTC](https://forum.ansible.com/t/playbook-structure/36607/7 "2022-05-13T10:24:30Z")
Fair enough, thanks. Those hints are the most important. Greetings Marc ---
**Author:** ![Nico\_Kadel-Garcia](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/nico_kadel-garcia/32/9998_2.png) [@Nico\_Kadel-Garcia](https://forum.ansible.com/u/Nico_Kadel-Garcia)\ **Post date:** [May 13, 2022, 11:04am UTC](https://forum.ansible.com/t/playbook-structure/36607/8 "2022-05-13T11:04:08Z")
It's gotten a bit strange out there. I'd encourage you to focus your installation on "ansible-core", which contains the relevant python modules and executable scripts, and entirely ignore the upstream "ansible" package unless you have a compelling need for 100 third party modules in a semi-organized and monolithic bundle taking up roughly half a Gig of local disk space. It's not really useful for most ansible server setups.