Ansible6:playbook simple Use "turn"

Ansbile-playbook is a collection of Ansible commands written in the Yaml language. The Playbook command executes sequentially from top to bottom. At the same time, playbook has created a number of features that allow you to transfer the state of a command to a later instruction, such as the ability to grab content from a file in a machine and attach it to a variable, and then use it in another machine, which allows you to implement some complex deployment mechanisms that the ansible command cannot achieve.

Playbook is used by the Ansible-playbook command, and its parameters are similar to the ansible command, such as parameter-K (–ask-pass) and-K (–ask-sudo) to inquire ssh password and sudo password,-u specify user, These instructions can also be written in playbook by the specified unit.

Ansible-playbook simple way to use: Ansible-playbook example-play.yml.

One a simple example

Here is a simple Ansible-playbook example that gives you an idea of its composition:

# Cat User.yml
-Name:create User
Hosts:all
User:root
Gather_facts:false
VARs
User: "Test"
Tasks
-Name:create User
User:name= "{{User}}"

The playbook implementation of the above feature is a new user:

The name parameter provides an overview of the functionality implemented by the playbook, which prints the value of the name variable during subsequent execution.

The hosts parameter specifies which hosts are to be used for the reference;

The user parameter specifies what users are using to log on to the remote host operation;

The gather_facts parameter specifies whether to execute the Setup module to obtain host-related information before the following task section executes, which is used when the subsequent task uses the information obtained by Setup;

The VARs parameter, specifying a variable, specifies a user variable whose value is test, and it is important to note that the value of the variable must be quoted in quotation marks;

Tasks specify a task, and the following name parameter is also a description of the task, which is printed during execution. User has set the call to the user module, name is a parameter in the user module, and the added user name calls the value of the above username.

Similarly, if you want to implement deleting this new user, simply replace the last line of the playbook file with the following line and perform the corresponding playbook:

User:name= "{{user}}" state=absent Remove=yes

II. Installing the Apache sample via Playbook

The Ansible-playbook enables simultaneous installation of Apache on multiple hosts simultaneously. It is important to note that multiple managed hosts may not have the same operating system, resulting in different Apache package names, assuming that there are both CentOS and Debian two operating systems, the specific playbook content is as follows:

# Cat Install_apache.yml
-Hosts:all
Remote_user:root
Gather_facts:true
Tasks
-Name:install Apache on CentOS
YUM:NAME=HTTPD state=present

-Name:install Apache on Debian
Yum:name=apache2 state=present
when:ansible_os_family = = "Debian"

It uses the When statement and also opens the Gather_facts Setup module, where the ansible_os_family variable and the information obtained from the directly used Setup module. If you have a large number of hosts, just add-f at run time and select a suitable number of concurrent hosts.

Third, the composition of playbook

Playbook is a list of one or more "play" components. The main function of play is to dress up a pre-set host as a role defined in advance through the task in ansible. Fundamentally, the so-called task is nothing more than a module called Ansible. Having multiple play organizations in one playbook allows them to join together to sing a drama with a pre-programmed mechanism. It mainly consists of the following four parts:

Playbooks Composition:
Target section: Defines the remote host group that will execute the playbook
Variable section: Defining variables to be used by the Playbook runtime
Task section: Define a list of tasks that will be performed on the remote host
Handler section: Defines a task that needs to be called after task execution completes

and its corresponding directory layer is five, as follows:

Generally required directory layer is: (depending on the situation can vary)
VARs variable Layer
Tasks Task Layer
Handlers trigger conditions
Files file
Template templates

1. Hosts and users

The purpose of each play in playbook is to have some or some hosts perform tasks as a specified user.

Hosts: Used to specify the host to perform the specified task, which can be one or more separate host groups by colons.

Remote_user: Used to specify the user who performed the task on the remote host. However, Remote_user can also be used in each task. You can also perform tasks on a remote host by specifying that it is available for play global or a task by sudo. In addition, you can even use Sudo_user to specify the user to switch when sudo is specified.

User: Same as Remote_user

sudo: If set to Yes, the user performing the task group gets root privileges when performing a task

Sudo_user: If you set user to Breeze,sudo to Yes,sudo_user as Bernie, Breeze users will get Bernie user privileges when performing tasks

Connection: How to connect to a remote host by default SSH

Gather_facts: Unless explicitly stated that the Setup module does not need to be executed on a remote host, it is automatically executed by default. If you do not need the variables passed by the Setup module, you can set this option to False

Example:

-Hosts:webnodes
Tasks
-Name:test Ping Connection:
Remote_user:test
Sudo:yes

2. Task List and action

The main part of play is the task list.

Each task in the task list executes sequentially on all hosts specified in the hosts, after the first task is completed on all hosts, and then the second one begins. When you run a playbook from the top down, if an error occurs halfway through, all of the executed tasks are rolled back so you can do it again after correcting playbook.

The purpose of the task is to execute the module with the specified parameters, and the 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 its name execution result output for playbook, suggesting that its contents describe the task execution steps as clearly as possible. If name is not supplied, the result of the action is used for the output.

You can use the Action:module options or module:options format to define a task, which is recommended for backwards compatibility. If the action line has too much content, you can use a few white-space characters at the beginning of the line to wrap.

Tasks
-Name:make sure Apache is running
SERVICE:NAME=HTTPD state=running

#在众多模块中只有command和shell模块仅需要给定一个列表而无需使用 "Key=value" format for example
Tasks
-Name:disable SELinux
Command:/sbin/setenforce 0

#如果命令或脚本的退出码不为零可以使用如下方式替代
Tasks
-Name:run This command and ignore the result
Shell:/usr/bin/somecommand | | /bin/true

#使用ignore_errors来忽略错误信息
Tasks
-Name:run This command and ignore the result
Shell:/usr/bin/somecommand

3, handlers

Used to take certain actions when the resources being followed are changed.
The "Notify" action can be used to trigger at the end of each play, which avoids having to perform the specified action every time a change occurs, instead of performing the specified operation only once all changes have been completed.
The actions that are listed in notify are called Handler, which is called notify in the actions defined in handler.

Note: Defining content in notify must be the same as the-name content defined in tasks to achieve the effect of the trigger, otherwise it will not take effect.

-Name:template configuration file
Template:src=template.j2 dest=/etc/foo.conf
Notify
-Restart memcached
-Restart Apache

#handler是task列表这些task与前述的task并没有本质上的不同.
Handlers:
-Name:restart memcached
Service:name=memcached state=restarted
-Name:restart Apache

4. Tags

Tags are used to let the user choose to run or skip over some of the code in playbook. The ansible is idempotent, so it will automatically skip the unchanged parts, even though some code will be very long to test that it really hasn't changed. At this point, if you are sure that it has not changed, you can skip these snippets through tags.

5. Example

An example of installing the HTTPD Web service:

 # cat/etc/ansible/playbook/install_web.yml 
-hosts:webservers 
  remote_user:root 
  gather_ Fasks:false 
  vars: 
    PACKAGES:HTTPD 
  tasks:    -name:install httpd   &N Bsp  yum:name={{Packages}} state=present-name:cofiguration httpd      copy:src=/root/httpd.conf dest =/etc/httpd/conf/httpd.conf      tags:httpd_conf        notify:        -Restart Httpd-name:start httpd      SERVICE:NAME=HTTPD state=started enabled=no     &NB Sp;tags:start-name:add CentOS user      user:name={{item}} state=absent      tags:addu Ser      with_items:        -CentOS        -admin     & Nbsp;handlers:        -Name:restart httpd          SERVICE:NAME=HTTPD stat E=restart 

This article is from the "Nobody" blog, please be sure to keep this source http://breezey.blog.51cto.com/2400275/1757624

Ansible6:playbook simple Use "turn"