Ansible

Another recommended layout to use profiles in an ansible-playbook project

Usually, I prefer to start a project from the recommended best practice layout in ansible official website.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
inventories/
   production/
      hosts               # inventory file for production servers
      group_vars/
         group1.yml       # here we assign variables to particular groups
         group2.yml
      host_vars/
         hostname1.yml    # here we assign variables to particular systems
         hostname2.yml

   staging/
      hosts               # inventory file for staging environment
      group_vars/
         group1.yml       # here we assign variables to particular groups
         group2.yml
      host_vars/
         stagehost1.yml   # here we assign variables to particular systems
         stagehost2.yml

library/
module_utils/
filter_plugins/

site.yml
webservers.yml
dbservers.yml

roles/
    common/
    webtier/
    monitoring/
    fooapp/

It covers the essential mulitple environments deployment so that we can easily switch deployment by running following command in production or staging

1
2
$ ansible-playbook -i inventories/production webservers.yml -k -K --ask-vault-pass
$ ansible-playbook -i inventories/staging webservers.yml -k -K --ask-vault-pass

As I mentioned in my previous post Using ansible playbook in a DevOps pipeline, we could add an all.yml file in the playbook group_vars to provide following information to ansible-playbook to prevent from inputing password.

1
2
3
ansible_user: YOUR_USER_NAME
ansible_password: YOUR_USER_PASSWORD
ansible_become_password: YOUR_BECOME_PASSWORD

The group_vars in the root of the playbook is called playbook group_vars

1
2
3
4
inventories/
group_vars
     all.yml
webservers.yml

I feel it’s so inconvienient when I’m using my own user password instead of a shared service account between team members.
I don’t want tell others my vault password, in that case others can know my ansible_password and ansible_become_password.
Initially, I think I can create a template and everyone who wants to use the playbook should copy the project template and create their all.yml locally. It results in following project structure. 

1
2
3
4
5
6
inventories/
group_vars
     .gitignore -> all.yml
     all.yml.cfg
     all.yml (Anyone who doesnt' want to use -k -K --ask-vault-password options can create this in this local machine)
webservers.yml

It turns out it’s even more cumbersome, obviously…

I find another better solution out, where we can use the –extra-vars options to achieve my goal without constraints.
I decide to use the profile concept which I’ve learnt from ant build scripts in my previous company.
Here we don’t use playbook group_vars, instead, we create a profiles folder and add the vars for each profile, such as kai, chu

1
2
3
4
5
6
7
8
9
10
11
inventories/
    production/
    staging/
profiles/
    template/
        all.yml
    kai/
        all.yml
    chu/
        all.yml
webservers.yml

I have put ansible_user, ansible_password and ansible_become_password in the all.yml in folder kai
Now we gain the benefit of the profile by running following command

1
$ ansible-playbook -i inventories/production --extra-vars @profiles/kai/all.yml webservers.yml --vault-password-file ~/.ansible-vault-pass

It is an env/profile matrix solution, it gives the flexibility to test our ansible-playbook with any favourate vars
Let’s run the playbook with chu’s profile in staging before finish this posts

1
$ ansible-playbook -i inventories/staging --extra-vars @profiles/chu/all.yml webservers.yml --vault-password-file ~/.ansible-vault-pass

Summary

  • It’s good to use –extra-vars when we have some variables setup which is the ansible playbook user related, in other words, the variables are different for different ansible user.
  • It would be more appropriate to add one more inventories/test if there are a lot environment related differences.

an sible book
Check out what sible means here in the urban dictionary