What matters is that it should be possible to split the generic code and the properties that are proper to an instance. When using the second method we described, where every custom variable is in the inventory group vars, you can version only the inventory in your ops repository. When using the simple way, you will have to version your playbooks in your ops repository, as they contain your custom variables. Your ops repository is where you version everything specific to an instance of your code namely your inventory and custom variables. In short, you want to split your code in 2 repositories: your code repository, and your ops repository.Īpplying it to Ansible, your code repository is where you version your roles or your Ansible collections. When choosing the few locations to use, think about what effect it will have on your code versionning. This is not correct and we want to keep things simple. Now do we change it in the group_vars or in the role params? Both work, and there is no way to figure out which location you would choose, unless there is a specific logic behind it. We cannot change the role defaults variable, as we want our own custom value. Let’s say we want to modify servicea_log_dir variable. Let’s just take the 2 previous examples and mix them. By doing that, we are documenting every variable the role needs. Note how we can comment variables that are required, but for which we don’t want to provide any default value. Roles/serviceA/default.yml: this file defines all variables required by the role, with some default values. Start with something simple, for instance having only 2 places where your variables can be defined: If not, maybe you are spreading your variables in too many places. Whenever you think of a variable, it should be obvious where it is defined. Define your own subset of variables locations The simple way There are 22 different places where to store your variables! As your code evolve and become more complex, it can get messy. extra vars (for example, -e "user=my_user")(always win precedence).role vars (defined in role/vars/main.yml).role defaults (defined in role/defaults/main.yml).command line values (for example, -u my_user, these are not variables).Defining variables for your Ansible playbooks and roles can become challenging as your project grows.īrowsing the Ansible documentation, the diversity of Ansible variables location is confusing, to say the least:
0 kommentar(er)
