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

A brief introduction to Playbook

The playbook configuration file uses YAML syntax and has the characteristics of conciseness and clear structure. The playbook configuration file, similar to the shell script, is an YAML format file that holds a list of tasks for specific needs. Although the ansible command described above can accomplish a variety of tasks, it is very inefficient to type one by one when configuring some complex tasks. A more efficient solution is to place all the task codes in the playbook configuration file, which can be automated by executing the file with the ansible-playbook command. YAML files usually have a .yaml or .yml extension.

II. The core elements of playbook

The core elements of playbook include:

Hosts: the target host of the task. Multiple hosts are separated by colons. The grouping information in / etc/ansible/hosts is generally called. Remote_user: on the remote host, the default identity to run this task is root. Tasks: a task, a specific task defined, a list of actions defined by a module. Handlers: triggers, like tasks, tasks that are triggered only under certain conditions. When the status of a task is changed after running, it can trigger execution by notifying the corresponding handlers through "notify". Roles: role, stripping out hosts, a specific set of structures made up of tasks, handlers, and so on.

III. Playbook format

Playbook needs to pay attention to:

Playbook is written in the YMAL language. YAML refers to many other languages, including XML, C, Python, Perl, and so on. MAL format is similar to JSON file format, easy for people to understand and read, and easy to write. Items are represented by "-", keys and values are separated by colons, and the whole file starts with "-" and begins with "." End. All "-" and ":" are followed by spaces, and pay close attention to indentation and alignment, otherwise the grammar may report errors. Be sure to use the "- C" option for pre-testing each time before executing the playbook file. This option executes the playbook file once, but no changes are made to the target host, and an error message will be reported if the syntax is incorrect or a file is missing from the target host.

1. Execute a simple playbook file:

[root@ansible ~] # grep-v ^ # / etc/ansible/hosts | grep-v ^ $# View the grouping information in hosts [web1] 192.168.1.2 [web2] 192.168.1.3 [root @ ansible ~] # vim / etc/ansible/a.yml # create an a.yml file Write the following-hosts: web1 # for the operation in the web1 group remote_user: root # remote execution user as root tasks: # Task list-name: adduser # Task name user: name=user1 state=present # execute user module Create user tags: # create tag tag-aaa # tag tag as aaa-name: addgroup # Task name group: name=root system=yes # execute group module Create group tags: # create tag tag-bbb # tag tag is bbb- hosts: web2 # for operations in web2 group remote_user: root # remote execution user identity is root tasks: # Task list-name: copy file To web # Task name copy: src=/etc/passwd dest=/home # execute copy module Copy the file tags: # create a tag tag-ccc # tag tag as ccc...

The playbook file I wrote here is as follows:

The tasks defined in the playbook file need to be invoked and executed through the ansible-playbook command, which is used as follows:

[root@ansible ~] # ansible-playbook [option] / etc/ansible/a.yml where the functions in option include: *-- syntax-check: detect the syntax of the yaml file. *-C: pre-test will not change any settings of the target host. *-- list-tasks: lists the tasks for the yaml file. *-- list-hosts: lists the hosts affected by the yaml file. *-- list-tags: lists the tags in the yaml file. *-t TAGS: indicates that only tasks with the specified tag are performed. *-- skip-tags=SKIP_TAGS: indicates the task with the specified tag and performs other tasks. *-- start-at-task=START_AT: run down from the specified task.

An example of executing a.yml files is as follows:

[root@ansible ~] # ansible-playbook-- syntax-check / etc/ansible/a.yml # Syntax Detection playbook: / etc/ansible/a.yml # indicates no error [root@ansible ~] # ansible-playbook-C / etc/ansible/a.yml # pre-tests a.yml. # Omit part 192.168.1.2: ok=3 changed=1 unreachable=0 failed=0 192.168.1.3: ok=2 changed=1 unreachable=0 failed=0 # returned result indicates no error All can be executed successfully. [root@ansible ~] # ansible-playbook-- list-hosts / etc/ansible/a.yml # list the hosts in the a.yml file [root@ansible ~] # ansible-playbook-- list-tasks / etc/ansible/a.yml # list tasks [root@ansible ~] # ansible-playbook-- list-tags / etc/ansible/a.yml # list the label [root@ansible ~] # ansible-playbook / etc/ansible/a.yml # execute Task [root@ansible ~] # ssh 192.168.1.2 tail-1 / etc/passwd # confirm the execution result user1:x:1001:1001::/home/user1:/bin/bash [root@ansible ~] # ssh 192.168.1.3 ls-ld / home/passwd-rw-r--r--. 1 root root 2342 July 23 16:06 / home/passwd# generally execute the "- C" command for pre-testing, and then execute the .yml file after there is no problem.

There is an online ansible-playbook grammar testing tool that can more intuitively check out grammar errors. If you are interested, you can take a look at: http://www.yamllint.com/

2. Trigger

A task that needs to be triggered to execute. If you want to trigger other tasks on the basis of the successful execution of the previous task in tasks, you need to define a handlers. For example, when the configuration file of the target host is modified through the module of ansible, if the task executes successfully, a trigger can be triggered to define the service restart operation of the target host in the trigger so that the configuration file takes effect. Handlers triggers have the following characteristics:

Handlers is one of the conditional mechanisms provided by ansible. Handlers is similar to task, but it only triggers execution when it is notified by task. Handlers will only be executed after all tasks have been executed. And even if it is notified many times, it will only be executed once.

Examples of use of handlers triggers are as follows:

[root@ansible ~] # ssh 192.168.1.2 netstat-anpt | grep 80 # query the port tcp6 0 0:: 80: * LISTEN 94858/httpd # on which the host is listening. You can see that it is listening on port 80. Now change it to port 8080 through script and make it effective. [root@ansible ~] # vim / etc/ansible/httpd.yml # Edit httpd.yml file Write the following content-hosts: web1 remote_user: root tasks:-name: change port command: sed-I 's/Listen\ 80/Listen\ 8080amp g' / etc/httpd/conf/httpd.conf notify: # configure the trigger condition-restart httpd server # after completing the task, call the name Trigger for "restart httpd server" handlers: # configure trigger-name: restart httpd server # specify the trigger name Service: name=httpd state=restarted # triggers the task to restart the httpd service as the trigger name specified by "notify" above. . # after the writing is completed, save and exit. [root@ansible] # ansible-playbook-C / etc/ansible/httpd.yml # for pre-testing. [root@ansible ~] # ansible-playbook / etc/ansible/httpd.yml # execute the script. [root@ansible ~] # ssh 192.168.1.2 netstat-anpt | grep 8080 # remote host has been running port 8080 tcp6 0: 8080:: * LISTEN 103594/httpd

3. Role

If you store a variety of different tasks files in a directory, that directory is the role. Roles are generally stored in the / etc/ansible/roles/ directory, and the default role directory can be adjusted through the configuration file of ansible. There are many subdirectories under the / etc/ansible/roles/ directory, each of which corresponds to a role, and each role has its own directory structure as follows:

/ etc/ansible/roles/ is a collection of roles, and there are custom subdirectories under this directory:

Mariadb:mysql role. Apache:httpd role. Nginx:Nginx role. The definition of each role is organized in a specific hierarchical directory structure. Take mariadb (mysql role) as an example: files: stores files called by modules such as copy or script. Templates: the directory where the template files that the template module needs to find are stored, such as the mysql configuration file template. Tasks: the directory where the task is stored. Handlers: stores the directory that triggers the execution. Vars: the directory where the variables are stored. Meta: used to store this role's metadata. Default: the directory where the default variables are stored, and the default variables used by this role are defined in the file.

In the above directory, tasks, handlers, vars, meta, default should contain at least one main.yml file, and there can also be other .yml files, but you need to include other .yml files in the main.yml file with the include directive.

.

Once you have a role, you can invoke the role directly in the yaml file (playbook configuration file), as shown in the following example:

-hosts: web1 remote_user: root roles:-mysql # call role name-httpd # call character name.

You can call only one role, or you can call multiple roles, and when the role is defined, you can execute it with the ansible-playbook PALYBOOK file. At this point, ansible will go to the role collection directory (/ etc/ansible/roles) to find the mysql and httpd directories, and then run all the code in the mysql and httpd directories in turn.

.

Here is an example of installing and configuring a mariadb database:

Requirements Analysis:

It is required to automatically install mariadb on the managed host, upload the prepared configuration file to the remote host after the installation is completed, restart the service, then create a new testdb database, and allow test users to have all permissions on it. The managed host configures the yum warehouse and configures it on its own. If the managed end can connect to the Internet, then point the yum warehouse directly to the Internet.

Start implementing on the ansible server:

[root@ansible /] # mkdir-pv / etc/ansible/roles/mariadb/ {files,tasks Handlers} mkdir: created directory "/ etc/ansible/roles/mariadb" mkdir: created directory "/ etc/ansible/roles/mariadb/files" mkdir: created directory "/ etc/ansible/roles/mariadb/tasks" mkdir: created directory "/ etc/ansible/roles/mariadb/handlers" [root@ansible /] # cd / etc/ansible/roles/mariadb/tasks/ # switch to the specified directory [root@ansible tasks ] # ls [root@ansible tasks] # vim main.yml # write main.yml file-name: install mariadb yum: name=mariadb-server state=present- name: move config file shell: "[- e / etc/my.cnf] & & mv / etc/my.cnf / etc/my.cnf.bak"-name: provide a new config file copy: src=my.cnf dest=/etc/my.cnf- name: reload mariadb shell: systemctl restart mariadb- name: create Database testdb shell: mysql-u root-e "create database testdb Grant all on testdb.* to 'test'@'192.168.1.%' identified by' test123';flush privileges; "notify:-restart mariadb...# has been written, save and exit. [root@ansible tasks] # cd.. / handlers/ # change to the trigger directory [root@ansible handlers] # vim main.yml # to write the main.yml file, write the following content-name: restart mariadb service: name=mariadb state=restarted...#, save and exit. [root@ansible handlers] # cd.. / files # enter the files [root@ansible files] # pwd/etc/ansible/roles/mariadb/files [root@ansible files] # ls # of the mariadb role folder to prepare the configured mysql database configuration file The my.cnf [root@ansible files] # cd / etc/ansible/ [root@ansible ansible] # vim mariadb.yml # that needs to be distributed to the remote host is written .yml file-hosts: web remote_user: root roles:-mariadb...## has been written, and you can save and exit. [root@ansible ansible] # ansible-playbook-C mariadb.yml # for pre-detection. # omit part of the content PLAY RECAP * 192.168.1.2: ok=3 changed=1 unreachable=0 failed=0 # returned result indicates no problem [root@ Ansible ansible] # ansible-playbook mariadb.yml # perform installation

After the installation is complete, check on the remote host to see if the testdb database has been created, and test it by logging in as a test user.

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.