The 61st day of learning operation and maintenance on the road from Xiaobai to great god -------- Ansible automated operation and maintenance tool (deep understanding of playbook configuration file)

Phase 3 Basics

Time: July 14, 2023

Participants: the whole class

Contents:

playbook configuration file

Table of contents

playbook configuration file

1. The concept of playbook configuration file

Modify the hosts file

Create a playbook configuration file

Notes on yml script writing:

2. The core elements of Playbook

3. Usage of Playbook

4. Experimental case:

(1) Workflow

1. Grammar check  

2. Pre-test (most important)

3. List hosts

4. List tasks

5. List tags

6. Conduct the test (the test can be carried out after the pre-test is successful)

7. Test view

(2) Trigger

The experimental example of the handlers trigger is as follows:

Script comments:

Experiment:

1. Pre-test:

2. Execute the test:

3. Result verification


playbook configuration file

1. The concept of playbook configuration file

 The Playbook configuration file uses YAML syntax, which is concise and clear, and has a clear structure .

The Playbook configuration file is similar to a shell script and is a YAML format file used to save a task list for specific requirements;

Although the ansible commands introduced above can complete various tasks, when configuring a series of tasks, it is very inefficient to enter commands one by one. A more effective way is to configure all task codes in the playbook configuration;

Use the ansible-playbook command to execute the file, which can realize automatic operation and maintenance;

YAML files usually have the extension .yaml or .yml.

YAML syntax is similar to other high-level languages. Its structure is displayed by indentation, options are expressed by "-", and keys and values ​​are separated by colons ":". The entire file starts with "---" and ends with "..." as follows:

example:

Modify the hosts file

Modify the configuration as follows:

vim /etc/ansible/hosts

The configuration is as follows:

Create a playbook configuration file

vim /etc/ansible/test1.yml

The configuration is as follows:

Notes on yml script writing:

vim /etc/ansible/test1.yml #Create test, yml file

--- #beginning format (can be ignored)

- hosts: hu1 #Indicates the operation on test01 (192.168.59.138)

  remote_user: root #Remote execution user identity root

  tasks: #task list

    - name: adduser #task name

      user: name=user2 state=present #Execute the user module to create a user

      tags: #create tag tag

      - testa #tag tag is testa

    - name: addgroup #task name

      group: name=tests system=yes #Execute the group module to create a group account

      tags: #create tag tag

      - testb #tag tag is testb

- hosts: hu2 #Indicates the operation on test02 (192.168.59.140)

  remote_user: root #Remote execution user identity root

  tasks: #task list

    - name: copy file #task name

      copy: src=/etc/passwd dest=/home #Execute the copy module to copy files

      tags: #create tag tag

      - testc #tag tag is testsc

... #end format (can be ignored)

All "-" and ":" are followed by spaces, and attention should be paid to indentation and alignment

2. The core elements of Playbook

Include:

hosts: the target host of the task, multiple hosts are separated by colons, generally call the group information in /etc/ansible/hosts;

remote_user: On the remote host, the default for running this task is root;

tasks: task, that is, the specific task defined, the list of operations defined by the module;

handlers: triggers, similar to tasks, only trigger tasks under certain conditions. When the status of a task is changed after running, it can be notified to the corresponding handlers through "notify" to trigger execution;

roles: role, which is a specific structural collection composed of tasks, handlers, etc., by stripping hosts.

3. Usage of Playbook

The tasks defined in the Playbook file need to be invoked and executed through the ansible-playbook command. The usage of the ansible-playbook command is as follows:

Usage: ansible-playbook [option] /PATH/PLAYBOOK.yml

The functions of the [option] section include:

1.--syntax-check: Check the syntax of the yaml file;

2.-C (--check): test, will not change any configuration of the host;

3.--list-hosts: List the list of hosts affected by the yaml file;

4.--list-tasks: List the task list of the yaml file;

5.--list-tags: List the tags in the yaml file;

6. -t TAGS (--tags=TAGS): Indicates that only tasks with specified tags are executed;

7. --skip-tags=SKIP_TAGSS: Indicates that in addition to the specified tag task, perform other tasks;

8. --start-at-task=START_AT: Start running from the specified task.

4. Experimental case:

(1) Workflow

1. Grammar check  

ansible-playbook --syntax-check

/etc/ansible/test1.yml

2. Pre-test (most important)

ansible-playbook -C /etc/ansible/test1.yml

Error conditions:

Correct situation:

3. List hosts

ansible-playbook --list-hosts /etc/ansible/test1.yml

4. List tasks

ansible-playbook --list-tasks /etc/ansible/test1.yml

5. List tags

ansible-playbook --list-tags /etc/ansible/test1.yml

6. Conduct the test (the test can be carried out after the pre-test is successful)

ansible-playbook  /etc/ansible/test1.yml

7. Test view

【huyang2】tail -5 /etc/passwd  tail -5 /etc/group

【huyang3】ls /man/

  Usually, the ansible-playbook -C/PATH/PLAYBOOK.yml command is executed first for testing, and then the ansible-playbook /PATH/TO/PLAYBOOK.yml command is executed after the test is OK.

(2) Trigger

 Tasks that need to be triggered to be executed. When the tasks previously defined in tasks are executed, if you want to trigger other tasks on the basis, you need to define handlers.

For example, after the configuration file of the target host is modified through the ansible module, if the task is executed successfully, a trigger can be triggered, and the service restart operation of the target host can be defined in the trigger so that the configuration file takes effect. The handlers trigger has the following advantages :

Handlers are one of the conditional mechanisms provided by Ansible. Handlers are similar to tasks, but they will only trigger execution when they are notified by the task;

Handlers will only be executed after all tasks are executed, and even if they are notified many times, it will only be executed once, and handlers will be executed in the order defined.

The experimental example of the handlers trigger is as follows:

vim /etc/ansible/httpd.yml

The configuration is as follows:

Script comments:

--- #Fixed beginning format

- hosts: hu1 #Specify the running host as the Rich group

  remote_user: root #Specify the identity of the peer running user

  tasks: #task list

    - name: reset httpd #Define task name

      command: sed -i 's/Listen 80/Listen 8080/g' /etc/httpd/conf/httpd.conf #Module is command: use sed command to replace listening port with 8080

      notify: #Call the restart httpd server trigger after the task is completed

        - reset httpd

  handlers: #Configure triggers

    - name: reset httpd #Specify the trigger name

      service: name=httpd state=restarted #Specify the trigger condition to restart the httpd service

... #end sentence

Experiment:

1. Pre-test:

ansible-playbook -C /etc/ansible/httpd.yml

2. Execute the test:

ansible-playbook  /etc/ansible/httpd.yml

3. Result verification

 

Guess you like

Origin blog.csdn.net/2302_77582029/article/details/131748688