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

This article shows you how to analyze the automatic operation and maintenance of Ansible, the content is concise and easy to understand, it will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

I. Overview of Ansible

Ansible is a more and more popular open source operation and maintenance automation tool in recent years. Ansible can realize operation and maintenance automation, improve the work efficiency of operation and maintenance engineers, and reduce human errors.

Ansible can achieve a variety of management tasks through its own integration of very rich modules, with more than thousands of modules. More importantly, it is very simple to operate, even rookies can easily get started, but it provides very rich functions, in the field of operation and maintenance, it can do almost anything.

1. Characteristics of Ansible

Since its release in 2012, Ansible has quickly become popular around the world, with the following characteristics:

Ansible is developed based on Python, and it is relatively easy for operation and maintenance engineers to redevelop it.

Ansible's rich built-in modules can meet almost all requirements.

The management mode is very simple. A single command can affect thousands of hosts.

Clientless mode, the underlying layer communicates through SSH

After the release of Ansible, it has been accepted and put into use by AWS, Google Cloud Platform, Microsoft Azure, Cisco, HP, VMware, Twitter and other big companies.

II. The role of Ansible

User: how to use Ansible to automate operation and maintenance?

Ansible toolset: what functions can be achieved by Ansible?

Target: which hosts can be affected by Ansible?

1. Users

The following figure shows that Ansible users can interact with Ansible in a variety of ways, four of which are shown in the figure:

CMDB:CMDB stores and manages the configuration information in the enterprise IT architecture, which is the core tool for building ITIL projects. Operators can combine CMDB and Ansible and directly issue instructions through CMDB to call the Ansible toolset to achieve the desired goals of the operator.

PUBLIC/PRIVATE mode: in addition to rich built-in modules, Ansible also provides rich API language interfaces, such as PHP, Python, PERL and other popular languages, which can be run as API calls based on PUBLIC/PRIVATE,Ansible.

Ad-Hoc command set: Users calls the Ansible tool set directly through the Ad-Hoc command set to complete the task

Playbooks:Users prepares the Ansible Playbooks by executing

A pre-scheduled task set in Playbooks that executes tasks sequentially.

2. Ansible tool set

The Ansible toolset contains Inventory, Modules, Plugins, and API.

Among them: Inventory: used to manage the list of devices, which can be implemented by grouping, and the call to the group directly affects all the hosts in the group; Modules: a variety of execution modules, almost all management tasks are performed through the module; Plugins: provides a variety of additional functions; API: provides an interface for programmers, based on which you can do secondary development of Ansible. The details are as follows:

Ansible Playbooks: task script, orchestration of configuration files that define Ansible tasks and are executed sequentially by Ansible, usually YML files in JSON format

Inventory:Ansible management host list

Modules:Ansible command execution function module, most of which are built-in core modules and can also be customized

Plugins: a supplement to module functions, such as connection type plug-ins, loop plug-ins, variable plug-ins, filter plug-ins, etc., which are not commonly used.

API: an application programming interface for third party programs to call

Ansible: it is not obvious in this part of the diagram. The combination of Inventory, API, Modules and Plugins can be understood as an Ansible command tool, which is the core execution tool.

3. Object of action

The role of Ansible is not only for Linux and non-Linux operating system hosts, but also for all kinds of PUBLIC/PRIVATE, commercial and non-commercial equipment network facilities.

When a user uses Ansible or Ansible-Playbooks, after the server terminal enters the Ad-Hoc command set or Playbooks of Ansible, Ansible will follow the rules of pre-selection arrangement to disassemble Playbooks into Play step by step, then organize Play into tasks that Ansible can recognize, then call all modules and plug-ins involved in the task, transfer the task set to the remote client in the form of temporary files or commands through SSH according to the host list defined in Inventory and return the execution result If it is a temporary file, it will be deleted automatically after execution.

III. Configuration of Ansible

1. Ansible installation

The installation and deployment of Ansible is very simple. Take RPM installation as an example, its dependent software is only Python and SSH, and the system is installed by default. The management side of Ansible can only be Linux, such as Redhat, Debian, Centos.

1) install Ansible through YUM

You can download the required software packages for Ansible directly from the Internet. This blog provides dependent software packages needed to install Ansible automated operation and maintenance tools.

[root@centos01 ~] # cd / mnt/ansiblerepo/ansiblerepo/repodata/ [root@centos01 ansiblerepo] # vim / etc/yum.repos.d/local.repo [local] name=centos baseurl= file:///mnt/ansiblerepo/ansiblerepo enabled=1 gpgcheck=0 [root@centos01 ~] # yum-y install ansible

2) verify the installation result

[root@centos01] # ansible-- version ansible 2.3.1.0 config file = / etc/ansible/ansible.cfg configured module search path = Default w overrides python version = 2.7.5 (default, Nov 6 2016, 00:28:07) [GCC 4.8.5 20150623 (Red Hat 4.8.5-11)]

3) create SSH interaction-free login

Ansible manages the device through SSH, while SSH includes two authentication methods: one is authenticated by password, the other is verified by key pair. The former must interact with the system, while the latter is interactive login-free. If you want to automatically manage the device through Ansible, it should be configured to log on to the managed device without interactive login.

[root@centos01] # ssh-keygen-t rsa Generating public/private rsa key pair. Enter file in which to save the key (/ root/.ssh/id_rsa): Created directory'/ root/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in / root/.ssh/id_rsa. Your public key has been saved in / root/.ssh/id_rsa.pub. The key fingerprint is: SHA256:cJz6NRTrvMDxX+Jpce6LRnWI3vVEl/zvARL7D10q9WY root@centos01 The key's randomart image is: +-[RSA 2048]-+ |. . . | |. . + oo | |. = o. Oo | | = * o. + * | |. S *. = + = * + | |. O = + XooE | |. .. =. + +. | |. O.. | |. O. | +-[SHA256]-+ [root@centos01 ~] # ssh-copy-id-I. ssh / id_rsa.pub root@192.168.100.20 [root@centos01 ~] # ssh-copy-id-I. ssh / id_rsa.pub root@192.168.100.30

At this point, the deployment of Ansible is complete, and the device can be managed through Ansible.

2. Ansible configuration

Inventory is a configuration file for Ansible to manage host information, which is equivalent to the function of the system Hosts file and is stored in / etc/ansible/hosts by default.

In the hosts file, devices are organized by grouping, Ansible defines hosts and groups through Inventory, and Inventory is specified by using the option-I or-inventory-file in the ansible command.

[root@centos01] # ansible-I / etc/ansible/hosts web-m ping

If you use the default Inventory file (/ etc/ansible/hosts), you can also unspecify the Inventory file, for example:

[root@centos01] # ansible web-m ping

Ansible implements the management of devices by adding the device list to the / etc/ansible/hosts file in a grouped way, so before formal management, the hosts file should be written first. In the hosts file, the group name is represented by the part contained in [], and the device list supports hostname and IP address.

By default, devices are managed by accessing port 22 (SSH). If the target host uses a non-default SSH port, you can also use a colon plus a port after the host name to separate the configuration by behavior units. In addition, hosts files support wildcards.

[root@centos01] # vim / etc/ansible/hosts. [web] 192.168.100.20 192.168.100.30 [test] www.benet.com:222 [mail] yj1.kgc.cn yj [2:5] .kgc.cn

A host can be placed in different groups at the same time.

After the configuration is complete, you can operate remotely on a group defined by hosts, or on one or more hosts in the group. For example:

1) operate only on the 192.168.1.2 hosts in the web group, and limit the changes of the hosts with the-limit parameter.

[root@centos01 ~] # ansible web-m command-a "systemctl status httpd"-- limit "192.168.100.20" 192.168.100.20 | SUCCESS | rc=0 > >

2) operate only on 192.168.100.20 hosts. Qualify changes to the host through IP.

[root@centos01 ~] # ansible 192.168.100.20-m command-a "systemctl status httpd" 192.168.100.20 | SUCCESS | rc=0 > >

3) operate only on 192.168.100.0 network segment hosts, which requires the use of wildcards to limit host changes.

[root@centos01 ~] # ansible 192.168.1.*-m command-a "systemctl status httpd" 192.168.100.20 | SUCCESS | rc=0 > >. 192.168.100.30 | SUCCESS | rc=0 > >.

3. Ansible command

Most of the maintenance commands of Ansible start with ansible. Pressing the Tab key twice after entering ansible at the terminal will complete all the commands related to ansible.

[root@centos01 ~] # ansible ansible ansible-console-2 ansible-galaxy ansible-playbook-2.7 ansible-vault-2 ansible-2 ansible-console-2.7 ansible-galaxy-2 ansible-pull ansible-vault-2.7 ansible-2.7 ansible-doc ansible-galaxy-2.7 ansible-pull-2 ansible-connection ansible-doc-2 Ansible-playbook ansible-pull-2.7 ansible-console ansible-doc-2.7 ansible-playbook-2 ansible-vault

1) ansible

Ansible is one of the most frequently used commands in production environments and is mainly used in the following scenarios:

Non-solidified demand

Temporary one-time operation

Secondary development interface call

Non-solidified requirements refer to temporary maintenance, such as viewing web server group disk usage, copying a file to another machine, and so on. Similar to these irregular, temporary tasks that need to be done, we become non-solidified requirements, temporary one-time operations, the syntax is as follows:

Ansible [options]

-v (- verbose): output detailed information about the execution process, and you can get all the information about the execution process.

-I PATH (- inventory=PATH): specify inventory information. Default is / etc/ansible/hosts.

-f NUM (- forks=NUM): number of concurrent threads. Default is 5 threads.

-private-key=PRIVATE_KEY_FILE: specifies the key file

-m NAME,-module-name=NAME: specifies the module to be used for execution

-M DIRECTORY (- module-path=DIRECTORY): specify the storage path of the module. Default is / usr/share/ansible.

-an ARGUMENTS (- args=ARGUMENTS): specify module parameters

-u USERNAME (- user=USERNAME): specifies that the remote host runs the command as USERNAME

-l subset (- limit=SUBSET): restrict running hosts

① checks whether all hosts are alive, execute the command as follows:

[root@centos01 ~] # ansible all-f 5-m ping 192.168.100.20 | SUCCESS = > {"changed": false, "ping": "pong"} 192.168.100.30 | SUCCESS = > {"changed": false, "ping": "pong"}

② lists all hosts in the web group and executes the command as follows:

[root@centos01] # ansible web-- list hosts (2): 192.168.100.20 192.168.100.30

③ batch displays the disk usage space in the web group, execute the command as follows:

[root@centos01 ~] # ansible web-m command-a "df-hT" 192.168.100.30 | SUCCESS | rc=0 > > File system type capacity available available mount point / dev/mapper/cl-root xfs 17G 4.4G 13G 26% / devtmpfs devtmpfs 897M 0897M 0% / devtmpfs tmpfs 912m 84K 912M1% / dev/shm tmpfs tmpfs 912M 0912M 0% / sys/fs/cgroup / dev/sda1 xfs 1014M 173M 842M 18% / boot tmpfs tmpfs 183M 16K 183M 1% / run/user/42 tmpfs tmpfs 183M 0183M 0% / run/user/0 192.168.100.20 | SUCCESS | rc=0 > > File system type capacity used available mount point / dev/mapper/cl-root xfs 17G 4.3G 13G 26% / devtmpfs devtmpfs 897M 0897M 0% / devtmpfs tmpfs 912M 84K 912m 1% / dev/shm tmpfs tmpfs 912M 0912m 0% / Sys/fs/cgroup / dev/sda1 xfs 1014M 173M 842M 18% / boot tmpfs tmpfs 183M 16K 183M 1% / run/user/42 tmpfs tmpfs 183M 0 183M 0% / run/user/0 / dev/sr0 iso9660 4.1G 4.1G 0% / mnt

The web keyword needs to define the group in the / etc/ansible/hosts file in advance.

The return result of Ansible is very friendly, and the execution result is usually represented in three colors.

Red: indicates that an exception occurred during execution

Orange color: indicates that the target has a state change after the command is executed

Green: indicates that the execution was successful and no target machine made changes

2) Ansible-doc

Ansible-doc is used to query the documentation of ansible module. Similar to the man command, there are detailed usage instructions and application case descriptions for each module. The syntax is as follows:

Ansible-doc [options] [module...]

List the supported modules:

[root@centos01 ~] # ansible-doc-l

Query the description of the ping module:

[root@centos01 ~] # ansible-doc ping > PING (/ usr/lib/python2.7/site-packages/ansible/modules/system/ping.py) A trivial test module, this module always returns `pong' on successful contact. It does not make sense in playbooks, but it is useful from `/ usr/bin/ansible' to verify the ability to login and that a usable python is configured. This is NOT ICMP ping, this is just a trivial test module. EXAMPLES: # Test we can logon to 'webservers' and execute python with json lib. Ansible webservers-m ping MAINTAINERS: Ansible Core Team, Michael DeHaan METADATA: Status: ['stableinterface'] Supported_by: core

3) Ansible-playbook

Ansible-playbook is the most frequently used command in daily applications, similar to the sh or source command in Linux, which is used to perform a series of tasks.

Its working mechanism: to achieve centralized processing tasks by reading pre-written playbook files. The Ansible-playbook command is followed by a playbook file in yml format, and the playbook file stores the task code to be executed. The command is used as follows:

Ansible-playbook playbook.yml

4) Ansible-console

Ansible-console is an interactive tool provided by Ansible, similar to cmd of Windows or shell of Linux. Users can use various commands built in Ansible like shell on ansible-console virtual terminals, which provides a good experience for users who are accustomed to using shell interactive mode. After the terminal enters the ansible-console command, it is displayed as follows:

[root@centos01] # ansible-console Welcome to the ansible console. Type help or? To list commands. Root@all (2) [FRV 5] $cd web root@web (2) [FRV 5] $list 192.168.100.20 192.168.100.30

4. Ansible module

1) command module

The command module executes commands on the remote host and does not support shell features such as pipes and redirects. The common parameters are as follows:

Chdir: the directory to enter in advance before running commands on the remote host

Creates: create a file when the command is running. If the file already exists, the creation task will not be performed.

Removes: removes a file while the command is running. If the file does not exist, the removal task will not be performed.

Executeable: indicates the shell program that runs the command

Run the "ls. /" command on all hosts and change to the / home directory before running. Do the following:

[root@centos01] # ansible web-m command-a "chdir=/ ls. /"

2) shell module

The shell module executes commands on the remote host, which is equivalent to calling the Shell process of the remote host, and then opens a sub-Shell to run the command under that Shell. The difference from the command module is that it supports Shell features such as pipes, redirects, and so on.

Examples are as follows:

[root@centos01 ~] # ansible web-m shell-a "echo hello world" 192.168.100.20 | SUCCESS | rc=0 > > hello world 192.168.100.30 | SUCCESS | rc=0 > > hello world [root@centos01 ~] # ansible web-m shell-a "echo hello world > / 1.txt" 192.168.100.20 | SUCCESS | rc=0 > > 192.168.100.30 | SUCCESS | rc=0 > >

3) copy module

The copy module is used to copy the specified host files to the specified location of the remote host. Common parameters are as follows:

Dest: indicates the destination directory location of the copied file, using an absolute path. If the source is a directory, the destination is also a directory, and if the target file already exists, the original content will be overwritten.

Src: indicates the path of the source file. You can use relative and absolute paths, and you can specify directories directly. If the source is a directory, the destination should also be a directory

Mode: indicates the permissions of the target file when copying. Optional

Owner: indicates the owner of the target file when copying. Optional

Group: indicates the group of the target file at the time of replication. Optional

Content: indicates the content copied to the target host and cannot be used with src, which is equivalent to copying the data specified by content to the target file

Examples are as follows:

[root@centos01] # ansible web-m copy-a "src=/etc/hosts dest=/root/a1.hosts mode=777 owner=root group=root"

4) hostname module

The hostname module is used to manage hostnames on remote hosts. The common parameters are as follows:

Name:

Indicates the hostname

Examples are as follows:

[root@centos01 ~] # ansible 192.168.100.20-m hostname-a "name=test"

5) yum module

The yum module is based on the yum mechanism and manages the package to the remote host. The common parameters are as follows:

Name: the package name, which can be accompanied by the version number. If the version is not specified, it defaults to the latest version

State=present | atest | absent: indicates the action to be performed on the package: present indicates to install the package, latest indicates to install the latest version of the package, and absent indicates to uninstall the package

Disablerepo: temporarily disable the ID of a warehouse when installing with yum

Enablerepo: temporarily enable the ID of a warehouse when installing with yum

Conf_file:yum runtime configuration file instead of using the default configuration file

Disable_gpg_check=yes | no: whether to enable integrity check

Examples are as follows:

[root@centos01 ~] # ansible web-m shell-a "/ usr/bin/rm-rf / etc/yum.repos.d/CentOS-*" [root@centos01 ~] # ansible web-m shell-a "/ usr/bin/mount / dev/cdrom / mnt" [WARNING]: Consider using mount module rather than running mount 192.168.100.20 | SUCCESS | rc=0 > > mount: / dev/sr0 write protection 192.168.100.30 will be mounted as read-only | SUCCESS | rc=0 > > mount: / dev/sr0 write protection [root@centos01 ~] # ansible web-m yum-a "name=httpd state=present" [root@centos01 ~] # ansible web-m shell-a "rpm-qa | grep httpd" [WARNING]: Consider using yum will be mounted read-only Dnf or zypper module rather than running rpm 192.168.100.20 | SUCCESS | rc=0 > > httpd-2.4.6-67.el7.centos.x86_64 httpd-tools-2.4.6-67.el7.centos.x86_64 192.168.100.30 | SUCCESS | rc=0 > > httpd-2.4.6-67.el7.centos.x86_64 httpd-tools-2.4.6-67.el7.centos.x86_64 [root@centos01 ~] # ansible web-m shell-a " Systemctl start httpd "[root@centos01 ~] # ansible web-m shell-a" netstat-anptu | grep httpd "192.168.100.20 | SUCCESS | rc=0 > > tcp6 00: 80:: * LISTEN 2072/httpd 192.168.100.30 | SUCCESS | rc=0 > > tcp6 00: 80 :: * LISTEN 3098/httpd

The management side only sends yum instructions to the managed side, and the managed side can only be installed successfully if there is an available yum repository.

6) service module

The service module is a module used to manage services on remote hosts. Common parameters are as follows:

Name: name of the managed service

State=started | stopped | restarted: actions include startup, shutdown or restart

Enable=yes | no: indicates whether to set the service to start automatically

Runlevel: if enabled boot is set, define the targets under which to start automatically

Examples are as follows:

[root@centos01] # ansible web-m service-a "name=httpd enabled=yes state=restarted"

7) user module

The user module is mainly used to manage user accounts on remote hosts. Common parameters are as follows:

Name: required parameter, account name

State=present | absent: create or delete an account. Present: create; absent: delete; system=yes | no: whether it is a system account

Uid: user UID

Group: the basic group of the user

Groups: the user's additional group

Shell: shell used by default

Home: the user's home directory

Mve_home=yes | no:

If the set home directory already exists, whether to move the existing home directory

Pssword: the user's password. It is recommended to use an encrypted string.

Comment:

User's comment information

Remore=yes | no:

When state=absent, whether to delete the user's home directory

An example of creating a user is as follows:

[root@centos01] # ansible web-m user-a "name=user01 system=yes uid=502 group=root groups=root shell=/etc/nologin home=/home/user01 password=pwd@123"

IV. Playbook configuration file

1. Execute the configuration file

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.

YAML syntax is similar to other high-level languages in that its structure is shown by indentation and represents items by "-"; ":" is used to separate keys and values; the whole file starts with "-" and begins with "…". The end is as follows:

[root@centos01 ~] # grep-v ^ # / etc/ansible/hosts | grep-v ^ $[web1] 192.168.100.20 [web2] 192.168.100.30 [root@centos01 ~] # vim / etc/ansible/a.yml-hosts: web1 remote_user: root tasks: -name: adduser user: name=user1 state=present tags:-aaa-name: addgroup group: name=root system=yes tags: -bbb-hosts: web2 remote_user: root tasks:-name: copy file to web copy: src=/etc/passwd dest=/home tags:-ccc.

All "-" and ":" are followed by spaces, and pay attention to indentation and alignment, as shown in the following figure:

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: task, that is, the specific task defined, the list of actions defined by the 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, etc.

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

Ansible-playbook [option] / PATH/TO/PLAYBOOK.yaml

Among them, the functions of [option] section include:

-syntax-check: check the syntax of the yaml file

-C (- check): pre-test, will not change any settings of the target host

-list-hosts: lists the hosts affected by the yaml file

-list-tasks: lists the tasks for the yaml file

-list-tags: lists the tags in the yaml file

-t TAGS (- tags=TAGS): indicates that only tasks with specified tags are executed

-skip-tags=SKIP_TAGS: indicates that other tasks are performed in addition to the tasks specified by the label

-start-at-task=START_AT: runs down from the specified task

An example of performing playbook is as follows:

[root@centos01] # ansible-playbook-- syntax-check / etc/ansible/a.yml playbook: / etc/ansible/a.yml [root@centos01 ~] # ansible-playbook-C / etc/ansible/a.yml. 192.168.100.20: ok=3 changed=1 unreachable=0 failed=0 192.168.100.30: ok=2 changed=1 unreachable=0 failed=0 [root@centos01 ~] # ansible-playbook-list-hosts / etc/ansible/a.yml [root@centos01] # ansible-playbook-list-tasks / etc/ansible/a.yml [root@centos01] # ansible-playbook-list-tags / etc/ansible/a.yml [root@ Centos01 ~] # ansible-playbook / etc/ansible/a.yml [root@centos01 ~] # ssh 192.168.100.20 tail-1 / etc/passwd user1:x:1001:1001::/home/user1:/bin/bash [root@centos01 ~] # ssh 192.168.100.30 ls-ld / home/passwd-rw-r--r--. 1 root root 2342 July 23 16:06 / home/passwd

Usually, the ansible-playbook-C / PATH/TO/PLAYBOOK.yaml command is executed first to test, and then the ansible-playbook / PATH/TO/PLAYBOOK.yml command is executed after the test is all right.

2. Trigger

For tasks that need to be triggered to execute, if you want to trigger other tasks based on the successful execution of the tasks previously defined in tasks, you need to define 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 to make the configuration file effective. 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.

The handlers is executed in the defined order.

Examples of use of handlers triggers are as follows:

[root@centos01 ~] # ssh 192.168.100.20 netstat-anpt | grep 80 tcp6 00: 80: * LISTEN 94858/httpd [root@centos01 ~] # vim / etc/ansible/httpd.yml-hosts: web1 remote_user: root tasks:-name: change port command : sed-I 's/Listen\ 80/Listen\ 8080 Compact g' / etc/httpd/conf/httpd.conf notify:-restart httpd server handlers:-name: restart httpd server service: name=httpd state=restarted. [root@centos01 ~] # ansible-playbook-C / etc/ansible/httpd.yml [root@centos01 ~] # ansible-playbook / etc/ansible/httpd.yml [root@centos01 ~] # ssh 192.168.100.20 netstat-anpt | grep 8080 tcp6 00: 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 shown in the following figure:

/ 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 that stores the template files needed by the template module to find, such as the mysql configuration file template

Tasks: the directory where the task is stored

Handlers: the directory where the relevant triggering execution is stored

Vars: the directory where the variables are stored

Meta: used to store this role 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 be other .yml files in this directory, 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: web remote_user: root roles:-mysql-httpd

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.

The above content is how to analyze the automatic operation and maintenance of Ansible. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

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.