Use estas dos palabras clave para establecer el orden de ejecución de tareas en Ansible

Los lectores habituales de Enable Sysadmin saben que la mayoría de nosotros somos grandes admiradores de Ansible. Nos gusta especialmente usar roles de Ansible para diseñar código reutilizable de manera efectiva.El guión sigue un orden de ejecución Cuando se ejecuta, hay varias formas de controlar el orden en que se ejecutan las tareas. En este artículo, presentaré dos características de Ansible particularmente útiles, pre_tareas y post_tareasLo guiaré a través de algunos ejemplos reales (y simples) de cómo estas características pueden agregar flexibilidad adicional a su libro de jugadas al realizar tareas en varios puntos durante la ejecución del libro de jugadas.

Primero, definiré pre_tareas y post_tareasEs posible que hayas adivinado lo que hicieron.definición pre_tareas En un libro de jugadas, estas tareas se ejecutarán antes que todas las demás tareas (incluidos los roles).definición post_tareas En su lugar, estas tareas se ejecutarán después de todas las demás tareas, incluidos los controladores definidos por otras tareas. Es un concepto simple y los siguientes ejemplos ilustran cómo usarlo en su entorno.

Administrar hosts en un balanceador de carga

Uno de mis aspectos favoritos de Ansible es su flexibilidad: puede usar Ansible para la administración de la configuración y como una herramienta de orquestación para interactuar con múltiples sistemas durante la ejecución de un libro de jugadas. Comenzaré con un ejemplo de equilibrio de carga. Siempre desea minimizar la interrupción de los sistemas de producción, y muchas arquitecturas utilizan el equilibrio de carga para lograrlo. Por lo general, es una buena idea extraer el sistema de back-end del balanceador de carga mientras se realiza un trabajo destructivo y luego volver a agregarlo cuando se realiza el trabajo. de ansible pre_tareas y post_tareas Haz esto fácil.

El siguiente libro de jugadas extraerá el servidor del balanceador de carga HAProxy, ejecutará el parche completo con un reinicio y luego volverá a agregar el servidor después de que se complete la función del parche:

$ cat patch-webservers.yml 
---

- hosts: webservers
  pre_tasks:
    - name: Disable web server in load balancer
      community.general.haproxy:
        state: disabled
        host: '{{ inventory_hostname_short }}'
        fail_on_not_found: yes
      delegate_to: loadbalancer.example.com
  roles:
    - full_patches
  post_tasks:
    - name: Enable web server in load balancer
      community.general.haproxy:
        state: enabled
        host: '{{ inventory_hostname_short }}'
        fail_on_not_found: yes
      delegate_to: loadbalancer.example.com

Realizar tareas de configuración inicial

Esta pre_tareas Las secciones también se pueden utilizar para establecer hechos con valores obtenidos en tiempo de ejecución. Por ejemplo, suponga que algunas de sus funciones dependen de conocer la última versión disponible de su software.Puede obtener esta información de su servidor de artefactos pre_tareas sección y establece un hecho al que se puede acceder mediante tareas en tu personaje. En este ejemplo, última_aplicación_versión El hecho se establece llamando al punto final de la API.Dado que las llamadas API se realizan solo en última_aplicación_versión No definido, todavía permite al usuario anular este hecho. Ese hecho está disponible para todos los personajes en este libro de jugadas. Se parece a esto:

$ cat software-version.yml 
---
- hosts: webservers
  pre_tasks:
    - name: Get latest software version from artifact server
      ansible.builtin.uri:
        url: http://artifact-server.example.com:8080/software/latest
        return_content: yes
      delegate_to: localhost
      register: uri_output
      when: latest_app_version is not defined

    - name: Set latest_software_version fact
      ansible.builtin.set_fact:
        latest_app_version: "{{ uri_output.json.version }}"
      when: latest_app_version is not defined

    - name: Print latest_app_version
      ansible.builtin.debug:
        msg: "{{ latest_app_version }}"
  roles:
    - appserver
    - apache
    - monitored_host

Si este código parece confuso, consulte mi artículo sobre el uso de Ansible para interactuar con los puntos finales web.

Silenciar el sistema bajo supervisión

El último ejemplo que mostraré es muy similar al ejemplo anterior de equilibrio de carga. Antes de comenzar cualquier trabajo en él, la unidad principal generalmente se silencia en un sistema de monitoreo. Una vez que se completa el trabajo, puede volver a habilitar la supervisión del host. Ansible pre_tareas y post_tareas Si su sistema de monitoreo admite solicitudes HTTP, puede hacerlo fácilmente, en la mayoría de los casos:

$ cat patch-databases.yml 
---
- hosts: database_servers
  pre_tasks:
    - name: Silence host in monitoring
      ansible.builtin.uri:
        url: "http://monitoring-server.example.com:8080/hosts/{{ inventory_hostname }}/schedule_downtime"
        method: POST
        body_format: json
        body:
          downtime_duration: 30m
      delegate_to: localhost
  roles:
    - full_patches
  post_tasks:
    - name: Re-enable host in monitoring
      ansible.builtin.uri:
        url: "http://monitoring-server.example.com:8080/hosts/{{ inventory_hostname }}/clear_downtime"
        method: POST
        body_format: json
      delegate_to: localhost

Una palabra sobre incluir

El ejemplo anterior incluye tareas definidas directamente en el libro de jugadas. Si bien esto podría estar bien para una o dos tareas, puede saturar rápidamente su secuencia de comandos. Tampoco es muy reutilizable: diferentes libros de jugadas necesitan replicar estas tareas.

[ Need more on Ansible? Take a free technical overview course from Red Hat. Ansible Essentials: Simplicity in Automation Technical Overview. ]

Puede utilizar el integrado de Ansible incluir Capacidad para crear código más limpio y reutilizable.En el siguiente ejemplo, he colocado la tarea de monitoreo en su propio directorio en el directorio de nivel superior tasks/ contenido. Esto hace que mi código sea más limpio y permite que otros playbooks reutilicen estas tareas:

$ cat patch-databases-with-include.yml
---
- hosts: database_servers
  pre_tasks:
    - name: Silence host in monitoring
      ansible.builtin.include: tasks/monitoring/silence-host.yml
  roles:
    - full_patches
  post_tasks:
    - name: Enable host in monitoring
      ansible.builtin.include: tasks/monitoring/enable-host.yml

Tenga en cuenta que esto tasks/ El directorio está en el mismo directorio que mi libro de jugadas principal, y No Esta tasks/ Un directorio bajo cualquier rol específico. Para que esto quede más claro, la estructura del directorio se ve así:

$ tree --noreport
├── ansible.cfg
├── inventory.ini
├── patch-databases-with-include.yml
├── patch-databases.yml
├── patch-webservers.yml
├── roles
│   ├── apache
│   │   └── tasks
│   │       └── main.yml
│   ├── appserver
│   │   └── tasks
│   │       └── main.yml
│   ├── full_patches
│   │   └── tasks
│   │       └── main.yml
│   └── monitored_host
│       └── tasks
│           └── main.yml
├── software-version.yml
├── tasks
│   └── monitoring
│       ├── enable-host.yml
│       └── silence-host.yml
└── templates
    └── hosts.j2

envolver

En este artículo, le presenté varios ejemplos de Ansible pre_tareas y post_tareas Las características le permiten realizar acciones fácilmente al principio y al final de su libro de jugadas. Esta función es útil para todo, desde silenciar un host bajo supervisión hasta enviar alertas a su herramienta de chat interna cuando un libro de jugadas se ejecuta correctamente. Estoy seguro de que encontrará usos interesantes para esta función a medida que cree libros de jugadas más complejos en su propia organización.

[ Learn more about server and configuration management by downloading the free eBook Ansible for DevOps. ]