Gestión de Parchas

Dado que una actualización de sistema rara vez es solo un yum update -y, gestión de parchas es un rol de Ansible para manejar fácilmente el proceso de actualización y todo lo relacionado con ello para servidores que utilizan los sistemas operativos RedHat, CentOS, Debian o Ubuntu.

Durante la gestión de parchas, si deseas:

• establecer el objetivo en un modo de mantenimiento en tu supervisión
• enviar un mensaje al principio o al final del proceso
• reaccionar en caso de fallas
• etc.

este rol te facilitará la vida.

En cualquier caso, recuerda que nunca debes conectarte a un servidor para realizar su actualización.

Requisitos

Nada especial.

Características

• Tomar notas sobre el sistema: dirección IP y rutas, procesos en ejecución, puntos de montaje (¡para solucionar problemas! ¡No lo olvides!)
• Ejecutar tareas personalizadas para todos los servidores (ver variable pm_before_update_tasks_file)
• Ejecutar tareas personalizadas para el servidor objetivo (ver capítulo de ejemplo de playbook)

Nuestro objetivo principal:

• Parchar el servidor con apt o yum

Y después:

• Establecer hechos de Ansible con la fecha actual y, si se desea, una variable de entorno.
• Ejecutar tareas personalizadas para el servidor objetivo (ver capítulo de ejemplo de playbook)
• Ejecutar tareas personalizadas para todos los servidores (ver variable pm_after_update_tasks_file)

Variables del Rol

• pm_restart_after_update: por defecto true

¿Se reiniciará el objetivo después de la gestión de parchas? Esto asegura que el último núcleo esté en ejecución y que el servidor y sus servicios puedan reiniciarse. Considera hacerlo regularmente.

• pm_logpath: por defecto /etc/ansible/facts.d/PM.log

¿Dónde almacenar la fecha de las gestiones de parchas que fueron exitosas o fallidas?

• pm_date_format: por defecto "{{ ansible_date_time.date }}-{{ ansible_date_time.time }}"

¿Cómo se formatea la fecha en el hecho y en la ruta del registro?

• pm_fact_name: por defecto pm

¿Cuál es el nombre del hecho que queremos?

• pm_set_env_variable: por defecto true
• pm_env_file_path: por defecto /etc/profile.d/last_pm_date.sh

¿Establecemos una variable de entorno con la fecha de la última gestión de parchas y dónde guardamos el script?

• pm_manage_yum_clean_all: por defecto true

Lanzar un yum clean all antes de actualizar. Debes establecerlo en false si, por ejemplo, ya descargaste los RPM.

• pm_manage_apt_clean: true

Lanzar un apt clean antes de actualizar.

• pm_manage_apt_autoremove: true

Eliminar automáticamente los paquetes deb.

• pm_apt_verbose_package_list: false

Imprimir la lista de resultados de apt.

• pm_before_update_tasks_file:

Por ejemplo custom_tasks/pm_before_update_tasks_file.yml. Puedes configurar el rol para ejecutar este archivo de tareas antes de actualizar el servidor. Cada tarea en el archivo objetivo será ejecutada.

Considera incluir tareas como enviar un mensaje, tomar un snapshot, establecer un modo de mantenimiento, etc.

• pm_after_update_tasks_file:

Por ejemplo custom_tasks/pm_after_update_tasks_file.yml. Puedes configurar el rol para ejecutar este archivo de tareas después de actualizar el servidor. Cada tarea en el archivo objetivo será ejecutada.

Ejemplo de Playbook

Configurar un playbook es bastante fácil como puedes ver:

- name: Iniciar una Gestión de Parchas
  hosts: servidores
  vars:
    pm_before_update_tasks_file: custom_tasks/pm_before_update_tasks_file.yml
    pm_after_update_tasks_file: custom_tasks/pm_after_update_tasks_file.yml
  tasks:
    - name: "Incluir gestión de parchas"
      include_role:
        name: "alemorvan.patchmanagement"

Además de este playbook, puedes crear 2 otros archivos de tareas por servidor que se ejecutarán antes y después de actualizarlos. Es útil, por ejemplo, para eliminar nodos de un balanceador de carga, vaciar cachés, reiniciar servicios, etc.

A diferencia de las variables pm_before_update_tasks_file y pm_after_update_tasks_file (que apuntan a archivos de tareas que realizan acciones para todos los objetivos), estos archivos se centran en acciones específicas de un solo servidor.

En el directorio del playbook, crea el directorio custom_tasks y archivos llamados before_pm_{{ inventory_hostname_short }}_custom_tasks.yml y after_pm_{{ inventory_hostname_short }}_custom_tasks.yml.

  - name: Ejecutar tareas personalizadas para este servidor definidas gracias al archivo after_pm_{{ inventory_hostname_short }}_custom_tasks.yml.
    debug:
      msg: "Esta tarea es una tarea personalizada definida en el archivo after_pm_{{ inventory_hostname_short }}_custom_tasks.yml"

Pruebas con Molecule

Puedes probar este rol a través de molecule y docker:

  $ molecule test

Consulta molecule/default/converge.yml para un buen ejemplo de cómo usar este rol.

Licencia

MIT

Información del Autor

Este rol fue escrito originalmente por Antoine Le Morvan para Vivalto Sante, basado en el trabajo de Nicolas Martin y el equipo de Ansible en Claranet Francia / BU RMP (Ismaël Ouattara y EliE Deloumeau).