Use of Ansible automated operation and maintenance tool playbook (2)

playbook

Playbook introduction

A playbook is a list of one or more ansible modules. The main function of the playbook is to pretend a set of pre-defined hosts as roles defined by the tasks in ansible. The task actually calls a module of ansible to organize the tasks in a playbook, so that they can be united. Get up and execute the predefined actions according to the pre-arranged mechanism. The playbook file is written in yaml format.

playbook command

format:

ansible-playbook <filename.yaml> [options]

Common options:

Options Detailed
–C、–check Pre-execution, not really executed, used to detect whether the playbook is wrong
–list-hosts List hosts running tasks
–list-tags List tags
–list-task List tasks
–limit Execute only for hosts in the host list
-t Specify to execute a tag
-v, -vv Show execution process

Playbook core components

  • hosts: The list of remote hosts on which the task is executed
  • tasks: task set
  • variables: built-in variables or custom variables are called in the playbook
  • templates: templates, files that can replace variables in template files and implement some simple logic
  • Handlers and notify: operations initiated by specific conditions are executed only when the conditions are met, otherwise they are not executed
  • tags: Tags, specify a certain task execution, used to select part of the code in the playbook to run.

Core component usage

hosts component

hosts: The purpose of each paly in the playbook is to allow a specific host to perform tasks as a specified user. Hosts are used to specify the host to perform the specified task, which must be defined in the host list in advance (/etc/ansible/hosts)

[nginx]
192.168.0.182
[httpd]
192.168.0.178
[web]
192.168.0.178
192.168.0.182
[ssh]
192.168.0.178:22

Playbook case:

- hosts: httpd
- host: web:!nginx

remote_user component

remote_user: can be used in host and task. You can also specify it to perform tasks on the remote host through sudo, which can be used for paly, global, or a task; in addition, you can use sudo_user to specify the user to switch when sudo is used.

Playbook case:

- hosts: web
  remote_user: root
  tasks:
    - name: test connection
      ping:
      remote_user: test
      sudo: yes
      sudo_user: usertest

task list and action component

The main part of the playbook is the task list, which contains one or more tasks, and each task is executed on all hosts specified in the hosts one by one, that is, the second task is started after the first task is completed on all hosts.
The purpose of the task is to execute the module with the specified parameters, and variables can be used in the module parameters. Module execution is idempotent, which means that multiple executions are safe because the results are consistent.
Each task should have a name, which is used to output the execution result of the playbook. It is recommended that its content clearly describes the task. If the name is not provided, the result of the action will be used for output.

Two formats of task:

  1. action:module arguments
  2. module: arguments are recommended.
    Note: shell and command modules are followed by commands, not key=value
    examples:
- hosts: web
  remote_user: root
  tasks:
    - name: install web service
      yum: name=httpd
    - name: start web service
      service: name=httpd state=started enable=yes
- hosts: web
  remote_user: root
  tasks:
    - name: ls file
      shell: ls /opt/

Write a simple playbook

- hosts: web
  remote_user: root
  tasks:
    - name: "安装httpd服务"
      yum: name=httpd
    - name: "复制配置文件"
      copy: src=/opt/httpd.conf dest=/etc/httpd/conf/
    - name: "复制主页文件"
      copy: src=/opt/index.html dest=/var/www/html/
    - name: "启动服务"
      service: name=httpd state=started enable=yes

Use handlers and notify in playbook

The handler is essentially a task list, similar to the behavior triggered by a trigger in MySQL. The task is not essentially different from the aforementioned task. It is mainly used to take certain actions when the resource of interest changes. The action corresponding to notify can be used to be triggered at the end of each play, which can avoid performing the same operation every time when multiple changes occur, and only perform the specified operation once after all changes have occurred. The operations listed in notify are called handlers, that is, the operations defined in handler are called in notify.
example:

- hosts: web
  remote_user: root
  tasks:
    - name: "安装httpd服务"
      yum: name=httpd
    - name: "复制配置文件"
      copy: src=/opt/httpd.conf dest=/etc/httpd/conf/
    - name: "复制主页文件"
      copy: src=/opt/index.html dest=/var/www/html/
      notify: restart httpd
    - name: "启动服务"
      service: name=httpd state=started enable=yes
  handlers:
    - name: restart httpd
      service: name=httpd state=restart

By executing this playbook again to change the configuration file of the httpd service, notify will listen, and when the configuration file is changed, the handlers named restart httpd will be executed

Use of tags in playbook

In the playbook, the tags component can be used to specify tags for specific tasks. When the playbook is executed again, the task of a certain tags can be specified for execution instead of executing the entire playbook.

example:

- hosts: web
  remote_user: root
  tasks:
    - name: "安装httpd服务"
      yum: name=httpd
    - name: "复制配置文件"
      copy: src=/opt/httpd.conf dest=/etc/httpd/conf/
    - name: "复制主页文件"
      copy: src=/opt/index.html dest=/var/www/html/
      tags: conf
      notify: restart httpd
    - name: "启动服务"
      service: name=httpd state=started enable=yes
  handlers:
    - name: restart httpd
      service: name=httpd state=restart
ansible-play -t conf http.yaml

Use variables in the playbook

Variable names can only be composed of letters, numbers and underscores, and can only start with a letter

example:

http_port=80

How to call the variable: call the variable through { {http_port }}, pay attention to the space before and after the curly braces, sometimes use "{ {http_port }}" to call to take effect

  • Define variable method

Define variables via the command line:

ansible-playbook -e http_port=80
  • Define variables in the playbook
- hosts: web
  remote_user: root
  gather_facts: no
vars:
  - http_port: 80
  - name: httpd
  tasks:
    - name: "安装httpd服务"
      yum: name=httpd
    - name: "复制配置文件"
      copy: src=/opt/httpd.conf dest=/etc/httpd/conf/
    - name: "复制主页文件"
      copy: src=/opt/index.html dest=/var/www/html/
      tags: conf
      notify: restart httpd
    - name: "启动服务"
      service: name=httpd state=started enable=yes
  handlers:
    - name: restart httpd
      service: name={
    
    {
    
     name }} state=restart

Use of when in playbook

When in the playbook is used to judge whether the execution condition is met, if it is met, it will be executed, if it is not met, it will be skipped.
Example:

- hosts: db
  remote_user: root
  tasks:
    - name: install mysql-server
      yum: name=mysql-server
      when: {
    
    {
    
     ansible_distribution_major_version }} == 6
    - name: install mariadb-server
      yum: name=mariadb-server
      when: {
    
    {
    
     ansible_distribution_major_version }} == 7

Use of with_items in playbook

With_items in the playbook can quickly iteratively update repeated variables, such as adding users in batches, downloading software in batches, where items can be lists or dictionaries.
Example:

- hosts: db
  remote_user: root
  tasks:
    - name: add user
      user: name={
    
    {
    
     item }} state=present
      with_items:
        - testuser1
        - testuser2
- hosts: db
  remote_user: root
  tasks:
    - name: add user
      user: name={
    
    {
    
     item.name }} state=present group={
    
    {
    
     item.group }}
      with_items:
        - {
    
    name: 'user1',group: 'system'}
        - {
    
    name: 'user2',group: 'system'}

Guess you like

Origin blog.csdn.net/qq_33235529/article/details/114529342