Define el orden de ejecución de las tareas en Ansible con estas dos palabras clave

Los lectores habituales de Enable Sysadmin saben que la mayoría de nosotros somos grandes fans de Ansible. Nos gusta especialmente usar roles de Ansible para diseñar código reutilizable de manera efectiva. Un libro de jugadas sigue a un orden de ejecución cuándo se ejecuta, y hay varias formas de controlar el orden en que se ejecutan las tareas. En este artículo, echaré un vistazo a dos características particularmente útiles de Ansible, pre_tareas y post_tareas. Lo guiaré a través de algunos ejemplos reales (y simples) de cómo estas funciones pueden agregar flexibilidad adicional a sus libros de jugadas al realizar tareas en diferentes momentos durante la ejecución de un libro de jugadas.

En primer lugar, voy a definir pre_tareas y post_tareas. Probablemente ya hayas adivinado lo que están haciendo. Definir pre_tareas en un playbook hará que estas tareas se realicen antes que todas las demás tareas, incluidos los roles. Definir post_tareas es lo contrario: estas tareas se ejecutarán después de todas las demás, incluidos todos los controladores definidos por otras tareas. Es un concepto simple y los siguientes ejemplos ilustran cómo puede implementarlo en su entorno.

Índice

    Administración de hosts en un equilibrador de carga

    Mi aspecto favorito 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 mientras ejecuta un libro de jugadas. Comenzaré con un ejemplo de equilibrio de carga. Siempre desea minimizar el tiempo de inactividad de los sistemas de producción, y muchas arquitecturas utilizan el equilibrio de carga para lograrlo. Por lo general, es una buena idea eliminar un sistema de back-end de un balanceador de carga mientras se realiza un trabajo disruptivo y luego volver a agregarlo una vez que se haya realizado el trabajo. Ansible pre_tareas y post_tareas hazlo facil.

    El siguiente libro de jugadas extraerá un servidor de un balanceador de carga HAProxy, ejecutará parches completos con un reinicio y luego agregará el servidor nuevamente 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

    Realización de tareas de configuración inicial

    el pre_tareas La sección también puede ser útil para definir hechos con valores obtenidos en tiempo de ejecución. Por ejemplo, imagine que algunos de sus roles se basan en conocer la última versión disponible de su software. Puede obtener esta información de su servidor de artefactos en el pre_tareas sección y establezca un hecho al que puedan acceder las tareas en sus roles. En este ejemplo, el última_versión_aplicación El hecho se establece llamando a un punto final de la API. Debido a que la llamada a la API solo se ejecuta si el última_versión_aplicación no está definido, todavía permite que un usuario anule este hecho. El hecho está disponible para todos los roles 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 suena confuso, consulte mi artículo sobre la interacción con puntos finales web mediante Ansible.

    Silenciar un sistema bajo vigilancia

    El último ejemplo que mostraré es muy similar al ejemplo anterior de equilibrio de carga. Es común silenciar un host en un sistema de vigilancia antes de comenzar cualquier trabajo en él. Una vez finalizado el trabajo, se puede volver a habilitar la supervisión del host. Ansible pre_tareas y post_tareas hágalo más fácil si su sistema de vigilancia admite solicitudes HTTP, que es lo que hace en su mayoría:

    $ 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 entiende

    Los ejemplos anteriores incluyen tareas definidas directamente en el libro de jugadas. Si bien esto puede estar bien para una o dos tareas, puede desordenar rápidamente sus libros de jugadas. Tampoco es muy reutilizable: diferentes libros de jugadas deberían duplicar estas tareas.

    Puede usar la función integrada de Ansible incluir capacidad de crear código más limpio y reutilizable. En el siguiente ejemplo, he colocado mis tareas de monitoreo en su propio directorio dentro de un tasks/ directorio telefónico. Esto hace que mi código sea mucho 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 el tasks/ directorio bajo un rol particular. Para aclarar este punto, 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

    Envoltura

    En este artículo, lo he guiado a través de algunos ejemplos de cómo Ansible pre_tareas y post_tareas La función facilita la adopción de medidas al principio y al final de sus libros de jugadas. Esta característica puede ser útil para todo, desde silenciar hosts mientras se monitorean hasta enviar alertas a sus herramientas de chat internas sobre ejecuciones exitosas de libros de jugadas. Estoy seguro de que encontrará algunos usos excelentes para esta función al crear libros de jugadas más complejos en su propia organización.

     

    Artículos de interés

    Subir