Ansible automated O & M playbook explanation and experience (1)

Playbook-Introduction: ansible user

Playbooks is a mode different from the ansible command line execution mode, ansible add user to group and its functions are more powerful and flexible. In simple terms, playbook is a very simple configuration management and multi-host deployment system. Unlike any existing mode, it can be used as a suitable basis for deploying complex applications. Playbook can be customized and executed in sequence according to specified operation steps. It supports synchronous and asynchronous modes. It is worth noting that playbook is described and defined in yaml format.
Playbooks structure:

 ansible user module
1. tasks: task, list of operations defined by the template 2. variables: Variable 3. templates: template, which is a file that uses the template syntax. handlers: A processor that triggers operations when certain conditions are met. roles: Role

Hosts and users: ansible create user

 



* Playbookd is designed to allow a host or some hosts to execute tasks as a user. One hosts row can be a host group, host, and multiple hosts, separated by a colon in the middle, you can use the wildcard mode. Remote_user indicates the user account for execution. * Vim/opt/ABC. yml-hosts: webserver # specifies the Host group, which can be one or more. Remote_user: Root # specify the user name for remote host execution

* Remote_user can also define the user to run commands on the managed host through sudo, or even specify the user to switch to when sudo is used by sudo_user. * Vim/opt/sudo. yml-hosts: webserver remote_user: Root become: yes # parameters later than version 2.6, which was previously sudo, meaning to switch the user to run become_user: yang # specify the sudo user as Yang * ansible-playbook sudo. yml-K # execute playbook

Ansible become user

Introduction to task list and action: ansible add user

• The main part of play is the task list. Tasks in the task list are executed on all hosts specified in hosts one by one, that is, the first task is completed on all hosts before the second task starts. When an error occurs in the middle of a playbook while running the current script, all executed tasks can be rolled back. Therefore, you can correct the playbook and execute it again. (Because of idempotence)
• The purpose of a task is to use the specified parameter execution module, while a variable can be used in the module parameters. The module execution is idempotent, which means that multiple executions are safe because the results are consistent.
• Each task should have its name, which is used to output the execution result of the playbook. We recommend that you describe the task execution steps as clearly as possible. If name is not provided, the action result is used for output.
• When defining a task, you can use the "Action: module options" format (which can be executed in a later version) or "module: Options" format. We recommend that you use the latter for backward compatibility. If a row of action contains too many content, you can use several blank characters to wrap the line at the beginning of the line.

Tasks:-Name: Make sure Apache is running service: Name = httpd state = running

• Among many modules, only the command and shell modules need to be given a list without the "Key = value" format. For example:

 



Tasks:-Name: Disable SELinux command:/sbin/setenforce 0

• If the exit code of the command or script is not 0, it may prevent the playbook from continuing to be executed as follows:

 



Tasks:-Name: Run this command and ignore the result shell:/usr/bin/somecommand |/bin/true

• That is to say, this command also needs to continue to go down, that is, the failure, but do not affect the following operations. You can also use ignore_errors to ignore the error message:

 



Tasks:-Name: Run this command and ignore the result shell:/usr/bin/somecommand ignore_errors: True

Ansible automated O & M playbook explanation and experience (1)