Ansible automation basic study notes

introduction

This section mainly explains Ansible tools. Although Chef, Puppet, SaltStack and Fabric (will be discussed in later chapters) are all popular automated operation and maintenance management tools, they are much more complicated than Ansible, but Each tool also has its own advantages, here we will first learn this relatively simple automated operation and maintenance tool - Ansible.

Ansible is an automated operation and maintenance tool based on python development that can realize batch system configuration, program deployment, running commands and other functions. Ansible mainly works based on modules, and does not have the ability to deploy in batches. The real deployment function is the running module.

• Ansible: runs on the central computer;

• Connection Plugins: connection plug-ins, mainly used for connection and communication between the local and the operator;

• Host Inventory: The host that specifies the operation is the host that defines the monitoring in a configuration file;

• Modules: core modules, custom modules, etc.;

• Plugins: Use plug-ins to complete functions such as logging, email, etc.;

• Playbooks: Multitask, deploy modules to nodes via SSH, either multiple nodes or a single node.

Ansible has two main types of servers: control machines and nodes. The control machine is used for control coordination, and the nodes are managed by the control machine through SSH, and the control machine describes the location of the nodes through the inventory. In the orchestration of nodes, Ansible deploys modules to nodes through SSH, modules are temporarily stored on nodes, and communicate with standard output JSON protocol, so as to retrieve information, send commands, etc. on remote machines.

lab environment

For the two Tencent cloud servers, the host python environment has not changed except that the server has been installed with docker.

• Lightweight Server 106.55.50.77
• G4 server 150.158.115.54

ansible install

There are two ways to install ansible. Like supervisor, it can be installed with python's pip, or it can be installed directly with apt-get. To prevent stepping on the pit, I choose to install it directly here.

# apt安装方式
$ sudo apt update
$ sudo apt install software-properties-common    # 安装通用的管理软件库的工具
$ sudo add-apt-repository --yes --update ppa:ansible/ansible
$ sudo apt install ansible

# 直接pip安装
$ python -m pip install --user ansible
$ python -m pip install --user paramiko

After the installation has no errors, you can enter some simple commands to view the current status, ansible --version to view the current running status:

$ anible --version
"""
ansible 2.9.27
  config file = /etc/ansible/ansible.cfg
  configured module search path = [u'/home/ubuntu/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.17 (default, Feb 27 2021, 15:10:58) [GCC 7.5.0]

"""

Ansible can operate on single or multiple machines or some machines at the same time through Inventory. Inventory is saved in the /etc/ansible/hosts configuration file by default, and Ansible can know the server to track through this file. Here we can add ssh communication to another server and write the ssh configuration information:

$ vim /etc/ansible/hosts

[test]
150.158.115.54 ansible_ssh_user=root ansible_ssh_pass=xxxxx

Here to explain, the inventory file can have many different formats (such as: INI, YAML, etc.), depending on the corresponding plugin, here we give some examples of Ansible's default format (INI), we can see the following A few examples, the above I use is the ssh password method:

# 1.常用主机（IP 地址）分组，标题是组名，用于分类系统和决定系统的控制等，可以有一台或多台。
[test]
127.0.0.1
foo.example.com

# 2.分组后添加对该组机器的登录用户和验证方式。添加主机和用户名以及私钥文件。
[dev_test]
192.168.42.3 ansible_ssh_user=ubuntu ansible_ssh_private_key_file=/path/of/keyfile

# 3.不使用分组，采用文件别名的方式。通过端口及主机来描述。
Alias ansible_host=192.168.1.50 ansible_port=6666

The three connection methods are defined as:

Host connection:

• ansible_connectionThe type of connection to the host, any possible connection plugin names, e.g. SSH protocol type with: ssh, smartor paramiko.

General connection:

• ansible_hostThe name of the host to connect to.

• ansible_portssh port number.

• ansible_userDefault ssh username.

Specific SSH connection:

• ansible_ssh_pass sshpassword

• ansible_ssh_private_key_filePrivate key file used by ssh.

AD-HOC Temporary Order

ad-hoc : Temporary commands, which are commands that perform certain operations quickly after inputting content, but do not want to save them.

In general, Ansible mainly lies in the scripting of playbooks that we will learn later, but compared with ad-hoc, its advantage is that when you receive a temporary task, you only need to quickly and easily execute an ad -hoc ad hoc command instead of writing a full playbook script.

We know that Ansible mainly implements various functions through modules. Let's operate the ad-hoc command through the simple module of ping.

# 对 test 分组执行命令
ansible test -m ping

# 对所有机器执行命令
ansible all -m ping

The following figure is the experimental process:

you can see that there may be an error on the figure after the first operation is performed. The main reason is that the HOST KEY needs to be checked and verified during the ssh connection. You can use the -oparameter to StrictHostKeyCheckingset to no to temporarily disable the check . If you want to save the settings, you can modify the Ansible configuration file /etc/ansible/ansible.cfgand host_key_checkingdelete the comment in the . Do as follows:

After the modification is completed, perform the same operation again, and you will see success. In addition, there are some other basic commands:

# 查看操作机器信息
ansible all -m setup

# 执行让操作机器输出“hello world”
ansible test -a "/bin/echo Hello world"

# 指定目标主机在某一路径下创建文件
ansible test -m file -a "dest=/home/file state=touch mode=777"

# 查询目标主机的内存
ansible test -m shell -a 'free -m'

For the above AD-HOC operations and results, we can see that the returned types are:

• success: This result indicates that the operation is successful. There are two cases. The first case is when some simple operations of the query are performed and the content does not need to be modified, indicating that the operation is no problem; the second case is when the operation has been executed before When executed, it will directly indicate success.

• changed: true This result indicates that some modification operations performed successfully, such as creating a file above, or modifying a configuration file, copying a file, etc. operations will have such results.

• failed: This result indicates that the operation failed, which may be a password error, parameter error, etc., depending on the value of msg in the prompt. And there will be multiple tasks in the playbook, and one of the tasks in the middle will not continue to be executed in such a situation.

Play Book Executive Control

Playbook is a very simple configuration management system and the basis of a multi-machine deployment system, which is very suitable for complex application deployment. At the same time, Playbooks can also be used to declare configurations, and to orchestrate an orderly execution process, so that specified steps can be executed in an orderly manner among multiple groups of machines, or tasks can be initiated synchronously or asynchronously.

Ansible officially uses the YAML format to write Playbooks by default, which greatly simplifies the syntax format, and the key-value format also makes reading and writing more convenient. We know that Playbooks is composed of one or more plays, that is, its content is a list of plays as elements. The content of play is also called a task, and executing a task is a call to a module.

---
- hosts: test
  remote_user: root
  vars:

  tasks:
    - name: Install the package "bc"
      apt:
        name: bc
        state: present
  handlers:
...

Structure description:

• Hosts and users (hosts)

  • The hosts parameter represents one or more groups or hosts, separated by commas.
  • remote_user indicates the user name, and become: true can also be used here to indicate the use of sudo privileges to perform operations. (I didn't notice this operation, it requires an additional echo password, and the operation of sudo -S is too cumbersome, and each step needs to be added)

• vars (variables)
  can be defined using variables in the task line, enclosed in "{ {item}}" like this. The jinjia2 syntax separates variables, which can facilitate later modification and maintenance, and can also be used in other tasks.
  
  
  Variable definitions can be placed in the following places:

  1. Inventory
  2. In the global (var:) or in a task (task)
  3. Used to store separate files in the roles structure
  4. Register variables in the registered module, mainly for debugging and judgment

• Tasks (tasks)
  are executed from top to bottom when running the playbook, and the next task will be executed after a task is executed on all its corresponding hosts. If a host fails to execute the task, the host will be removed from the rotation of the entire playbook. If the execution fails, the error in the playbook needs to be corrected and then executed again.
  
  Each task must have a name, so that when the task is output, it can be clearly identified to which task it belongs. If it is not defined, it will be specifically marked.

• handlers
  Handlers (optional) are no different from normal tasks, and are also a list item, just refer to it by name. Handlers are notified by the notifier. If they are not notified, the handlers will not be executed. No matter how many notifiers have notified, the handlers will only be executed once after all tasks are executed. At the same time handlers will also be executed in the order in which they are declared.
  
  The best application scenario for Handlers is to restart a service or trigger a system restart operation, other than that it is rarely used.

Of course, the above template is only a part of the statement of the playbook. You can find the usage conditions and writing specifications of other statements on the official website . I won't introduce too much here. You can do it by service、shell、condition、whenmastering the above few examples. The following is an example of installing a package:多服务器修改同文件文件传输服务启动

#  在指定目录下创建一个文件，并赋予权限
- name: create a file
    file:
         path: /home/file
         state: touch
         owner: shiyanlou
         mode: 'u+rw,g+rw'

# 复制一个文件到指定目录
  - name: copy a file
    copy:
         src: /etc/ansible/ansible.cfg
         dest: /home/file

# 安装一个软件包
- hosts: test
  become: true
  vars:
      apt_packages_ca:
         - apt-transport-https
         - ca-certificates
         - apparmor-utils

  tasks:
    - name: add CA certificates are installed.
      apt:
          name: "{
    
    { item }}"
          update_cache: yes
      with_items: apt_packages_ca

Loop:

Here I mainly want to record the loop (Loop), because I have not used it before. If you want to create a large number of users or install many packages in a single task, or repeat the polling step, this can be achieved efficiently through a loop. Similar to general loops, playbook also has standard loops, nested loops, hash loops, Do-Until loops, etc. Here we only explain a few simple loop statements. For details, please refer to the official Loop section.

demo：

# demo1：添加多个用户
- name: add several users
  user:
    name: "{
    
    { item }}"
    state: present
    groups: "ubuntu"
  with_items:
     - testuser1
     - testuser2

# demo2：给用户赋予多个数据库权限
- name: give users access to multiple databases
  mysql_user:
  name: "{
    
    { item[0] }}"
  priv: "{
    
    { item[1] }}.*:ALL"
  append_privs: yes
  password: "xxxx"
  with_nested:
    - [ 'Jay', 'Chou' ]
    - [ '20220311_db', '20220312_db', '20220313_db' ]

# demo3：打印一下条件输出
---
- hosts: test

  tasks:
      - name: test condition
        command: echo {
    
    {
    
     item }}
        with_items: [ 0, 2, 4, 6, 8, 10 ]
        when: item > 5
...

item: The location to place the variable that needs to be read

with_items: used to specify the value to be read out

when: List the conditions for judgment, execute the command if the condition is true, skip skipping if it is false

The execution command of the playbook is:

$ sudo vim test.yaml
$ ansible-playbook test.yaml

As for this, the official finally gave an example of docker.yml to install docker with playbook. At present, it seems to me that it is unnecessary. In fact, from the perspective of multiple servers, if it is a new machine and there is a cluster plan, Manufacturers usually come with docker versions above 2019. Of course, with the exception of a domestic system, the docker problem bugged me for a while, and various error reports made me stunned. As a result, the version was the first half of 2018 version, and re-installation was required. After updating various dependencies, after finishing one, the rest of the entire system is directly ghosted, and I don't bother to enter it again.

Then there are many parameters and debug settings in ansible-playbook, and there are many Development Plugins in the community, but I basically don't use them. My usage scenario is very simple, that is, to update different files according to the different configurations of the server, or start the project again, But the project is in the image, the ansible process cannot control the process of the docker image, which is determined by the operating system and is also a rule. So most of my operations are written in sh scripts, or docker-compose, and then let ansible call them. As for why I don't use docker swarm or k8s, I can only say iterative updates in work, not by one person. After all, unless you say that a certain field is very complete and the architecture is very clearly defined, you will always try various things. According to simple principles, it is like a popular joke on the Internet: people and programs, only one can run. ! emmm. . .