Detailed explanation of the use of ansible automated operation and maintenance tools

1. Introduction to ansible

1. ansible

Ansible is a new automated operation and maintenance tool, developed based on Python. It combines the advantages of many old-fashioned operation and maintenance tools to realize batch operating system configuration, batch program deployment, batch running commands and other functions. It is only necessary to install the ansible program on the management workstation to configure the IP information of the managed host, and the managed host has no client. Ansible applications exist in the epel (third-party community) source and depend on many python components

Reference  site: http://www.ansible.com.cn



2.ansible features

Modular design, calling specific modules to complete specific tasks, itself It is the core component, short and powerful;

it is implemented based on the Python language, and is implemented by three key modules of Paramiko (a concurrently connected ssh host function library of python), PyYAML and Jinja2 (templated);

simple deployment, agentless clientless tool;

master-slave Mode work;

support custom module function;

support playbook script, continuous tasks are completed in the order of setting;

expect each command to be idempotent:

3. ansible architecture

ansible core: Ansible's own core module

host inventory: host library, defined and controllable The host list

connection plugins: connection plugins, generally based on the ssh protocol connection by default

modules: core modules (self-contained modules), custom modules (custom modules)

playbooks: playbooks, which are executed in the order set and arranged to complete the scheduling tasks



4. Configuration files:

(1) The main configuration file of ansible application: /etc /ansible/ansible.cfg

(2) Host Inventory Defines the managed host: /etc/ansible/hosts

follows INI style; the characters in brackets are group names; a host can belong to multiple groups at the same time;

example:

# Ex 1: Ungrouped hosts, specify before any groupheaders. Specified directly before any groupheaders, hosts that do not belong to any group

green.example.com

blue.example.com

192.168.100.1

192.168.100.10

# Ex 2: A collection of hosts belonging to the 'webservers' group ; a batch of hosts belongs to a group, such as the group defined as 'webservers'

[webservers]

alpha.example.org

beta.example.org

192.168.1.100

192.168.1.110

Note: It is executed by the root user by default, but the password based on the ssh connection operation needs to be entered multiple times. For convenience, the authentication based on the ssh key can be used.

2.

Ansible application commands Use format;

ansible-doc -l : get the list

ansible-doc -s module_name : get the usage information of the specified module

2.ansible command format

ansible <host-pattern> [-f forks] [-m module_name] [-a args]


<host-pattern>

specifies the control host, which is expressed in the form of a pattern or directly given an IP, which must be defined in the file in advance; all set all


[-f forks]

to indicate how many hosts to control in each batch, the default is 5 hosts in one batch


[ -m module_name]

Which module management operation is used, all operations need to be specified through the module


[-a args]

indicates module-specific parameters; args is generally in the format of key=value

Note : The parameters of the command module are not in kv format, but in kv format. Just give the command to be executed directly;


note: <host-pattern> reads /etc/ansible/hosts by default, or you can specify the custom file path

-iPATH, --inventory=PATH: specify the host inventory file path to use ;

Common modules (module_name):

1) command: the default module, which can be omitted. Operation command on the remote host

-a 'COMMAND'

Note: The parameters of the comand module are not in key=value format, directly give the command to be executed

[root@localhost ~]# ansible all -m command -a 'ifconfig'

2) user:

-a 'name= state={present (create) |absent (delete) } force= (whether to force the operation to delete the home directory) system= uid= shell= home='

[root@localhost ~]# ansible all -m user -a 'name=ansible state=present'

3)group:

-a 'name= state={present|absent} gid= system= (system group) '

[root@localhost ~]# ansible all -m group -a 'name=mygroup state=presentsystem=true'

4) cron:

-a 'name= state= minute= hour= day= month= weekday= job='

[root@localhost ~]# ansible all -m cron -a 'name='Time' state=presentminute='*/5' job='/usr/sbin/ntpdate 172.168.0.1 &> /dev/null''

5 )ping:

no parameters

[root@localhost ~]# ansible all -m ping

6) file: file management

-a 'path= mode= owner= group= state={file|directory|link|hard|touch|absent} src = (link, where to link) '

[root@localhost ~]# ansible all -m file -a 'path=/tmp/testdirstate=directory'

[root@localhost ~]# ansible all -m file -a 'path =/tmp/test.txt state=touchmod=600 owner=user1'

7)copy:

-a 'dest= (path on remote host) src= (path on local host) content= (directly specify content) owner= group= mode ='

[root@localhosttmp]# ansible web -m copy -a 'src=/etc/yum.repos.d/aliyun.repodest=/etc/yum. repos.d/'

8)template

-a  'dest= src=\'#\'" content=  owner= group=  mode='

9)yum：

-a 'name=  conf_file= ( 指明配置文件 )  state={present|latest|absent} enablerepo= disablerepo='        

[root@localhost ~]# ansible all -m yum 'name=httpd state=present'

10)service：

-a 'name= state={started|stopped|restarted} enabled= ( 是否开机自动启动 )   runlevel='

[root@localhost ~]# ansible all -m service -a 'name=httpd state=started'

11)shell：

-a 'COMMAND'    运行 shell 命令

[root@localhost ~]# ansible all -m shell -a echo "123456789" |passwd --stdin user1'

12)script：

-a '/PATH/TO/SCRIPT' 运行脚本

[root@localhost ~]# ansible all -m script -a '/tmp/a.sh' 3. Playbooks script

13) setup: Get the facts variable of the specified host;





1. Playbook organization format: YAML language format

playbooks is a more powerful configuration management component of ansible, which realizes multiple tasks based on text file arrangement and execution, and executes multiple times

(1) YAML introduction

YAML: YAML Ain't Markup Language; Yet Another Markup Language;

similar to semi-structured data, declarative configuration; a highly readable format for expressing data sequences, easy to interact with scripting languages

​​Official  site: http://www.yaml.org

(2) Syntax Format

1) Any book structure is identified by indentation and can be nested

2) Each line is a key-value data key :value separated by colons. If you want to identify a line, you need to use { } and , to separate the format

3) List with -

identification

ansible_ssh_port specifies the ssh port


ansible_ssh_user specifies the ssh user ansible_ssh_pass specifies that the ssh user login is the authentication password, and the plaintext password is not secure ansible_sudo_pass specifies the password for sudo Example :





















[websrvs]

192.168.0.101 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass=xuding

192.168.0.102

Note: It is not safe to define the password when connecting directly in /etc/ansible/hosts. It is generally recommended to implement

3.playbooks based on ssh key authentication

(1) Core elements

Tasks tasks, Variables variables, Templates templates, Handlers processors, Roles roles

(2) Define tasks in playbooks:

- name: task description comment description information

module_name: module_args declare module: define ansible module parameters



(3) ansible -playbook Execute the command:

ansible-playbook <filename.yml> ... [options]



4.playbook---Variables

(1) Variable naming: composed of letters, numbers and underscores, and can only start with letters;

(2) Variable types :

1) facts: host-specific attribute information sent back by the remote host, which is stored in ansible variables; can be called directly without declaration;

2) custom variables:

Passed via command line: ansible-playbook test.yml --extra-vars "host=www user=test"

Passed via roles

3) Host variables: variables defined after the host in the inventory; variables passed directly to a single host

instance :

[root@localhost ~]# Vim /etc/ansible/hosts Defined directly after the host

[web]

192.168.0.101 host=mail

192.168.0.102

192.168.0.103

4) Group variables: variables defined on groups in inventory (For example, edit on the default file /etc/ansible/hosts)

[group_name:vars]

var1=value

var2=value

Note: The group name must exist in advance, examples are as follows:

[websrvs]

192.168.0.101

192.168.0.102

[websrvs:vars ] Example of

host=mail

variable usage:

[root@localhost~]# vim useradd.yml

- hosts: websrvs

remote_user: root

vars:

username: testuser

password: xuding

tasks:

-name: add user

user: name={{ username }} state=present

-name: set password

shell: /bin/echo {{ password }} |/usr/bin/passwd -- stdin {{ username }}

comments:

1) {{ }} call variable

2) #ansible-playbook /PATH/TO/SOME_YAML_FILE { -eVARS|--extra-vars=VARS} variable reassignment call method

[root@localhost ~]# ansible-playbookuseradd.yml --extra-vars "username=ubuntu"

5.playbook--- tasks

(1) Conditional test:

add when clause after a task to realize conditional test function; when statement supports Jinja2 Syntax;

      Example: At that time, when RedHat series systems were used, yum was called to install

tasks:

-name: install web server package

yum: name=httpd state=present

when: ansible_os_family == "RedHat"

(2) Iteration: item

calls the built-in item variable in the task; use the with_items statement after a task to define a list of elements;

tasks:

-name: add four users

user: name={{ item }} state=present

with_items:

-testuser1

-testuser2

-testuser3

-testuser4

Note: During iteration, each element in the list can be in dictionary format;

example:

-name: add two users

user: name={{ item.name }} state=present groups={{ item.groups }}

with_items:

- { name: 'testuser5', groups: 'wheel' }

- { name: 'testuser6', groups: 'root' }

6.playbook--- handlers: Processor;

trigger A task that will be triggered to execute only when the conditions it cares about are met;

example: a configuration file change triggers a restart of the service

- hosts: websrvs

remote_user: root

tasks:

-name: install httpd

yum:name=httpd state=present

-name: install config file

copy: src=/root/httpd.confdest=/etc/httpd/conf/httpd.conf

notify: restart httpd

- name: start httpd service

service: name=httpd state=started

handlers:

-name: restart httpd

service: name=httpd state=restarted

7.playbook template

templates:

used to generate text files (configuration files); jinja2 can be used in the template files Expressions, expressions should be defined in {{}}, or you can simply perform variable substitution;

roles:

roles are used to implement "code reuse";

roles are playbook elements organized in a specific hierarchical format (variables, tasks , templates, handlers);

can be called directly by the playbook with the name of the role;

usage: create a [group_name] subdirectory under roles/, not all of them; for example:

/etc/ansible/roles/ (define roles directory in /etc/ansible/ansible.cfg)

webserver/

files/: All files used in this role are placed in this directory;

templates/: Jinja2 template file storage location;

tasks/: task list file; there can be multiple, but at least one file called main.yml;

handlers/: handler list file; there can be multiple, but at least one file called main.yml;

vars/: Variable dictionary file; there can be multiple, but at least one file called main.yml;

meta/: special settings and dependencies of this role;