Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "best practices" example of separate staging/production inventories #290

Open
alexqfredrickson opened this issue Dec 16, 2020 · 3 comments

Comments

@alexqfredrickson
Copy link

Per the Ansible Tips and tricks documentation:

Separate production and staging inventory

You can keep your production environment separate from development, test, and staging environments by using separate inventory files or directories for each environment. This way you pick with -i what you are targeting. Keeping all your environments in one file can lead to surprises!

There aren't any examples of this in the documentation. I couldn't find any here either.

It sounds like a good idea to separate hosts into groups like development, staging, production (etc.) - but I can't figure out how to run a playbook against development:staging on some occasions, and production on others (at least not without copy/pasting roles all over a project).

@atc0005
Copy link
Contributor

atc0005 commented Dec 16, 2020

I can't speak to best practices, but we're using a structure like this:

./inventories/prod/hosts
./inventories/prod/group_vars/
./inventories/prod/host_vars/
./inventories/dev/hosts
./inventories/dev/group_vars/
./inventories/dev/host_vars/
./ansible.cfg

I'm oversimplifying a bit, but that overall structure allows us to target just the collection of systems that we want with the host or groups-specific settings intended for the collection.

@alexqfredrickson
Copy link
Author

alexqfredrickson commented Dec 16, 2020

This is kind of what the documentation is suggesting as a best practice - which makes sense, but it can get complicated.

For example: pretend your servers follow AWS Tagging best practices. Your server names might encapsulate multiple dimensions of categories. In their example of phlpwcspweb3: phl represents the data center locale (Philadelphia), p represents the stack type (production), w represents a "tier" (web), csp represents the general application environment (Customer Service Portal), web3 is a unique ID.

Then assume you want to run playbooks against production Customer Service Portal-related hosts in the Philadelphia data center. If we create inventories for specific combinations of categories (like ./inventories/phl_prod_csp/hosts), it seems like this would be difficult to maintain. If we create only very general inventories (like ./inventories/prod/hosts), then it's not clear to me how I would filter down on "Philadelphia CSP" hosts. I don't know if our hosts can reference hosts/groups in other inventories, and specifying specific hosts at runtime would seem to defeat the purpose of host groups.

Maybe despite all of this, creating staging/prod (etc.) inventories is still the best practice - but it would still be helpful to see some examples. My issue is that the tips/tricks documentation is leaving it up to interpretation.

@atc0005
Copy link
Contributor

atc0005 commented Dec 16, 2020

You can reference several inventories (repeat -i option) and can limit the scope to specific host groups. I don't know that I've tried mixing inventories and host groups, but I wouldn't be surprised if it's possible.

Depending on the complexity of the environment, using dynamic inventories may be preferable over trying to create complex inventory structures. I've previously read about how to create custom dynamic inventories (e.g., external data sources), but we've not yet had to reach for that functionality.

Deferring to others for further feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants