How to distinguish production / production with dynamic inventory?

Question

I am stuck. He left the Internet and could not find the answer.

I have been using Ansible for many years, but always with static reserves. To distinguish between different environments, such as production and production, I used different static inventory files, staging and production , respectively. When I needed to create intermediate servers, I would do:

 ansible-playbook site.yml -i staging 

When I wanted to do the same for production, I would do:

 ansible-playbook site.yml -i production 

Both stages of production and production require variables with different values, so I have group_vars/staging and group_vars/production . All is good and in line with best practices.

Now I need to provide EC2 instances in AWS. I am using this AWS guide . I have a notebook with two games. The first runs with localhost , creates / finds the required EC2 instances in AWS, and populates the group with add_host . The second game uses this group to run against instances of EC2 found in the first game. Everything is according to this guide.

Everything works fine except for one. I do not know how to indicate which environment to provide and, therefore, the required variables are not loaded from group_vars/(staging|production) . Basically, what I want, like -i (staging|production) , I have used all these years with static reserves, but it seems that using -i now makes no sense, since the inventory is dynamic. I want to be able to load variables from group_vars/staging or group_vars/production based on the argument that I pass to the ansible-playbook when I run it.

How can I do it? What is the best practice?

Answer 1

While I'm not sure how to do this using the standard EC2 modulator, since we do not use it to create boxes from a level that exists at the level, there is an easy way to get what you want, an ec2 external inventory script and simple settings in inventories/main What you need to do is configure ec2.py and ec2.ini inside your inventories so that it is used as the source of the instances. Be sure to uncomment group_by_tag_keys = True inside ec2.ini .

The next step is to differentiate which instance goes there. Although there are many selection methods in ec2.py , I prefer to specifically mark each instance accordingly. Thus, all my instances have a tag called environment , which is populated accordingly (in your case, it will be either production or production). Then it remains only to process it inside your inventories/main , and here is a small example of how to do it.

First you must define an empty group for the tags you want to use:

 [tag_environment_staging] [tag_environment_production] 

so that we can refer to them later. After that, all that remains to be done is to indicate these groups as children for the respective stages. Therefore, after this, our minimum file will look like this:

 [tag_environment_staging] [tag_environment_production] [staging:children] tag_environment_staging [production:children] tag_environment_production 

And you go there. From now on, each instance extracted from ec2 through the dynamic inventory script that comes with the environment tag will correspond to the corresponding configuration in group_vars . All you have to remember is that when working with dynamic inventories you want your -i point to inventories , not a specific file, so that it works correctly.

Answer 2

I have a similar problem with dynamic stocks, but for Openstack. The solution that I have come up with so far is to use an environment variable to indicate whether I want to target an intermediate or production environment. It should also be applicable to your case. In our setup, $OS_PROJECT_NAME has either stage or prod . In ansible.cfg install

 inventory = ./inventories/${OS_PROJECT_NAME}/openstack.py 

Then we have the environment-specific group variables in the section

 inventories/(stage|prod)/group_vars/ 

The downside is that you have to have an inventory script in two places or have a symbolic binding. Also beware that group_vars found relative to the playbook directory will still override the group_vars inventory.