Load variables based on the environnement (test, val, prod)

[Wilfried Anuzet]

Hello to all Ansible guru :)

I write a playbook to deploy a newest Jboss infrastructure.
I want to use a loop to iterate over a list of items to deploy all the datasource I need, all the datasources change based on the environnement they're deployed

Here the part of my role to add the datasource:
 

- name: Add datasources
   command: {{ jboss_home }}/bin/jboss-cli.sh -c controller={{ jboss_master }}:{{ jboss_master_port }} --user={{ admin_user }} --password={{ admin_password }} --command="data-source add --jndi-name={{ item.jndi_name }} --name={{ item.ds_name}} --connection-url={{ item.conn_url }} --driver-name={{ item.driver_name }} --user-name={{ item.dsusername }} --password={{ item.dspassword }} --profile={{ item.ds_profile }}"                                                  
   with_items:
     - { some vars }
     - { another vars }
     - ...

When I launch the playbook I use a different inventory file based on the environnement, like:

ansible-playbook -i testing install-all.yml

or

ansible-playbook -i production install-all.yml

What's the best pratices to add datasources based on the environnement type ?
I think about something like:

 command: some_command_with_vars
 with_items:
   - { some_item }
 when: {{ env }}

But I have to write three blocks with all item for my three environnement (the two other will be skipped everytime I run the playbook).

Is there's a way to load dynamically a file containing a dict with all item I need based on the environnement ?
In that way I have to write three file containing the vairables I need inthe vars folder (test.yml, val.yml and prod.yml) and load them dynamically based on the environnement variable I can set in the inventory file. Something like:

command: some_command_with_vars
with_items_in:
  - {{ env }}.yml

Am I and the right way ? What I missed here and how do you handle that ?

Thanks :)

[John Jolet]

I set those in group_vars/appname-stg.yml, group_vars/appname-dev.yml, etc.

as long as a host only belongs to one environment-grouping, this works great.

[Wilfried Anuzet]

Thanks for your answer,

I don't know if your proposition fit well in my playbook.
here my structure of a file like production, testing, validation that I call with:

ansible-playbook -i testing install-all.yml

Example file:

 
# Actual Wildfly master node
[master]
wfy01
 
# Actual Wildfly slave nodes
[slave]
wfy02
wfy03

As you can see all have the same following struture. and there's always master and slave groups.
So I cannot really use groups variables as they have to be different if the master or slave server are in production, validation or testing env...

Maybe it's my playbook structure itself which is not really well done.
I'm thinking about make an invetory with [ master-prod ],[ master-dev ], etc groups but again I have to write other yml file for all env as now I use this kind to include roles based on groups the server belong:

- name: Configure the Wildfly master node
  hosts: master #write three file with master-prd, master-dev, master-val ?
  user: root
  roles:
    - master

Maybe you can suggest a better way to do :)

[Wilfried Anuzet]

Btw i found a solution.

Not sure if it's the best pratices but it works well for my case.
I've defined a variable for all server on the production, validation and testing file:

[all:vars]
env=production #or validation, testing

I create production.yml, validation.yml and testing.yml file in roles/datasources/vars that contains my datasources dict:

datasources:
  FirstDS:
    jndi_name: 'FirstDSjndiName'
    ds_name: 'FirstDSName'
    conn_url: 'FirstDSConnURL'
    driver_name: 'FirstDSdriver'
    dsusername: 'FirstDSUser'
    dspassword: 'FirstDSpassword'
  SecondDS:
    [...]

And inside my task file I load the file dynamically with:

- name: Include "{{ env }}" datasources dict
  include_vars: "vars/{{ env }}.yml"

[J Hawkesworth]

I use group_vars for each environment. But I also have some groups which I use in more than one of my inventory files. This is nice as it means things which can be shared across different environments, but not necessarily across all environments, can go in one settings file, and things which are specific to environments go in environment-specific group vars settings.

Hope this helps,

Jon