multiple playbooks or one playbook per function?

By playbook per function I mean something like a web.yml
playbook which defines how all the webservers are put together. Of
course we could then define variables associated with host groups and
hosts themselves to take care of the local idiosyncrasies that make
them unique (location, fw rules it it has more than one IP, which repo
it should be sucking data from, etc).

Now what about network thingies such as routers, switches, traffic
monitoring appliances, and whatnots? Should they all be inside, say,
network.yml and then do the same as above? Maybe even having different

- hosts:
    - switches
  vars:
  roles:

- hosts:
    - scan
  vars:
  roles:

- hosts:
    - routers
  vars:
  roles:

within the same playbook. After all I can run ansible specifying I
want this playbook to be only applied to that host or group of hosts.
Or just have one playbook for each of these groups. I see pros and
cons on each of them but am curious about what is The Proper Way <tm>.

Thoughts?

Such flexibility is available at the project level provided by
ansible-runner. Take a look at "Runner Input Directory Hierarchy"
https://ansible-runner.readthedocs.io/en/latest/intro.html#inputdir

Keep the roles and playbooks modular and as simple as possible. This will
make both security screening and maintenance easier. Put the elements (roles,
playbooks, inventory, ...) together by linking the directories and files into
a projects.

To deliver and integrate, such projects can be encapsulated in Python. See
"Using Runner as a Python Module Interface to Ansible"
https://ansible-runner.readthedocs.io/en/latest/python_interface.html

Cheers.

  -vlado

I don’t think there’s a proper way, ultimately its whatever works for you.
I do actually have 1 playbook per cluster type, but I have quite ‘tall’ software stacks (lots of steps to configure each cluster) and then I use external tools such as jenkins or gnu parallels to run multiple playbooks simultaneously (which I can do as typically I don’t ‘double-up’ and have hosts function as more than one type of cluster member).

I think I probably wouldn’t do that if I had simpler clusters which didn’t need so many tasks applied to them to ensure they are properly configured.
If you often need to build all your cluster types at once then maybe having multiple playbooks would work for you.
I’d definitely recommend pushing down any complexity into roles (and even into multiple tasks files within roles) as this lets you re-use roles in your playbooks.
Hope this helps,
Jon