The use of the playbooks variable of the automatic operation and Maintenance tool ansible

In peacetime operation and maintenance work sometimes need to be based on different remote nodes or different IP systems to do different configuration deployment. For example, ansible can do different processing of the configuration files on each node according to different IP addresses, and variables are needed here.

You can define variables directly in the playbooks file:

-Hosts:webservers vars:http_port:80

A variable named Http_port is defined with a value of 80.

Defining variables through file inclusions and roles

[Email protected] ~]# CAT/ETC/ANSIBLE/ROLES/WEBSERVERS/VARS/MAIN.YML---http_port:8099max_clients:321

Directly define variables in the role directory vars/main.yml . The file is automatically included when the role is executed.

Use of variables

To use variables in the template file:

My amp goes to {max_amp_value}}

You can also use variables directly in the playbooks file:

Template:src=foo.cfg.j2 dest={{Remote_install_path}}/foo.cfg

Use the variable value to determine where the file is stored on the remote node.

Reference other variables in the definition variable:

-Hosts:app_servers Vars:app_path: "{{Base_path}}/22"

Double quotation marks include the value of the variable (such as the value of App_path).

System Information: Facts

There is another place to get some variables, but the values of these variables are collected by ansible themselves.

The system information collected from the remote node is called facts .

factsThis includes the IP address of the remote host, the operating system type, disk-related information, and so on.

Follow the commands below to see what information is available:

Ansible hostname-m Setup

The return content looks like this:

[[email protected] ~]# ansible webservers -m setup192.168.1.65 |  success >> {     "Ansible_facts": {          "Ansible_all_ipv4_addresses": [              "192.168.1.65"         ],           "Ansible_all_ipv6_addresses": [              "fe80::250:56ff:fe93:a885"         ],           "Ansible_architecture":  "x86_64",           "Ansible_bios_date":  "01/07/2011",           "ansible_bios_version":  "6.00",           "Ansible_cmdline":  { &Nbsp;           "Keyboardtype":  "PC",               "KEYTABLE":  "Us",               "LANG":  "en_US. UTF-8 ",             " SYSFONT ": " Latarcyrheb-sun16 ",             " Crashkernel " :  "[email protected]",              "Quiet": true,              "Rd_NO_DM":  true,              "Rd_no_luks":  true,              "Rd_NO_LVM":  true,               "RD_NO_MD": true,              "RHGB": true,              "Ro":  true,              "root":  "UUID= C3E6EDA7-D67D-4787-8F9F-6534941F11FD "        },           "Ansible_date_time": {              "Date":  "2015-07-30",               "Day":  ",           "    "Epoch":  "1438241766",               "Hour":  ",             " iso8601 ": " 2015-07-30t07:36:06z ", &Nbsp;             "Iso8601_micro":  " 2015-07-30t07:36:06.373646z ",             " Minute ": ",              "month":   ",             " second ": " 06 ",               "Time":  "15:36:06",               "TZ":  "CST",               "Tz_offset":  "+0800",               "Weekday":  "Thursday",               "Year":           },          "Ansible_default_ipv4": {              "Address":  "192.168.1.65",               "Alias":  "Eth1",               "Gateway":  "192.168.1.254",               "Interface":  "eth1",               "MACAddress":  "00:50:56:93:a8:85",               "MTU": 1500,               "netmask":  "255.255.255.0",               "Network":  "192.168.1.0",               "type":  "ether"        },         #省略若干行内容          "Ansible_eth1": {              "Active": true,               "Device":  "eth1",               "IPv4": {                  "Address":  "192.168.1.65",                   "netmask":  "255.255.255.0",                   "Network":  "192.168.1.0"              },               " IPv6 ":  [                {                       "Address":  "fe80::250:56ff:fe93:a885",                       "prefix":  ",   "                    " Scope ": " link "                 }            ],               "MACAddress":  "00:50:56:93:a8:85",               "module":  "Vmxnet3",               "MTU": 1500,               "Promisc": false,               "type":  "Ether"         },           "Ansible_fips": false,           "Ansible_form_factor":  "Other",          " Ansible_fqdn ": " DB2 ",         " Ansible_hostname ": " DB2 " ,          "Ansible_interfaces": [              "Lo",               "Eth1"         ],                    Omit several lines of content ...

You can use the value returned from the top in a few ways:

{{Ansible_devices.sda.model}}

To obtain the host name of the system:

{{Ansible_hostname}}

factsare often used in conditional statements and templates. For example, depending on the Linux distribution, different package management programs are executed.

Close Facts

If you are sure that you do not need any facts information for the host and you know the remote node host well, you can turn it off. When the remote operation node is large, turning off facts will improve the performance of the ansible.

You only need to play set the following in:

-Hosts:whatever Gather_facts:no

Local Facts (FACTS.D)

If there is a directory on the Remote node system, the etc/ansible/facts.d suffix file in this directory can be in .fact JSON format or INI format, or an executable file that can return JSON formatted data, which can be used to provide local facts information.

Create a file on the remote node with the /etc/ansible/facts.d/preferences.fact following contents:

[general]asdf=1bar=2

Get customized information on the control node:

[[email protected] ~]# ansible webservers -m setup -a  "Filter=ansible_ Local "192.168.1.65 | success >> {    " ansible_facts ":  {          "Ansible_local": {              "Preferences": {                  "General": {                      "ASDF":  "1",                        "Bar":  "2"                  }            }         }    },      "changed":  false} 

Filter to specify a filtering condition.

You can use the obtained information in playbooks or in a template:

{{ANSIBLE_LOCAL.PREFERENCES.GENERAL.ASDF}}

Registering variables

The results of a task can be saved to a variable for later use, sometimes the role of the running command needs to be saved and performed as a condition for the next person's task. When running playbooks, you can use -v parameters to display the result information during execution.

The specific format is as follows:

-Hosts:web_servers tasks:-Shell:/usr/bin/foo register:foo_result Ignore_errors:true-shell:/ Usr/bin/bar When:foo_result.rc = = 5

Use the register result of executing the shell module in the variable foo_result and reference the variable later.

Example:

#远程节点上创建一个shell脚本 [[email protected] ~]# cat/tmp/test.sh #!/bin/bashecho 123# Control node [[email protected] ~]# cat/etc/ansible /REGISTER.YML----hosts:webservers remote_user:root tasks:-Shell:/tmp/test.sh register:rst_value Ignore _errors:true-name:touch file in tmp named Register.log File:state=touch dest=/tmp/register.log When:rst_va Lue.stdout = = "123" #远程节点 [[email protected] ~]# ll/tmp/register.log-rw-r--r--. 1 root root 0 Jul 16:42/tmp/register.log

When the remote node script/tmp/test.sh runs to the end and outputs 123, the file/tmp/register.log is created on the remote node.

Access to complex variables

In the facts information, the network-related information is a nested data structure that wants to obtain an IP address:

{{ansible_eth0["IPv4" ["Address"]}}

Or:

{{ansible_eth0.ipv4.address}}

Access the first element of the array:

{{foo[0]}}

To define a variable in a separate file

You can also define a variable in a separate file, and then use the var_files import file in playbooks:

----Hosts:all remote_user:root vars:favcolor:blue vars_files:-/vars/external_vars.yml tasks:-Name:thi S is just a placeholder command:/bin/echo foo

The variable file is also in ymal format:

---# in the above example, this would is vars/external_vars.ymlsomevar:somevaluepassword:magic

When you use the Ansible role in automated work, you do not need to define the variable file as above, the variables defined in VARS/MAIN.YML in the role directory are automatically imported into playbooks and do not need to explicitly include the variable file.

Command line pass Variable

In addition to the variable definition form described above, you can also pass variables through the command line, such as a more generic node deployment playbooks, passing a version number in each deployment:

Ansible-playbook release.yml--extra-vars "version=1.23.45 Other_variable=foo"

You can also pass host group and remote user information to playbooks:

----Hosts: ' {{hosts}} ' Remote_user: ' {{user} ' tasks:-... ansible-playbook release.yml--extra-vars "Hosts=vip ERs user=starbuck "

The variables in the playbooks make the ansible more flexible and more robust when used, and can perform different operations on the remote nodes in a "individualized" manner so that the node system reaches the desired state.

This article is from the "Diannaowa" blog, make sure to keep this source http://diannaowa.blog.51cto.com/3219919/1680732

The use of the playbooks variable of the automatic operation and Maintenance tool ansible