basis
The host list, inventory, is the place where the IP or domain name of the managed machine is stored. The IP addresses in the list can be grouped, such as a group of front-end machines and a group of back-end machines. By default, this configuration file is in /etc/ansible/hosts. The following is an example
# cat /etc/ansible/hosts
[webservers]
foo.example.com
bar.example.com
192.168.31.10
[dbservers]
one.example.com
two.example.com
three.example.com
The group name follows the general variable naming rules and cannot start with a number, and special symbols can only be underscores
Use in playbook
# cat main1.yml
---
- hosts: dbservers
gather_facts: yes
tasks:
- name: test1
debug:
msg: "just for a test"
ansible-playbook main1.yml #这种执行方式就是去默认主机清单里找，即 /etc/ansible/hosts
ansible-playbook main1.yml -i hosts #这种执行方式主机清单就是当前目录的hosts文件，路径也可以用绝对路径，hosts文件名称不固定
When the playbook is executed, the -v parameter is added, and the host list path will be output
Use in the command line (Ad-Hoc)
ansible webservers -m ping
Default groups
There are two special group names, which are built-in, and are available by default, alland ungrouped, as the name suggests, a allgroup represents all machines, and ungroupedrepresents machines that do not belong to any group, as shown in the following example of a host list
# cat /etc/ansible/hosts
192.168.31.10 #属于 ungrouped 和 all 分组
192.168.31.11 #属于 ungrouped 和 all 分组
[webservers]
foo.example.com #属于 webservers 和 all 分组
bar.example.com #属于 webservers 和 all 分组
[dbservers]
one.example.com #属于 dbservers 和 all 分组
two.example.com #属于 dbservers 和 all 分组
three.example.com #属于 dbservers 和 all 分组
Therefore, the Ansible command that we often use to check the connectivity of the machine, or the group name of the playbook, is specified as all, which means that all machines apply the playbook
allAnd ungroupedbelong to the reserved group name and cannot be written into the group name of the host list by yourself
Common machine grouping methods
There are roughly three
- According to service (business, role), such as web, mysql, php, dns
- According to geographic location (computer room), such as north, south, beijing, shenzhen
- According to the time stage, that is, production prod, pre-production stag, and test
Nesting of machine groups
A machine may belong to multiple groups. For example, if a machine is web, in the north, in the production environment, then this machine will appear in three groups
The host lists we introduced before are all in the format of configuration files (INI), and Ansible also supports YAML format for writing host lists. For host lists with nested relationships, it is clearer to write in YAML format, as shown in the following example
all:
hosts:
192.168.21.100:
children:
webservers:
hosts:
192.168.31.101:
192.168.31.102:
192.168.31.103:
dbservers:
hosts:
192.168.41.101:
192.168.41.102:
192.168.41.103:
east:
hosts:
192.168.41.101:
192.168.41.102:
192.168.41.103:
west:
hosts:
192.168.31.101:
192.168.31.102:
192.168.31.103:
prod:
hosts:
192.168.31.101:
192.168.31.102:
192.168.31.103:
test:
hosts:
192.168.41.103:
centos:
children:
webservers:
ubuntu:
children:
dbservers:
Select a group of machines in batch
Batch selection of www01 ~ www50 machines
[webservers]
www[01:50].example.com
Batch selection of dba ~ dbf machines
[databases]
db-[a:f].example.com
This situation is similar to regular matching, which is generally rarely used. For example, if a machine needs to be offline, this way of writing is more troublesome.
Other matching syntaxes that can be used are shown in the following table
| Description | Pattern(s) | Targets |
|---|---|---|
| All hosts | all (or *) | Match all machines |
| One host | host1 | Match a single machine |
| Multiple hosts | host1,host2 | Match multiple machines separated by comma |
| One group | webservers | Match a machine group |
| Multiple groups | web servers: dbservers | Match multiple machines grouped by colon |
| Intersection of groups | webservers:&staging | Match machines in both webservers and staging groups |
Define variables in the host list
3.1 Playbooks 高级一Related content in the reference
Control SSH connection variables (connection variables)
This type of variable is specifically used to control the SSH connection parameters of the target machine. For example, adding the SSH port of the target machine is not listening on the default port 22, so you need to change it here
| variable | meaning |
|---|---|
| ansible_connection | Remote communication mode, smart, ssh, paramiko, the default is smart means automatic, this value generally does not need to be changed, paramiko is a python operation ssh package |
| ansible_host | Generally not used, unless the given domain name cannot be resolved (if you use the IP address directly in this way) |
| ansible_port | Specify the ssh port, the default is 22 |
| ansible_user | Specify the user for ssh connection, the default is the current user |
| ansible_password | Specify the password for the ssh connection (if no password-free login is done) |
| ansible_python_interpreter | Specify the python path of the target machine, and find /usr/bin/python by default. If this place does not exist, or the python version of this place is too low, you need to modify it |
Usage example
#cat /etc/ansible/hosts
some_host ansible_port=2222 ansible_user=manager
192.168.31.100 ansible_user=root ansible_password=123456
freebsd_host ansible_python_interpreter=/usr/local/bin/python
It can be seen that these variables all start with ansible. The official document does not seem to mention whether they can be overwritten. However, it is better not to define variables starting with ansible.
Use account passwords to directly control the machine. You need to log in manually to remember The key
Reference
https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html
https://docs.ansible.com/ansible/latest/user_guide/intro_patterns.html
https://docs.ansible.com/ansible/latest/user_guide/connection_details.html