Notas de estudio básico de automatización de Ansible

Introducción

En esta sección se explican principalmente las herramientas de Ansible. Aunque Chef, Puppet, SaltStack y Fabric (se analizarán en capítulos posteriores) son todas herramientas populares de administración automatizada de operación y mantenimiento, son mucho más complicadas que Ansible, pero cada herramienta también tiene sus propias ventajas. aquí aprenderemos primero esta herramienta de mantenimiento y operación automatizada relativamente simple: Ansible.

Ansible es una herramienta de mantenimiento y operación automatizada basada en el desarrollo de python que puede realizar la configuración del sistema por lotes, la implementación de programas, la ejecución de comandos y otras funciones. Ansible funciona principalmente en base a módulos y no tiene la capacidad de implementarse por lotes. La función de implementación real es el módulo en ejecución.

• Ansible: se ejecuta en la computadora central;

• Complementos de conexión: complementos de conexión, utilizados principalmente para la conexión y comunicación entre el local y el operador;

• Host Inventory: El host que especifica la operación es el host que define el monitoreo en un archivo de configuración;

• Módulos: módulos básicos, módulos personalizados, etc.;

• Complementos: use complementos para completar funciones como registro, correo electrónico, etc.;

• Playbooks: multitarea, implemente módulos en nodos a través de SSH, ya sea múltiples nodos o un solo nodo.

Ansible tiene dos tipos principales de servidores: máquinas de control y nodos. La máquina de control se usa para la coordinación del control, y los nodos son administrados por la máquina de control a través de SSH, y la máquina de control describe la ubicación de los nodos a través del inventario. En la orquestación de nodos, Ansible implementa módulos en nodos a través de SSH, los módulos se almacenan temporalmente en nodos y se comunican con el protocolo JSON de salida estándar para recuperar información, enviar comandos, etc. en máquinas remotas.

entorno de laboratorio

Para los dos servidores en la nube de Tencent, el entorno de host Python no ha cambiado, excepto que el servidor se instaló con Docker.

• Servidor ligero 106.55.50.77
• Servidor G4 150.158.115.54

instalación ansible

Hay dos formas de instalar ansible, como supervisor, se puede instalar con pip de python, o se puede instalar directamente con apt-get, para evitar pisar el foso, elijo instalarlo directamente aquí.

# 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

Después de que la instalación no tenga errores, puede ingresar algunos comandos simples para ver el estado actual, ansible --version para ver el estado de ejecución actual:

$ 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 puede operar en una o varias máquinas o en algunas máquinas al mismo tiempo a través de Inventario. El inventario se guarda en el archivo de configuración /etc/ansible/hosts de manera predeterminada, y Ansible puede conocer el servidor para rastrear a través de este archivo. Aquí podemos agregar comunicación ssh a otro servidor y escriba la información de configuración ssh:

$ vim /etc/ansible/hosts

[test]
150.158.115.54 ansible_ssh_user=root ansible_ssh_pass=xxxxx

Aquí para explicar, el archivo de inventario puede tener muchos formatos diferentes (como: INI, YAML, etc.), dependiendo del complemento correspondiente, aquí damos algunos ejemplos del formato predeterminado de Ansible (INI), podemos ver los siguientes Algunos ejemplos, el anterior que uso es el método de contraseña ssh:

# 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

Los tres métodos de conexión se definen como:

Conexión de anfitrión:

• ansible_connectionEl tipo de conexión al host, cualquier posible nombre de complemento de conexión, por ejemplo, tipo de protocolo SSH con: ssh, smarto paramiko.

Conexión general:

• ansible_hostEl nombre del host al que conectarse.

• ansible_portnúmero de puerto ssh.

• ansible_userNombre de usuario ssh predeterminado.

Conexión SSH específica:

• ansible_ssh_pass sshclave

• ansible_ssh_private_key_fileArchivo de clave privada utilizado por ssh.

Orden Temporal AD-HOC

ad-hoc : Comandos temporales, que son comandos que realizan ciertas operaciones rápidamente después de ingresar contenido, pero no quieren guardarlas.

En general, Ansible se basa principalmente en la creación de secuencias de comandos de libros de jugadas que aprenderemos más adelante, pero en comparación con ad-hoc, su ventaja es que cuando recibe una tarea temporal, solo necesita ejecutar rápida y fácilmente un comando ad-hoc ad hoc. en lugar de escribir un guión de libro de jugadas completo.

Sabemos que Ansible implementa principalmente varias funciones a través de módulos, operemos el comando ad-hoc a través del módulo simple de ping.

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

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

La siguiente figura es el proceso experimental:

puede ver que puede haber un error en la figura después de realizar la primera operación. La razón principal es que la CLAVE DE HOST debe verificarse y verificarse durante la conexión ssh. Puede usar el -oparámetro para StrictHostKeyCheckingestablecerlo en no para deshabilitar temporalmente la verificación. Si desea guardar la configuración, puede modificar el archivo de configuración de Ansible /etc/ansible/ansible.cfgy host_key_checkingeliminar el comentario en el archivo . Haga lo siguiente:

Después de completar la modificación, realice la misma operación nuevamente y verá el éxito. Además, hay algunos otros comandos básicos:

# 查看操作机器信息
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'

Para las operaciones y resultados AD-HOC anteriores, podemos ver que los tipos devueltos son:

• success: Este resultado indica que la operación es exitosa, existen dos casos, el primer caso es cuando se realizan algunas operaciones simples de la consulta y no se necesita modificar el contenido, indicando que la operación no tiene problema, el segundo caso es cuando la operación se ha ejecutado y luego Cuando se ejecuta, indicará directamente el éxito.

• changed: verdadero Este resultado indica que algunas operaciones de modificación realizadas con éxito, como la creación de un archivo anterior, o la modificación de un archivo de configuración, la copia de un archivo, etc. tendrán tales resultados.

• failed: este resultado indica que la operación falló, lo que puede ser un error de contraseña, error de parámetro, etc., según el valor de msg en el aviso. Y habrá múltiples tareas en el libro de jugadas, y una de las tareas en el medio no seguirá ejecutándose en tal situación.

Control ejecutivo de Play Book

Playbook es un sistema de administración de configuración muy simple y la base de un sistema de implementación de múltiples máquinas, que es muy adecuado para la implementación de aplicaciones complejas. Al mismo tiempo, los Playbooks también se pueden usar para declarar configuraciones y orquestar un proceso de ejecución ordenado, de modo que los pasos específicos se puedan ejecutar de manera ordenada entre múltiples grupos de máquinas, o las tareas se puedan iniciar de forma sincrónica o asincrónica.

Ansible usa oficialmente el formato YAML para escribir Playbooks de forma predeterminada, lo que simplifica enormemente el formato de sintaxis, y el formato de clave-valor también hace que leer y escribir sea más conveniente. Sabemos que Playbooks está compuesto por una o más obras, es decir, su contenido es una lista de obras como elementos. El contenido del juego también se denomina tarea, y la ejecución de una tarea es una llamada a un módulo.

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

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

Descripción de la estructura:

• Hosts y usuarios (hosts)

  • El parámetro hosts representa uno o más grupos o hosts, separados por comas.
  • remote_user indica el nombre de usuario, y Become: true también se puede usar aquí para indicar el uso de privilegios de sudo para realizar operaciones. (No noté esta operación, requiere una contraseña de eco adicional, y la operación de sudo -S es demasiado engorrosa, y cada paso debe agregarse)

• vars (variables)
  se pueden definir usando variables en la línea de tareas, encerradas en "{ {item}}" como esta. La sintaxis de jinjia2 separa variables, lo que puede facilitar su posterior modificación y mantenimiento, y también puede utilizarse en otras tareas.
  
  
  Las definiciones de variables se pueden colocar en los siguientes lugares:

  1. Inventario
  2. En el global (var:) o en una tarea (task)
  3. Se utiliza para almacenar archivos separados en la estructura de funciones
  4. Registrar variables en el módulo registrado, principalmente para depuración y juicio

• Las tareas (tareas)
  se ejecutan de arriba a abajo cuando se ejecuta el libro de jugadas, y la siguiente tarea se ejecutará después de que se ejecute una tarea en todos sus hosts correspondientes. Si un host no puede ejecutar la tarea, el host se eliminará de la rotación de todo el libro de jugadas. Si la ejecución falla, el error en el libro de jugadas debe corregirse y luego ejecutarse nuevamente.
  
  Cada tarea debe tener un nombre, de manera que al salir la tarea se pueda identificar claramente a qué tarea pertenece, si no se define se marcará específicamente.

• handlers Los handlers
  (opcionales) no son diferentes de las tareas normales, y también son un elemento de la lista, simplemente consúltelos por su nombre. Los controladores son notificados por el notificador. Si no son notificados, los controladores no se ejecutarán. No importa cuántos notificadores hayan notificado, los controladores solo se ejecutarán una vez después de que se hayan ejecutado todas las tareas. Al mismo tiempo, los controladores también se ejecutarán en el orden en que se declaran.
  
  El mejor escenario de aplicación para los controladores es reiniciar un servicio o desencadenar una operación de reinicio del sistema, aparte de que rara vez se usa.

Por supuesto, la plantilla anterior es solo una parte de la declaración del libro de jugadas. Puede encontrar las condiciones de uso y las especificaciones de escritura de otras declaraciones en el sitio web oficial . No introduciré demasiado aquí. Puede hacerlo service、shell、condition、whendominando el por encima de algunos ejemplos. El siguiente es un ejemplo de instalación de un paquete:多服务器修改同文件文件传输服务启动

#  在指定目录下创建一个文件，并赋予权限
- 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

Círculo:

Aquí principalmente quiero grabar el bucle (Loop), porque no lo he usado antes. Si desea crear una gran cantidad de usuarios o instalar muchos paquetes en una sola tarea, o repetir el paso de sondeo, esto se puede lograr de manera eficiente a través de un bucle. Al igual que los bucles generales, el libro de jugadas también tiene bucles estándar, bucles anidados, bucles hash, bucles Do-Until, etc.

manifestación:

# 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: La ubicación para colocar la variable que necesita ser leída

with_items: se utiliza para especificar el valor que se va a leer

when: Enumere las condiciones para el juicio, ejecute el comando si la condición es verdadera, omita la omisión si es falsa

El comando de ejecución del libro de jugadas es:

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

En cuanto a esto, el funcionario finalmente dio un ejemplo de docker.yml para instalar docker con playbook. En este momento, me parece que es innecesario. De hecho, desde la perspectiva de varios servidores, si es una máquina nueva y hay es un plan de clúster, los fabricantes generalmente vienen con versiones de docker superiores a 2019. Por supuesto, con la excepción de un sistema doméstico, el problema de docker me molestó por un tiempo y varios informes de errores me sorprendieron. Como resultado, la versión fue la primera mitad de la versión 2018, y se requirió reinstalación.Después de actualizar varias dependencias, después de terminar una, el resto de todo el sistema está directamente fantasma, y ​​no me molesto en ingresarlo nuevamente.

Luego, hay muchos parámetros y configuraciones de depuración en ansible-playbook, y hay muchos complementos de desarrollo en la comunidad, pero básicamente no los uso. Mi escenario de uso es muy simple, es decir, actualizar diferentes archivos de acuerdo con diferentes configuraciones. del servidor, o iniciar el proyecto nuevamente, pero el proyecto está en la imagen, el proceso ansible no puede controlar el proceso de la imagen acoplable, que está determinado por el sistema operativo y también es una regla. Entonces, la mayoría de mis operaciones están escritas en scripts sh, o docker-compose, y luego dejo que ansible las llame. En cuanto a por qué no uso docker swarm o k8s, solo puedo decir actualizaciones iterativas en el trabajo, no por una sola persona. Después de todo, a menos que diga que un campo determinado es muy completo y la arquitectura está muy claramente definida, siempre intentará varias cosas. Según principios simples, es como una broma popular en Internet: personas y programas, solo uno puede corre. ! emmm. . .