Ansible playbook script

1. Overview of YAML

■ YAML is a non-markup language, a language used to write configuration files, very concise and powerful

■ YAML syntax is similar to other languages, and can also express data structures such as hash tables and scalars

■ The structure is displayed by spaces, the configuration items in the sequence are represented by -, the key values ​​in the Map are separated by:, and the extension of YAML is yaml

1.1, basic grammar rules

■ Case sensitive

■ Use indentation to indicate hierarchical relationships

■ Tab key is not allowed when indenting, only spaces are allowed

■ The number of indented spaces is not important, as long as the elements of the same level are aligned to the left

1.2 Data structure supported by YAML

1.2.1, object

Object: A collection of key-value pairs, also known as mapping/hashes/dictionary
For example: name: Example Developer

1.2.2, array

Array: A set of values ​​arranged in order, also known as sequence/list.
For example:

- Apple
- Orange

1.2.3, scalar

Scalar: A single, indivisible value
For example:

number: 12.30
sure: true

2. Ansible's script-playbook script

■ Call ansible template through task to organize multiple plays to run in one playbook

2.1, playbooks composition

■ Tasks: tasks, that is, an operation completed by calling the module

■ Variables: Variables

■ Templates: Templates

■ Handlers: Handlers, when a certain condition is met, trigger the execution of the operation

■ Roles: Roles

2.2, supplementary commands

ansible-playbook nginx.yaml -- syntax-check      #检查yaml文件的语法是否正确
ansible-playbook nginx.yaml --list-hosts         #检查生效的主机
ansible-playbook nginx.yaml --list-task          #检查tasks任务
ansible-playbook nginx.yaml --start-at-task='Copy Nginx.conf' #指定从某 个task开始运行

3. Practical analysis

3.1. Define a remote execution user for each user (comparison between ordinary users and root users)

3.1.1, create a user set password on the node server

[root@webserver ~]# useradd lisi
[root@webserver ~]# passwd lisi
[root@webserver ~]# id lisi

3.1.2, create a playbook

[root@ansible ~]# vim demo1.yuml

[root@ansible ~]# ansible-playbook demo.yaml --syntax-check #检查语法

[root@ansible ~]# ansible-playbook demo.yaml     #执行剧本

3.1.3, modify to root user

[root@ansible ~]# ansible-playbook demo.yaml     #执行剧本

Summary: When the script is executed, permissions should also be considered, and the user performing the task

3.2, specify the remote host sudo switch user

[root@ansible ~]# vim demo.yaml

[root@ansible ~]# ansible-playbook demo.yaml --syntax-check

[root@ansible ~]# ansible-playbook demo.yaml 

[root@webserver ~]# cd /home/lisi
[root@webserver lisi]# ll /

[root@ansible ~]# vim demo.yaml    

[root@ansible ~]# ansible-playbook demo.yaml 

[root@webserver lisi]# ll

3.3. Create a case of installing apache, turning off the firewall, and visiting the homepage

[root@ansible ~]# vim demo1.yaml

[root@ansible ~]# ansible-playbook demo1.yaml --syntax-check

[root@webserver ~]# rpm -q httpd
[root@webserver ~]# systemctl status httpd

3.3.1, browser access

3.4, tasks list and action

■ The main part of Play is the task list. The tasks in the task list are executed on the hosts specified in the hosts one by one in order, that is, the first task is completed on all hosts before the second task starts when the playbook is running (from Execute from top to bottom). If a host fails to execute a task, the entire tasks will be rolled back. Please correct the error in the playbook and execute it again. The purpose of Task is to execute the module with the specified parameters, and variables can be used in the module parameters. The module is idempotent when executed, which means that multiple executions are safe because the results are consistent.

■ Each task must have a name, so that when the playbook is running, it can be easily distinguished from the task execution information it belongs to.

■ To define a task, the common format: "module: options" For example: yum: name=httpd

■ In ansible's own modules, the command module and shell module do not need to use the key=value format

3.4.1, rollback example

[root@ansible ~]# vim demo1.yaml

[root@ansible ~]# ansible-playbook demo1.yaml --syntax-check

[root@ansible ~]# ansible-playbook demo1.yaml 

[root@webserver ~]# yum -y remove httpd   #先删除httpd，再进行剧本测试
[root@webserver ~]# rpm -q httpd

Summary: Although there is an error, the command cannot be executed, but the previous command was successfully executed, and apache was successfully installed without returning, indicating that the tasks are rolled back and the error must be corrected before the execution can continue.

3.4.2. Ignore the error and force a successful test

[root@ansible ~]# vim demo1.yaml

[root@ansible ~]# ansible-playbook demo1.yaml --syntax-check
[root@ansible ~]# ansible-playbook demo1.yaml 

3.5. Do different tasks for two different nodes

[root@ansible ~]# vim demo2.yaml

[root@ansible ~]# ansible-playbook demo2.yaml --syntax-check
[root@ansible ~]# ansible-playbook demo2.yaml 

[root@mysql ~]# cd /opt
[root@mysql opt]# ll

3.6 Introduction to Handlers

Handlers are also a list of some tasks, and there is no difference from ordinary tasks
. The notify is performed by the notifier. If it is not notified, the Handlers will not be executed. If it is notified, the Handlers will be executed no matter how many notifications there are. The person has notified, and after all tasks in play are executed, the handlers will only be executed once

3.6.1, introduce variables

[root@ansible ~]# vim demo1.yaml

[root@ansible ~]# ansible-playbook demo1.yaml --syntax-check
[root@ansible ~]# ansible-playbook demo1.yaml 

3.6.2, pass variables through the ansible command

[root@ansible ~]# vim demo1.yaml

[root@ansible ~]# ansible-playbook demo1.yaml -e "aaa=httpd"

3.6.3, reference ansible's fixed variables

[root@ansible ~]# vim test.yaml
[root@ansible ~]# ansible-playbook test.yaml --syntax-check

[root@ansible ~]# ansible-playbook test.yaml

[root@mysql opt]# ll
[root@mysql opt]# cat addr.txt

3.6.4, reference host variables

Add after the host of the MySQL group

[root@ansible ~]# vim test.yaml

[root@ansible ~]# ansible-playbook test.yaml 

[root@mysql opt]# cat addr.txt

Summary: Variable usage scenario
1: The service name used in the script, Data
2: Command IP address test
3: The parameter value of the node hosts system

3.7, condition test

If you need to use variable, facts (setup) or the execution result of the previous task as a prerequisite for the execution of a task, you need to use conditional testing. In the Playbook, use the when clause and add the when clause after the task. Conditional test: when clause supports jinjia2 expression or grammar
For example:

[root@ansible ~]# vim when.yml

[root@ansible ~]# ansible-playbook when.yml --syntax-check
[root@ansible ~]# ansible-playbook when.yml

3.8, multi-condition judgment

[root@ansible ~]# vim when.yml

[root@ansible ~]# ansible-playbook when.yml --syntax-check
[root@ansible ~]# ansible-playbook when.yml

3.9. Group condition judgment

[root@ansible ~]# vim when2.yml

[root@ansible ~]# ansible-playbook when2.yml --syntax-check
[root@ansible ~]# ansible-playbook when2.yml

4. Iteration

When there are tasks that need to be performed repetitively (cycles), an iterative mechanism can be used. Its use format is to define the content to be iterated as item variable references, and specify the elements to be iterated through the with items statement

[root@ansible ~]# vim b.yml 

[root@ansible ~]# ansible-playbook b.yml --syntax-check
[root@ansible ~]# ansible-playbook b.yml

[root@webserver ~]# rpm -q httpd
[root@webserver ~]# rpm -q tomcat

4.1. Iteration (custom)

[root@ansible ~]# vim c.yml

[root@ansible ~]# ansible-playbook c.yml --syntax-check
[root@ansible ~]# ansible-playbook c.yml

[root@mysql ~]# id test1
[root@mysql ~]# id test2

4.2. Summary

Playbooks are the basis of a very simple configuration management and multi-machine deployment system, and a system that is very suitable for deploying complex applications