Introducción
Los handlers son tareas especiales de Ansible que se ejecutan únicamente cuando son notificadas por una tarea que ha realizado cambios. Se utilizan habitualmente para recargar y reiniciar servicios.
En este laboratorio, implementará una unidad de systemd de demostración segura, notificará a los handlers cuando el archivo de la unidad cambie y verificará que el servicio esté activo y habilitado.
Crear un proyecto de automatización de servicios
En este paso, creará un proyecto para la automatización de servicios. Este laboratorio utiliza un alias de host local porque el servicio representa un estado real del sistema en la máquina virtual RHEL 10.
cd /home/labex/project
mkdir -p rhce-ansible/{inventory,files,playbooks,reports}
cd rhce-ansible
cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
host_key_checking = False
retry_files_enabled = False
EOF
cat > inventory/hosts <<'EOF'
[service_hosts]
host ansible_connection=local
EOF
Incluso con una conexión local, el playbook gestionará el estado real de systemd en la máquina virtual. Por eso este laboratorio utiliza un alias de host y become: true más adelante, en lugar de simular que existen varios hosts de servicio independientes.
Crear un archivo de unidad de systemd de demostración
En este paso, creará el archivo de unidad de origen que Ansible copiará en /etc/systemd/system. El servicio ejecuta /usr/bin/sleep infinity, por lo que es seguro y fácil de verificar.
Antes de ejecutar los comandos en este paso, regrese al directorio del proyecto de Ansible. Esto mantiene la estabilidad de los comandos incluso cuando LabEx ejecuta cada paso por separado.
cd /home/labex/project/rhce-ansible
cat > files/rhce-handler-demo.service <<'EOF'
[Unit]
Description=RHCE handler demo service
[Service]
Type=simple
ExecStart=/usr/bin/sleep infinity
Restart=always
RestartSec=1
[Install]
WantedBy=multi-user.target
EOF
Esta unidad es inofensiva por diseño: inicia un proceso sleep de larga duración y lo reinicia si se detiene. La sección [Install] permite que Ansible habilite el servicio para multi-user.target.
sed -n "1,12p" files/rhce-handler-demo.service
Verifique las líneas ExecStart y WantedBy antes de continuar. Si el archivo de unidad de origen es incorrecto, Ansible implementará fielmente la definición de servicio errónea.
Escribir un playbook con Handlers
En este paso, escribirá un playbook que copie el archivo de unidad y notifique a los handlers. La tarea meta: flush_handlers ejecuta los handlers pendientes antes de la tarea del servicio, de modo que systemd reconozca la nueva unidad.
Antes de ejecutar los comandos en este paso, regrese al directorio del proyecto de Ansible.
cd /home/labex/project/rhce-ansible
cat > playbooks/manage-service.yml <<'EOF'
---
- name: Deploy and manage the demo service
hosts: service_hosts
become: true
gather_facts: false
tasks:
- name: Install demo systemd unit
ansible.builtin.copy:
src: ../files/rhce-handler-demo.service
dest: /etc/systemd/system/rhce-handler-demo.service
mode: '0644'
notify:
- Reload systemd
- Restart demo service
- name: Run handlers before enabling the service
ansible.builtin.meta: flush_handlers
- name: Ensure demo service is active and enabled
ansible.builtin.systemd:
name: rhce-handler-demo.service
state: started
enabled: true
handlers:
- name: Reload systemd
ansible.builtin.systemd:
daemon_reload: true
- name: Restart demo service
ansible.builtin.systemd:
name: rhce-handler-demo.service
state: restarted
EOF
La tarea copy notifica a dos handlers solo cuando el archivo de unidad cambia. meta: flush_handlers ejecuta cualquier handler pendiente antes de que la tarea systemd inicie y habilite el servicio, lo cual es crucial porque systemd debe recargar los archivos de unidad antes de reconocer un nuevo servicio.
ansible-playbook playbooks/manage-service.yml --syntax-check
La verificación de sintaxis debe ser exitosa antes de que el playbook escriba en /etc/systemd/system. Esto detecta errores de sangría en la lista de tareas y en la sección handlers sin alterar el estado del servicio.
Ejecutar el playbook y verificar el servicio
En este paso, ejecutará el playbook del servicio. La primera ejecución debería instalar la unidad, recargar systemd, iniciar el servicio y habilitarlo para el arranque. Antes de ejecutar los comandos en este paso, regrese al directorio del proyecto de Ansible.
cd /home/labex/project/rhce-ansible
ansible-playbook playbooks/manage-service.yml | tee reports/service-first-run.txt
La primera ejecución debería copiar el archivo de unidad, recargar systemd, reiniciar el servicio de demostración a través del handler y luego asegurar que el servicio esté habilitado. Guardar la salida le permite revisar si la ruta del handler se ejecutó.
systemctl is-active rhce-handler-demo.service
systemctl is-enabled rhce-handler-demo.service
is-active verifica el estado de ejecución durante el arranque actual, mientras que is-enabled comprueba si el servicio está vinculado a un objetivo de arranque. Las tareas de servicio RHCE a menudo requieren ambos estados.
Modificar el archivo de unidad y activar el handler nuevamente
En este paso, realizará un cambio controlado en el archivo de unidad de origen. Cuando la tarea de copia detecte el cambio, notificará a los handlers nuevamente. Antes de ejecutar los comandos en este paso, regrese al directorio del proyecto de Ansible.
cd /home/labex/project/rhce-ansible
El módulo lineinfile también puede editar archivos locales mediante un comando ad hoc. Aquí, cambia solo una línea en la unidad de origen.
ansible localhost -c local -m ansible.builtin.lineinfile -a 'path=files/rhce-handler-demo.service regexp=^RestartSec= line=RestartSec=3'
Esto cambia el archivo de origen, no la unidad instalada en /etc/systemd/system. La siguiente ejecución del playbook debería detectar el cambio en el origen, copiar la unidad actualizada y notificar a los handlers nuevamente.
ansible-playbook playbooks/manage-service.yml | tee reports/service-second-run.txt
grep -F RestartSec /etc/systemd/system/rhce-handler-demo.service
La unidad instalada ahora debería mostrar RestartSec=3. El servicio debería permanecer activo y habilitado porque los handlers recargaron systemd y reiniciaron el servicio de demostración después de que el archivo cambió.
Resumen
Ha implementado una unidad de systemd segura, utilizado handlers para la recarga de systemd y el reinicio de servicios, verificado el estado activo y habilitado del servicio, y activado el handler mediante un cambio controlado en el archivo de unidad.
