Dumb question re orchestrating the starting and stopping of tiered services with ordering dependencies:
Imagine tier A depends on tier B. To bring up the app, start B then A. To bring it down, stop A then B. I can’t figure out whether it’s possible to represent these relationships using roles without having to basically duplicate things so there is an A-stop role, a A-start role, a B-stop role, and a B-start role. Have gotten close to figuring it out using start/stop tags, but can’t model to opposite ordering dependencies between start and stop.
Anyone else come up with an efficient reusable way to model this use case?
I don't know if this helps, but I usually use roles for configuration
management and use standalone playbooks for orchestration stuff. I've
just found it easier to have more control if I centralize certain
aspects (like say an application upgrade) in a single playbook instead
of spread around in different roles. But roles are super useful for
configuration management.
Just my 2 pence...
Let me try to better illustrate my question with a more concrete example. Imagine an app Foo that has two tiers: Apache and MySQL. Each tier is a role with start and stop tasks. These tasks are tagged appropriately. Foo lists Apache and MySQL as its contained roles.
Starting the app is as simple as “ansible-playbook Foo.yml --tags=start”. Stopping it is a matter of “ansible-playbook Foo.yml --tags=stop”.
The interesting part comes in because to start Foo, MySQL needs to start first. To shut down Foo, Apache needs to stop first. Without a home-grown hack, there doesn’t appear to be any way to conditionally control the order of role specifications. The hack is to specify the roles twice, in reverse order, with an associated variable that the leaf-level start/stop tasks use to decide whether to actually fire or not (yes, it’s ugly :-).
This doesn’t seem like a weird use case to me, so I’m hoping there’s a more elegant solution that doesn’t involve separate roles/playbooks for every action type (start/stop/install/etc.).
Hi Jeff,
I can only agree with Michael here - playbooks describe ordering of operations for a specific operational purpose and as far as I know role dependencies will not get you there in the scenario you describe.
The way I usually do this is to think of splitting my roles into two. You generally need two paths through your collections of tasks. The following broad groups can usually be combined:
- install / start / simple reconfiguration
- stop / remove
If you’re using roles currently as a “this is what should be present in my working application” then you’ve currently got the first one sorted.
For example, I have a global playbook that describes the current state of my entire system that I want to enforce. I use that for the first purpose and it works very well.
I have specific playbooks for removals or stopping particular apps (with dependencies) or more complicated reconfigurations or upgrades.
You may even want to have roles called “remove_foo” or so on but its generally easier to have this in a dedicated playbook unless its something that you’re doing often or that can be easily parameterised between plays (eg remove_app name=foo, remove_app name=bar).
Hope this helps.
Cheers,
Andrew