Ansible is introduced to installation

Ansible (automatic operation and maintenance tool)

Automatic operation and maintenance

Automatic operation and maintenance refers to the automation of a large number of repetitive daily work in operation and maintenance, and the work performed by yourself or more people is transformed into automatic operation with the help of platforms or tools through combing and analysis. Automated operation and maintenance is not only a maintenance process, but also a management improvement process. It is a higher level of operation and maintenance and a future development trend.

Common automatic operation and maintenance tools

Ansible:python,Agentless, small and medium-sized application environment
Saltstack:python, which generally deploys agent s, with high execution efficiency
Puppet:ruby, with powerful functions and complex configuration, is suitable for large-scale environments
Fabric:python,agentless
chef:ruby, few domestic applications
Cfengine
runc

(1) 1. Introduction to Ansible

Ansible automatic operation and maintenance tool, developed based on python, integrates the advantages of many operation and maintenance tools (puppet, cfengine, chef, func, fabric), and realizes the functions of batch system configuration, batch program deployment, batch operation command, etc.

Ansible works based on modules and does not have the capability of batch deployment. What really has batch deployment is the modules run by ansible. Ansible only provides a framework, mainly including:

1. connection plugins: responsible for communication with the monitored end

2. host inventory: Specifies the host of the operation, which is the host of monitoring defined in the configuration file

3. Various modules, core modules, command modules and user-defined modules

4. With the help of the plug-in, complete the functions of logging mail and so on

5. playbook: when the script executes multiple tasks, it is not necessary to allow the node to run multiple tasks at one time

2. Basic architecture

Core: ansible

Core Modules: These are built-in modules of ansible

Custom Modules: if the core module is not enough to complete a function, you can add an extension module

Plugins: complete the supplement of module functions

Playbooks: an ansible task configuration file that defines multiple tasks in a script and is automatically executed by ansible

Connector plugins: ansible connects to each host based on the connection plug-in. Although ansible connects to each host Using ssh, it also supports other connection methods, so a connection plug-in is required

Host Inventory: defines the hosts that can be managed easily

[the external chain picture transfer fails. The source station may have an anti-theft chain mechanism. It is recommended to save the picture and upload it directly (img-fneypgmf-1626346691047) (C: \ users \ 14375 \ desktop \ 1160003-2018122114536388-823786315. JPG)]

3. Ansible does not require an agent

Ansible is built around an agent-free architecture. Generally speaking, ansible connects to the hosts it manages through OpenSSH or WinRM and runs tasks, usually by pushing applets called ansible modules to these hosts. These procedures are used to place the system in the specific state required. After ansible runs its task, all pushed modules will be deleted.

Ansible does not need to approve the use of any special agents before deploying to the managed host. Since there are no agents and no additional custom security infrastructure is required,

Ansible has several important advantages:

				1,Cross platform support: Ansible provide Linux,Windows,UNIX Agent free support for and network devices for physical, virtual, cloud and container environments.

2. Human readable automation: Ansible Playbook is written in YAML text file, which is easy to read and helps to ensure that everyone can understand their purpose.

3. Perfect description of application: each change can be made through Ansible Playbook, and every aspect of the application environment can be described and recorded.

4. Easily manage version control: Ansible Playbook and project are plain text. They can be viewed as source code and placed in existing version control systems.

5. Support dynamic list: the list of Ansible managed computers can be dynamically updated from external sources to obtain the current correct list of all managed servers at any time, which is not affected by the infrastructure or location.

6. Choreography can be easily integrated with other systems: it can use the existing HP SA, Puppet, Jenkins, red hat satellite and other systems in the environment and integrate them into Ansible workflow.

4. Ansible benefits

1. Ansible integrates the advantages of many old brand operation and maintenance tools. Basically, ansible can realize the functions that pubbet and saltstack can realize

2. Lightweight. There is no need to install agent on the client. When updating, just update it on the operating machine

3. Ansible is a lightweight tool. Ansible does not need to start services. It is just a tool that can easily realize distributed expansion

4. Batch task execution can be written into script, and can be realized without remote distribution

5. Ansible is a lightweight automation tool with consistency, high reliability and safety design

6. It is written in python, which makes maintenance easier

5. Ansible working principle

[the external chain picture transfer fails. The source station may have an anti-theft chain mechanism. It is recommended to save the picture and upload it directly (img-f1v4hyqM-1626346691048)(C:\Users375\Desktop151223115116074.jpg)]

The management end supports local, ssh and zeromq connections to the managed end. By default, ssh based connections are used. Host Inventory (host group) can be classified according to application type. The management node realizes corresponding operations through various modules. The batch execution of a single module and a single command can be called ad-hoc The management node can realize the collection of multiple task s through playbooks to realize a class of functions, such as the installation and deployment of web services, batch backup of database servers, etc. playbooks can be simply understood as the configuration file of the system through the combination of multiple ad-hoc operations.

6. Ansible task execution process

(1) read configuration

(2) grab the full machine & group list

The machine, group and its variable correlation information can be read from multiple static files, folders and scripts.

(3) use host pattern to filter the machine list

(4) determine the execution module and configuration according to the parameters

Dynamically read from the modules directory. Users can develop modules by themselves.

(5) Runner execution return

				 Connection Link definition connection method => Action Stage machine list( Lookup plugin Action variable/Acquisition of files and other resources) Callback plugin Hook call at each stage

(6) end of output

Filter plugin filter operator, Callback plugin hook call of each stage

7. Ansible command

1,ansible

ansible is the core part of the instruction, which is mainly used to execute ad-hoc commands, that is, a single command. The default needs to be followed by the host and options. When the module is not specified by default, the command module is used.

2,ansible-doc

This instruction is used to view module information. The common parameters are - l and - s, as follows:

/ / list all installed modules

# ansible-doc -l

/ / view the usage of a specific module, such as the command module

# ansible-doc -s command

3,ansible-galaxy

The ansible Galaxy instruction is used for convenient slave https://galaxy.ansible.com/ Download the third-party extension module from the website. We can understand that it is similar to yum under centos and pip or easy under python_ install .

4,ansible-lint

Ansible lint is a tool for checking the syntax of playbook. The usage is ansible lintplaybook yml .

5,ansible-playbook

This instruction is the most used instruction. After reading the playbook file, it executes the corresponding action. This will be emphasized later.

6,ansible-pull

This instruction uses another mode that needs to be talked about ansible, the pull mode, which is just opposite to the push mode we often use. It is applicable to the following scenarios: you have a large number of machines to configure, and it still takes a lot of time even if you use very high threads; You need to run Anisble on a machine without a network connection, such as installing it after startup. This part will also be described in a separate section.

7,ansible-vault

Ansible vault is mainly used to encrypt / decrypt the configuration file, which contains sensitive information and does not want it to be seen. Vault is an advanced usage. Mainly for playbooks, for example, when it involves configuring passwords or other variables, it can be encrypted through this instruction. In this way, we can see a password string file through cat. When editing, we need to enter the preset password to open it. When executing this playbook file, you need to add the – ask vault pass parameter. You also need to enter a password before it can be executed normally.

(2) Install Ansible

1 control node

Ansible is easy to install. Ansible software only needs to be installed on one (or more) control nodes to run it. Hosts managed by ansible do not need to install ansible.

Requirements for control nodes:

The control node shall be a Linux or UNIX system. Windows is not supported as a control node, but a Windows system can be a managed host.
The control node needs to install Python 3 (version 3.5 or above) or Python 2 (version 2.7 or above).

If the operating system is red hat 8.0, Ansible 2.9 can automatically use the platform Python package, which supports system utilities using python. You do not need to install python37 or python27 packages from AppStream.

2 managed host

A major advantage of Ansible is that the managed host does not need to install a special agent. The Ansible control node uses standard network protocols to connect to the managed host to ensure that the system is in the specified state.

Managed hosts may meet some requirements, depending on how the control nodes connect them and the modules they want to run.

Linux and UNIX managed hosts need Python 2 (version 2.6 or above) or Python 3 (version 3.5 or above) to run most modules.

3 Windows based managed host

Ansible has many modules designed specifically for Windows systems. These modules are listed in https://docs.ansible.com/ansible/latest/modules/list_of_windows_modules.html Part.

Most modules designed specifically for windows managed hosts require PowerShell 3.0 or later to be installed on the managed host instead of Python. In addition, the managed host also needs to configure PowerShell remote connections. Ansible asked at least the general NET Framework 4.0 or later is installed on a Windows managed host.

4 managed network devices

Ansible can also configure managed network devices, such as routers and switches. Ansible contains a large number of modules specifically designed for this purpose. Including support for Cisco IOS, IOS XR and NX-OS; Juniper Junos； Arsta EOS； And network devices based on VyOS.

You can write Ansible playbooks for network devices using the same basic techniques used when writing playbooks for servers. Since most network devices cannot run Python, Ansible runs the network module on the control node rather than on the managed host. Special connection methods are also used to communicate with network devices, usually using CLI on SSH, XML on SSH or API on HTTP(S).

5 install Ansible

[root@localhost yum.repos.d]# ls #Check whether there are epel source packages
CentOS-Stream-AppStream.repo  CentOS-Stream-Debuginfo.repo  CentOS-Stream-HighAvailability.repo  CentOS-Stream-PowerTools.repo  liu.repo
CentOS-Stream-BaseOS.repo     CentOS-Stream-Extras.repo     CentOS-Stream-Media.repo             CentOS-Stream-RealTime.repo

[root@localhost yum.repos.d]# yum -y install epel-release #Download epel source package
Repository baseos is listed more than once in the configuration
Repository appstream is listed more than once in the configuration
 Last metadata expiration check: 1:30:41 Before, it was executed at 02:30:05 on Tuesday, July 13, 2021.
Dependency resolution.
==================================================================================
 software package                    framework           edition               Warehouse            size
==================================================================================
install:
 epel-release              noarch         8-11.el8           extras          24 k
 Install weak dependencies:
 epel-next-release         noarch         8-11.el8           extras          11 k

Transaction summary
==================================================================================
Install 2 software package

Total downloads: 35 k
 Installation size: 38 k
 Download package:
(1/2): epel-next-release-8-11.el8.noarch.rpm      2.1 kB/s |  11 kB     00:05    
(2/2): epel-release-8-11.el8.noarch.rpm           4.4 kB/s |  24 kB     00:05    
[root@localhost yum.repos.d]# ls 
CentOS-Stream-AppStream.repo  CentOS-Stream-Extras.repo            CentOS-Stream-PowerTools.repo  epel-next.repo          epel.repo                  liu.repo
CentOS-Stream-BaseOS.repo     CentOS-Stream-HighAvailability.repo  CentOS-Stream-RealTime.repo    epel-next-testing.repo  epel-testing-modular.repo
CentOS-Stream-Debuginfo.repo  CentOS-Stream-Media.repo             epel-modular.repo              epel-playground.repo    epel-testing.repo

[root@localhost yum.repos.d]# yum makecache #Verify yum source
Repository baseos is listed more than once in the configuration
Repository appstream is listed more than once in the configuration
CentOS Stream 8 - AppStream                       4.4 kB/s | 4.4 kB     00:00    
CentOS Stream 8 - BaseOS                          543  B/s | 3.9 kB     00:07    
CentOS Stream 8 - Extras                          497  B/s | 3.0 kB     00:06    
Extra Packages for Enterprise Linux Modular 8 - x 6.5 kB/s | 663 kB     01:42    
Extra Packages for Enterprise Linux 8 - Next - x8  13 kB/s | 1.1 MB     01:28    
Extra Packages for Enterprise Linux 8 - x86_64    645 kB/s |  10 MB     00:16    
Metadata cache established.

[root@localhost yum.repos.d]# yum -y install ansible #Install ansible
[root@localhost yum.repos.d]# ansible --version #View version number
ansible 2.9.23
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.6/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.6.8 (default, Dec  3 2020, 18:11:24) [GCC 8.4.1 20200928 (Red Hat 8.4.1-1)]

[root@localhost yum.repos.d]# ansible -m setup localhost|grep ansible_python_version
        "ansible_python_version": "3.6.8",   
        # Verify ansible on localhost by using the setup module_ python_ version

(3) Build Ansible list

Definition list

The list defines a batch of hosts that Ansible will manage. These hosts can also be assigned to groups for centralized management. A group can contain subgroups, and hosts can also be members of multiple groups. The list can also set variables applied to the hosts and groups it defines

There are two ways to define the host list:

Static host list: defined by text file

Other hosts list: generated by scripts or other programs using external information providers

List function

Define a batch of hosts list managed by Ansible, and directly manage the hosts in the list during the call process by executing Ansible module.

Specify managed host using static manifest

Static manifest file refers to the text file of Ansible target managed host, which can be written in many different formats, including INI style and YAML

Through the host group, Ansible can be run more effectively on a series of systems. The host name enclosed in square brackets at the beginning of each part is followed by the host name or IP address of each managed host in the reorganization, one in each line.

Default list location

Default location: / etc/ansible/hos

Usage rules: we generally do not apply to the default list. In order to facilitate management, managers will set their own list directory in their own folder directory

List reading order: list under Current Directory > list under this user > list of global users

grammar

[ceshi]
192.168.220.98
log ansible_ssh_host=192.168.220.116 ansible_ssh_port=10056 ansible_ssh_user=wwwad

Explanation of terms:

[ceshi] this is the host group name

log: alias of 192.168.220.116

ansible_ssh_port=10056: ansible remote control port

ansible_ssh_user=wwwad: user name of remote control

Basic definition: one host name or IP address per line, batch format

green.example.com
blue.example.com
192.168.100.1
192.168.100.10

Group definition: basic group definition

[webservers]
ip/servername

View catalog list

List all managed hosts in the list: ansible all -- List hosts

[root@localhost ansible]# ansible all --list-hosts
  hosts (1):
    192.168.240.40

List hosts that do not belong to a group: ansible ungrouped -- List hosts

[root@localhost ansible]# ansible ungrouped --list-hosts
  hosts (1):
    192.168.240.41

List hosts that do not belong to the group: ansible awebservers -- List hosts

[root@localhost ansible]# ansible awebservers --list-host
  hosts (2):
    192.168.240.40
    192.168.240.44

List all specified hosts: ansible all - I Inventory -- List hosts

[root@localhost ansible]# ansible all -i cctv --list-hosts
  hosts (1):
    192.168.240.40

Ansible connecting managed hosts

[root@localhost ansible]# ansible all -m ping
192.168.240.40 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/libexec/platform-python"
    },
    "changed": false,
    "ping": "pong"
}

Generate and transfer keys

[root@localhost ~]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
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:Z3PyT7XhH6MOS/tzpyTmDjm90H2Q6nfsy08YRzuwTgk root@localhost.localdomain
The key's randomart image is:
+---[RSA 3072]----+
|                 |
|                 |
|           E .  .|
|            . +o.|
|        S = .+++o|
|         o Ooo.*+|
|          =oB.=*o|
|          .B+B++B|
|           +B==*B|
+----[SHA256]-----+
[root@localhost ~]# ssh-copy-id root@192.168.240.40
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@192.168.240.40's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'root@192.168.240.40'"
and check to make sure that only the key(s) you wanted were added.

Keywords: Linux

Added by robertvideo on Mon, 17 Jan 2022 14:40:12 +0200

Programming VIP