Shulou(Shulou.com)06/01 Report--

Automatic operation and maintenance tool ansible how to use, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

Text

Back to the top.

Introduction to Ansible playbook

Playbook is the script that ansible uses to configure, deploy, and manage controlled nodes.

Through the detailed description of playbook, a series of tasks can be executed to make the remote host achieve the desired state. Playbook is like a series of to-do-list listed by the Ansible controller to the controlled node, and the controlled node must be completed.

It can also be understood that the literal meaning of playbook, or script, is actually performed by actors according to the script. In Ansible, this time it is performed by computers, installed by computers, deployed by applications, providing external services, and organizing computers to handle all kinds of things.

Back to the top.

Ansible playbook usage scenario

To perform some simple tasks, using the ad-hoc command can easily solve the problem, but sometimes when a facility is too complex and requires a lot of operations, the ad-hoc command is not appropriate, so it is best to use playbook.

Just like executing shell commands and writing shell scripts, it can be understood as a batch task, but playbook has its own syntax format.

With playbook you can easily reuse this code and migrate it to different machines, like functions, to maximize the use of code. In the process of using Ansible, you will also find that most of the operations you deal with are writing playbook. Common applications can be written as playbook, after which it becomes very easy to manage the server.

Back to the top.

Ansible playbook format 1) introduction to the format

Playbook is written in the YMAL language. YAML made reference to a variety of other languages, including XML, C, Python, Perl, and the e-mail format RFC2822,Clark Evans, which was first published in May 2001. Ingy d ö t Net and OrenBen-Kiki are also co-designers of the language.

YMAL format is similar to JSON file format, easy for people to understand and read, and easy to write. First of all, learn to understand the format of YMAL, which is very helpful for us to write playbook. The following are the YMAL formats commonly used by playbook:

1. The first line of the file should start with "- -" (three hyphens), indicating the beginning of the YMAL file.

2. On the same line, the content after # represents a comment, similar to shell,python and ruby.

3. The list element in YMAL begins with a "-" followed by a space, followed by the element content.

4. Elements in the same list should remain the same indentation. Otherwise, it will be treated as an error.

5. The representation of objects such as hosts,variables,roles,tasks in play is represented by a ":" separation between the key values, followed by a space.

Here is an example:

-# install and run the mysql service-hosts: node1 remote_user: root tasks:-name: install mysql-server package yum: name=mysql-server state=present-name: starting mysqld service service: name=mysql state=started

Our file name should end with .yml, as in our example above is mysql.yml. Among them, there are three parts:

Host section: use hosts to indicate which host or host group to use to run the following tasks, each playbook must specify hosts, hosts can also use wildcard format. The host or host group is specified in the inventory list. You can use the system default / etc/ansible/hosts, or you can edit it yourself. Add the-I option at run time to specify the location of the list. When running the manifest file, the-list-hosts option shows which hosts will participate in the execution of the task.

Remote_user: specify which user in the remote host logs in to the remote system. Users who execute task on the remote system can specify or use sudo at will, but the user must have the right to execute the corresponding task.

Tasks: specifies a series of actions to be performed by the remote host. The core of tasks is the module of ansible, and the usage of the module has been mentioned earlier. Tasks contains name and the module to be executed. Name is optional only for users to read, but it is recommended to add it. The module is required and the corresponding parameters should be given to the module.

Run the playbook file using ansible-playbook to get the following output, which is in JSON format. And it is composed of different colors, so it is easy to identify. Generally speaking

| | Green means the execution is successful and the system remains intact |

| | Yellow indicates that the system status has changed. |

| | Red indicates execution failed and error output is displayed |

There are three steps to implement: 1. Collect facts 2, execute tasks 3, and report the results.

2) Core elements

The core elements of Playbook:

Hosts: host group

Tasks: task list

Variables: variable, which can be set in four ways

Templates: a text file that contains template syntax

Handlers: a task triggered by a specific condition

3) basic components

The basic components of the Playbooks configuration file:

Hosts: the target host running the specified task

Remoute_user: the user who performs the task on the remote host

Sudo_user:

Tasks: task list

Format:

Tasks:

-name: TASK_NAME

Module: arguments

Notify: HANDLER_NAME

Handlers:

-name: HANDLER_NAME

Module: arguments

Module, module parameters:

Format:

(1) action: module arguments

(2) module: arguments

Note: the shell and command modules are followed directly by commands, not the parameter list of the key=value class

Handlers: task, triggered under certain conditions; triggered when notification of other tasks is received

(1) when the status of a task is changed after running, you can notify the corresponding handlers through "notify".

(2) the task can be labeled with "tags", and then can be called with-t specified on the ansible-playbook command.

Give an example

① defines playbook

[root@server ~] # cd / etc/ansible [root@server ansible] # vim nginx.yml---- hosts: web remote_user: root tasks:-name: install nginx yum: name=nginx state=present-name: copy nginx.conf copy: src=/tmp/nginx.conf dest=/etc/nginx/nginx.conf backup=yes notify: reload # when nginx.conf changes Tag the corresponding handlers tags: reloadnginx #-name: startnginx service service: name=nginx state=started tags: startnginx # handlers: # Note, there are no -, there are two spaces-name: reload service: name=nginx state=restarted # in order to see it in the process

② test run results

When we're done, we can run:

[root@server ansible] # ansible-playbook nginx.yml

Now we can see if the ports of the two machines are open:

[root@server ansible] # ansible web-m shell-a'ss-nutlp | grep nginx'192.168.37.122 | SUCCESS | rc=0 > > tcp LISTEN 0128 *: 80 *: * users: ("nginx", pid=8304,fd=6), ("nginx", pid=8303 Fd=6)) 192.168.37.133 | SUCCESS | rc=0 > > tcp LISTEN 0128 *: 80 *: * users: ("nginx", pid=9671,fd=6), ("nginx", pid=9670,fd=6))

③ test tag

We have already put a tag in it, so we can refer to the tag directly. But we need to shut down the service before running the script and referencing the tag:

[root@server ansible] # ansible web-m shell-a 'systemctl stop nginx' [root@server ansible] # ansible-playbook nginx.yml-t startnginx

④ Test notify

We also made a notify to test it:

First of all, it is triggered by a change in the configuration file, so let's change the port in the configuration file:

[root@server ansible] # vim / tmp/nginx.conf listen 8080

Then let's reload the script:

It is found that what we are executing is the reload section and the notify part that we defined.

Let's take a look at our port number:

[root@server ansible] # ansible web-m shell-a'ss-ntlp | grep nginx'192.168.37.122 | SUCCESS | rc=0 > > LISTEN 0128 *: 8080 *: * users: ("nginx", pid=2097,fd=6), ("nginx", pid=2096 Fd=6)) 192.168.37.133 | SUCCESS | rc=0 > > LISTEN 0128 *: 8080 *: * users: ("nginx", pid=3061,fd=6), ("nginx", pid=3060,fd=6))

As you can see, our nginx port has become 8080.

4) variables part

Above, we mentioned that variables is a variable, and there are four ways to define it. Now let's talk about these four methods of definition:

① facts: can be called directly

In the previous article, we talked about the setup module, which is implemented by calling the facts component. Our variables here can also call the facts component directly.

We can use the setup module to obtain the specific facters, and then directly put it into our script and call it.

② user-defined variables

We can also use user-defined variables directly. There are two ways to customize variables:

Passed in through the command line

-e VARS,-- extra-vars=VARS on the command line of the ansible-playbook command, so you can pass in custom variables directly.

Define variables in playbook

We can also define our variables directly in playbook:

Vars:-var1: value1-- var2: value2 example

① defines screenplay

Let's use global substitution to modify the file we just edited:

[root@server ansible] # vim nginx.yml

In this way, our script definition is complete.

② copy configuration file

If we want to install a service on a regulated machine, copy the configuration file of the service directly on our server side to our / tmp/ directory. So that our script can work properly.

Let's take the keepalived service as an example:

[root@server ansible] # cp / etc/keepalived/keepalived.conf / tmp/keepalived.conf

③ runs the script, and variables are passed in from the command line

[root@server ansible] # ansible-playbook nginx.yml-e rpmname=keepalived

④ modifies the script to define variables directly

Similarly, we can define the variable directly in the script so that it does not need to be passed in through the command line. If you want to install different services in the future, just modify the variables in the script.

[root@server ansible] # vim nginx.yml

⑤ runs a script with defined variables

We just defined the variable in the script. Now let's give it a try:

[root@server ansible] # ansible-playbook nginx.yml

It is found that this is also possible.

③ passes variables through roles

Specifically, we will explain it in detail when we talk about roles below. This is the conveyor belt.

④ Host Inventory

We can also define it directly in the host list.

The method of definition is as follows:

Pass different variables to different hosts:

IP/HOSTNAME varaiable=value var2=value2

Pass the same variable to the hosts in the group:

[groupname:vars] variable=value5) template templates

A template is a text file with a script nested (written in a template programming language).

Jinja2:Jinja2 is a template language of python, based on the template language of Django.

Template support:

Strings: using single or double quotation marks

Numbers: integer, floating point number

List: [item1, item2,...]

Tuple: (item1, item2,...)

Dictionary: {key1:value1, key2:value2,...}

Boolean: true/false

Arithmetic operation:

+, -, *, /,%, * *

Comparison operation:

= =,! =, >, >, tcp LISTEN 0 128 *: 9999 *: * users: ("nginx", pid=7831,fd=6), ("nginx", pid=7830,fd=6), ("nginx", pid=7829) Fd=6)) 192.168.37.133 | SUCCESS | rc=0 > > tcp LISTEN 0128 *: 9999 *: * users: ("nginx", pid=9654,fd=6), ("nginx", pid=9653,fd=6), ("nginx", pid=9652,fd=6))

It can be seen that our script has been successfully executed.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.