In this article, we will quickly review the main functions of Ansible. For novices, some of the details may not be understood. It doesn’t matter, we will talk about it later.
Prepare the environment
Since we use Ansible to manage multiple machines in batches, we prepare multiple machines for testing, and CentOS7 is used here.
[root@192-168-31-106 ~]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.31.106 node1 manager
192.168.31.100 node2
192.168.31.101 node3
192.168.31.102 node4
IP configuration to the /etc/hosts of the management node is not necessary, here is just for convenience
- 106 is the management node, that is, the node where Ansible is installed, and the other nodes are managed nodes, or called working nodes
- Ansible needs to be installed on the management node, please refer to the previous section for installation steps
1.0-安装 - The management node needs to be configured to log in to other machines without password, please refer to https://blog.csdn.net/xys2015/article/details/110442383
After the configuration is complete, remember to test all, such as
ssh ${IP_OR_DOMAIN} echo hello
Host list
The machine managed by Ansible must be written in the inventory file. The simple host list format is very simple. Just arrange the IP addresses vertically. The default host inventory file is /etc/ansible/hosts. Let’s modify it and fill in the one we want to use. IP address
cp /etc/ansible/hosts /etc/ansible/hosts.bak #查看这个默认文件可以看到一些基础帮助
cat /etc/ansible/hosts
[myservers]
192.168.31.106:22
192.168.31.100:22
192.168.31.101:22
192.168.31.102:22
#myservers是分组名，可根据实际情况填写
#主机清单文件里，#号开头是注释
In the production environment, the host list file is usually placed on git for management
Ad-Hoc
For example, if we want to check the memory usage of a remote machine, we can do this with SSH
[root@192-168-31-106 ~]# ssh 192.168.31.100 free -h
If we want to view the memory usage of multiple machines at the same time, we can write a script to implement it in a loop. I won’t go into details here. Let’s see how Ansible implements similar functions.
[root@192-168-31-106 ~]# ansible all -a "free -h"
192.168.31.106 | CHANGED | rc=0 >>
total used free shared buff/cache available
Mem: 3.9G 2.5G 741M 9.1M 651M 1.1G
Swap: 0B 0B 0B
192.168.31.101 | CHANGED | rc=0 >>
total used free shared buff/cache available
Mem: 3.9G 210M 3.5G 8.5M 110M 3.5G
Swap: 0B 0B 0B
192.168.31.102 | CHANGED | rc=0 >>
total used free shared buff/cache available
Mem: 3.9G 210M 3.6G 8.5M 103M 3.5G
Swap: 0B 0B 0B
192.168.31.100 | CHANGED | rc=0 >>
total used free shared buff/cache available
Mem: 3.9G 215M 3.5G 8.5M 103M 3.5G
Swap: 0B 0B 0B
Here allis a special usage, which means all the machines written in the host list, the default is/etc/ansible/hosts
CHANGEDIt may be a bit strange for everyone here to understand, because we know that free -hthe state of the target machine will not be changed. A well-designed Ansible grammar can achieve a very important function that is "idempotence". To put it bluntly, a script can achieve a function. , And repeated execution of this script will not change the target state. For example, if we write a set of scripts to install nginx, it may include downloading packages and starting services. A script with good idempotence should be guaranteed. When I repeatedly execute this script, The system can automatically detect that nginx is already running, so that related installation operations are no longer performed. If you don't have relevant background knowledge, it may be difficult for everyone to understand this point, and you can ignore it for the time being
I believe that you can draw inferences from one another, and you can already achieve many Ansible gameplay such as the following commands
ansible all -a "df -h"
ansible all -a "cat /etc/hosts"
There is an instruction that is very common, usually we execute it for the first time
ansible all -m ping
ansible myservers -m ping #myservers是我定义的机器分组名称，大家根据情况修改
Can detect whether the connectivity of Ansible to the target machine is normal
Exploring the Playbook
If we want to automate certain functions, the most traditional solution is to write Shell scripts to organize a group of commands. In Ansible, you can use a YAML file, called a playbook, to organize Ansible commands in an orderly and structured manner. , As follows, we demonstrate how to use Ansible to configure the time synchronization service on the machine
[root@192-168-31-106 ~]# cat ntpupdate.yaml
---
- hosts: all
tasks:
- name: Ensure ntpdate (for time synchronization) is installed.
yum:
name: ntpdate
state: present
- name: Create a cron "*/10 * * * * /usr/sbin/ntpdate -u ntp1.aliyun.com &> /dev/null"
cron:
name: "sync_beijing_time"
minute: "*/10"
job: "/usr/sbin/ntpdate -u ntp1.aliyun.com &> /dev/null"
We are testing at this stage, it doesn’t matter where this file is placed
YAML has very strict requirements for spaces. You can use 2 spaces or 4 spaces. Generally, 2 spaces are used (the official document example is also 2). You can use the following command to check whether there are grammatical errors:
ansible-playbook --syntax-check ntpupdate.yaml
Take a look at which machines are managed by the script:
ansible-playbook ntpupdate.yaml --list-hosts
Actually execute the command:
ansible-playbook ntpupdate.yaml
[root@192-168-31-106 ~]# ansible-playbook ntpupdate.yaml
PLAY [all] *******************************************************************************************************
TASK [Gathering Facts] ********************************************************************************************
ok: [192.168.31.102]
ok: [192.168.31.101]
ok: [192.168.31.106]
ok: [192.168.31.100]
TASK [Ensure ntpdate (for time synchronization) is installed.] *****************************************************
ok: [192.168.31.102]
ok: [192.168.31.100]
changed: [192.168.31.101]
ok: [192.168.31.106]
TASK [Create a cron "*/10 * * * * /usr/sbin/ntpdate -u ntp1.aliyun.com &> /dev/null"] ******************************
changed: [192.168.31.102]
changed: [192.168.31.101]
changed: [192.168.31.106]
changed: [192.168.31.100]
PLAY RECAP ********************************************************************************************************
192.168.31.100 : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
192.168.31.101 : ok=3 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
192.168.31.102 : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
192.168.31.106 : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
The content of the execution observation output ansible-playbook ntpupdate.yamlcan be repeated several times. The screenshots you get may be different from mine.
- Green OK means that the target machine has not made any changes
- Yellow indicates that the target machine has been modified (not necessarily a real modification)
You can find a machine at will and check the execution result
[root@192-168-31-100 ~]# rpm -qa | grep update
geoipupdate-2.5.0-1.el7.x86_64
[root@192-168-31-100 ~]# crontab -l
#Ansible: sync beijing time
*/10 * * * * /usr/sbin/ntpdate -u ntp1.aliyun.com &> /dev/null
I believe that everyone can intuitively feel the simplicity and power of Ansible. The above automatic configuration time synchronization task is still a bit of a workload if written in Shell script, and it is certainly not as simple as Ansible, especially realized by Shell script. Idempotent, the result can be observed, etc., and the workload is greatly increased. The YUM we used above installs and manages timed tasks. This is called Ansible-supported module (module), which we will talk about later.
Reference
https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html