ansible-playbook: how to dynamically, conditionally set a large deployment environment (variable space) in a playbook?

Question

I am using an ansible playbook to deploy a php web application in aws. The deployment is repeated many times, with a different environment, for each customer. The different scenarios range from single server deployments to full deployments using elastic load balancers, and use varying code repositories based on product type.

To allow a human to deploy this app repetitively and adjust the deployment type and environment, I am running ansible-playbook with --extra-vars "@deployment_vars_file.yml" and copying and filling this vars file on a per-deployment basis, instead of putting the variables in group_vars/all.yml, so that I can keep a copy of the variable space I set for each deployment, and avoid overwriting (or .template suffixing) group_vars/all.yml and multiple roles' vars/main.yml files, for each deployment. I rarely rely on variable precedence, since the role and play variables inherit (are constructed out of) my deployment vars file variables.

My roles are already run conditionally at the play level, and I have a handle on how to run tasks/blocks/roles/plays conditionally, depending on the environment type that is defined in the --extra-vars file.

I need to define many other variables, dynamically (during the playbook run), conditionally (based on the values of variables in my --extra-vars file), with as little work as possible (i.e., in one place), at the beginning of the playbook. My roles' vars/main.yml files, as well as vars: play keywords, will inherit these other variables, (in addition to directly inheriting some of the --extra-vars variables). The values of these other variables need to persist at the playbook level, not just within each play. I don't want to have to do this in multiple locations with the same lines of code.

How can I do this, and what is the most simple way?

Answer 1

Yes, an input host file for ansible looks like https://pastebin.com/Vtfw5FtV The upper part node stuff is generated using terraform, we can dynamically up/down scale the number of nodes with terraform and terraform outputs the yaml used for the hosts part of the file. The tenant-specifiek yml vars (about 150 additional lines of tenant specific config yml) are kept in a separate git location and a jenkins step/python concatenates them together and pushes them to the host directory location for each tenant and runs individual roles (hotfix) or all of 'em (full deploy) or perhaps just stop/start. The Jenkins job is pretty much a control screen with a lot of dropdowns, radio buttons and selectors. We can select how many nodes we want for a single service, which build to grab from nexus, do a full deploy, a single service hotfix or just a configuration hotfix. All this is selectable/executable per environment, per tenant and per individual module/service. The Jenkins screen is dynamically build from the host (targets) & roles (actions) directory.

Again, we're most likely abusing Ansible "best practices" a fair bit but for us this approach has been working remarkably well for last >3 years in terms of overall manageability and gives us maximum flexibility of the whole CI/CD pipeline.