Ansible supports variables that can be used to store values that can be reused throughout files in an entire Ansible project. This can help simplify creation and maintenance of a project and reduce the incidence of errors.
\n<\/p>\n
vars, vars_files<\/code>, and vars_prompt<\/code><\/li>\n- Command line:\n
# ansible-playbook play.yml -e'{\"myVar\":\"myValue\",\"anotherVar\":\"anotherValue\"}'<\/pre>\n<\/li>\n - Roles, blocks, and inventories<\/li>\n<\/ul>\n<\/li>\n
- Essential variable use:\n
\n- debug: msg=\"Look! I'm using my variable ({ myVar )) !\"<\/code><\/li>\n<\/ul>\n<\/li>\n- A note on quotes:\n
\nname: \"({ package ))\"<\/code><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n <\/p>\n
Scope of variables<\/span>
\nVariables can be defined in a bewildering variety of places in an Ansible project. However, this can be simplified to three basic scope levels:<\/p>\n\n- Global scope<\/em>:\u00a0 Variables set from the command line or Ansible configuration<\/li>\n
- Play scope<\/em>:\u00a0 Variables set in the play and related structures<\/li>\n
- Host scope<\/em>:\u00a0 Variables set on host groups and individual hosts by the inventory, fact gathering, or registered tasks
\nIf the same variable name is defined at more than one level, the higher wins. So variables defined by the inventory are overridden by variables defined by the playbook, which are overridden by variables defined on the command line.<\/li>\n<\/ul>\n <\/p>\n
Variables in playbooks<\/span><\/p>\nWhen writing playbooks, administrators can use their own variables and call them in a task. For example, a variable web_package<\/code> can be defined with a value of httpd<\/code> and called by the yum<\/code> module in order to install the httpd<\/code> package.<\/p>\n- hosts: all\r\n vars:\r\n user: joe\r\n home: \/home\/joe<\/pre>\nIt is also possible to define playbook variables in external files. In this case, instead of using vars, the vars_files<\/code> directive may be used.<\/p>\n- hosts: all\r\n vars_files:\r\n - vars\/users.yml<\/pre>\nThe playbook variables are then defined in that file or those files in YAML format:<\/p>\n
user: joe\r\nhome: \/home\/joe<\/pre>\nOnce variables have been declared, administrators can use the variables in tasks. Variables are referenced by placing the variable name in double curly braces.<\/p>\n
vars:\r\n user: joe\r\ntasks:\r\n# This line will read: Creates the user joe\r\n- name: Creates the user {{ user }}\r\n user:\r\n # This line will create the user named Joe\r\n name: \"{{ user }}\"<\/pre>\nImportant<\/em><\/strong>
\nWhen a variable is used as the first element to start a value, quotes are mandatory. This prevents Ansible from considering the variable as starting a YAML dictionary. The following message appears if quotes are missing:<\/p>\nyum:\r\n name: {{ service}}\r\n ^ here\r\n\r\nWe could be wrong, but this one looks like it might be an issue with\r\nmissing quotes. Always quote template expression brackets when they\r\nstart a value. For instance:\r\n\r\nwith_items:\r\n- {{ foo }}\r\nShould be written as:\r\n\r\nwith_items:\r\n- \"{{ foo }}\"<\/pre>\n <\/p>\n
Host variables and group variables<\/span>
\nInventory variables that apply directly to hosts fall into two broad categories:<\/p>\n\n- host variables that apply to a specific host<\/li>\n
- group variables that apply to all hosts in a host group or in a group of host groups.<\/li>\n<\/ul>\n
Host variables take precedence over group variables, but variables defined by a playbook take precedence over both. One way to define host variables and group variables is to do it directly in the inventory file. This is an older approach and not preferred, but may be encountered by users:<\/p>\n
\u2022 This is a host variable, ansible_user<\/code>, being defined for the host demo.example.com.<\/p>\n[servers]\r\ndemo.example.com ansible_user=joe<\/pre>\n\u2022 In this example, a group variable user<\/code> is being defined for the group servers.<\/p>\n[servers]\r\ndemo1.example.com\r\ndemo2.example.com\r\n\r\n[servers:vars]\r\nuser=joe<\/pre>\n\u2022 Finally, in this example a group variable user<\/code> is being defined for the group servers, which happens to consist of two host groups each with two servers.<\/p>\n[servers1]\r\ndemo1.example.com\r\ndemo2.example.com\r\n\r\n[servers2]\r\ndemo3.example.com\r\ndemo4.example.com\r\n\r\n[servers:children]\r\nservers1\r\nservers2\r\n\r\n[servers:vars]\r\nuser=joe<\/pre>\nAmong the disadvantages of this approach, it makes the inventory file more difficult to work with, mixes information about hosts and variables in the same file, and uses an obsolete syntax.<\/p>\n
Using group_vars and host_vars directories<\/span>
\nThe preferred approach is to create two directories in the same working directory as the\u00a0 inventory file or directory,\u00a0 group_vars<\/code> and host_vars<\/code>. These directories contain files defining group variables and host variables, respectively.<\/p>\nImportant<\/em><\/strong>
\nThe recommended practice is to define inventory variables using host_vars<\/code> and group_vars<\/code> directories, and not to define them directly in the inventory file or files.<\/p>\nTo define group variables for the group servers, a YAML file named group_vars\/servers<\/code> would be created, and then the contents of that file would set variables to values using the same syntax as a playbook:<\/p>\nuser: joe<\/pre>\nLikewise, to define host variables for a particular host, a file with a name matching the host is created in host_vars<\/code> to contain the host variables.<\/p>\nThe following examples illustrate this approach in more detail. Consider the following scenario where there are two data centers to manage that has the following inventory file in ~\/project\/inventory<\/code>:<\/p>\n[admin@station project]$ cat ~\/project\/inventory\r\n[datacenter1]\r\ndemo1.example.com\r\ndemo2.example.com\r\n[datacenter2]\r\ndemo3.example.com\r\ndemo4.example.com\r\n[datacenters:children]\r\ndatacenter1\r\ndatacenter2<\/pre>\n\u2022 If a general value needs to be defined for all servers in both datacenters, a group variable can be set for datacenters:<\/p>\n
[admin@station project]$ cat ~\/project\/group_vars\/datacenters\r\npackage: httpd<\/pre>\n\u2022 If the value to define varies for each datacenter, a group variable can be set for each datacenter:<\/p>\n
[admin@station project]$ cat ~\/project\/group_vars\/datacenter1\r\npackage: httpd\r\n[admin@station project]$ cat ~\/project\/group_vars\/datacenter2\r\npackage: apache<\/pre>\n\u2022 If the value to be defined varies for each host in every datacenter, using host variables is recommended:<\/p>\n
[admin@station project]$ cat ~\/project\/host_vars\/demo1.example.com\r\npackage: httpd\r\n[admin@station project]$ cat ~\/project\/host_vars\/demo2.example.com\r\npackage: apache\r\n[admin@station project]$ cat ~\/project\/host_vars\/demo3.example.com\r\npackage: mariadb-server\r\n[admin@station project]$ cat ~\/project\/host_vars\/demo4.example.com\r\npackage: mysql-server<\/pre>\nThe directory structure for project, if it contained all of the example files above, might look like this:<\/p>\n
project\r\n\u251c\u2500\u2500 ansible.cfg\r\n\u251c\u2500\u2500 group_vars\r\n\u2502 \u251c\u2500\u2500 datacenters\r\n\u2502 \u251c\u2500\u2500 datacenters1\r\n\u2502 \u2514\u2500\u2500 datacenters2\r\n\u251c\u2500\u2500 host_vars\r\n\u2502 \u251c\u2500\u2500 demo1.example.com\r\n\u2502 \u251c\u2500\u2500 demo2.example.com\r\n\u2502 \u251c\u2500\u2500 demo3.example.com\r\n\u2502 \u2514\u2500\u2500 demo4.example.com\r\n\u251c\u2500\u2500 inventory\r\n\u2514\u2500\u2500 playbook.yml<\/pre>\n <\/p>\n
Overriding variables from the command line<\/span>
\nInventory variables are overridden by variables set in a playbook, but both kinds of variables may be overridden through arguments passed to the ansible or ansible-playbook commands on the command line. This can be useful in a case where the defined value for a variable needs to be overridden for a single host for a one-off run of a playbook. For example:<\/p>\n[user@demo ~]$ ansible-playbook demo2.example.com main.yml -e \"package=apache\"<\/pre>\n <\/p>\n
Variables and arrays<\/span>
\nInstead of assigning a piece of configuration data that relates to the same element (a list of packages, a list of services, a list of users, etc.) to multiple variables, administrators can use arrays. One interesting consequence of this is that an array can be browsed.
\nFor instance, consider the following snippet:<\/p>\nuser1_first_name: Bob\r\nuser1_last_name: Jones\r\nuser1_home_dir: \/users\/bjones\r\nuser2_first_name: Anne\r\nuser2_last_name: Cook\r\nuser3_home_dir: \/users\/acook<\/pre>\nThis could be rewritten as an array called users:<\/p>\n
users:\r\n bjones:\r\n first_name: Bob\r\n last_name: Jones\r\n home_dir: \/users\/bjones\r\n acook:\r\n first_name: Anne\r\n last_name: Cook\r\n home_dir: \/users\/acook<\/pre>\nUsers can then be accessed using the following variables:<\/p>\n
# Returns 'Bob'\r\nusers.bjones.first_name\r\n# Returns '\/users\/acook'\r\nusers.acook.home_dir<\/pre>\nBecause the variable is defined as a Python dictionary, an alternative syntax is available.<\/p>\n
# Returns 'Bob'\r\nusers['bjones']['first_name']\r\n# Returns '\/users\/acook'\r\nusers['acook']['home_dir']<\/pre>\nImportant<\/strong><\/em>
\nThe dot notation can cause problems if the key names are the same as names of Python methods or attributes, such as discard, copy, add, and so on. Using the brackets notation can help avoid errors. Both syntaxes are valid, but to make troubleshooting easier, it is recommended that one syntax used consistently in all files throughout any given Ansible project.<\/p>\n <\/p>\n
Registered variables<\/span>
\nAdministrators can capture the output of a command by using the register<\/code> statement. The output is saved into a variable that could be used later for either debugging purposes or in order to achieve something else, such as a particular configuration based on a command’s output. The following playbook demonstrates how to capture the output of a command for debugging purposes:<\/p>\n---\r\n- name: Installs a package and prints the result\r\n hosts: all\r\n tasks:\r\n - name: Install the package\r\n yum:\r\n name: httpd\r\n state: installed\r\n register: install_result\r\n - debug: var=install_result<\/pre>\nWhen the playbook is run, the debug module is used to dump the value of the install_result<\/code> registered variable to the terminal.<\/p>\n[user@demo ~]$ ansible-playbook playbook.yml\r\nPLAY [Installs a package and prints the result] ****************************\r\nTASK [setup] ***************************************************************\r\nok: [demo.example.com]\r\nTASK [Install the package] *************************************************\r\nok: [demo.example.com]\r\nTASK [debug] ***************************************************************\r\nok: [demo.example.com] => {\r\n\"install_result\": {\r\n\"changed\": false,\r\n\"msg\": \"\",\r\n\"rc\": 0,\r\n\"results\": [\r\n\"httpd-2.4.6-40.el7.x86_64 providing httpd is already installed\"\r\n]\r\n}\r\n}\r\nPLAY RECAP *****************************************************************\r\ndemo.example.com : ok=3 changed=0 unreachable=0 failed=0<\/pre>\n <\/p>\n
Dictionary Variables<\/span><\/p>\nemployee:\r\n name: bob\r\n id: 42<\/pre>\n