Uso de un playbook de Ansible para administrar actualizaciones de estaciones de trabajo y servidores

He decidido simplificar mi proceso de actualización para los sistemas cliente que admito, así como para mis propios dispositivos Linux. Si bien una serie de secuencias de comandos complejas me han servido bien durante mucho tiempo, los beneficios de usar Ansible para esta tarea son demasiados para ignorarlos.

Dentro parte uno En esta serie de artículos, analicé el proceso de actualización real, establecí la estructura de mi libro de jugadas y proporcioné palabras clave y comentarios. El libro de jugadas consta de tres partes. Cada juego gestiona una categoría de sistemas. El juego 1 administra mi dispositivo controlador Ansible (mi estación de trabajo principal), mientras que los juegos 2 y 3 administran los servidores y todas las estaciones de trabajo restantes.

Comencemos este segundo artículo mirando la segunda pieza.

Índice

la segunda habitacion

Aquí está la segunda pieza completa. El objetivo de este juego es realizar actualizaciones en el firewall y el servidor.

El cortafuegos debe estar operativo mientras los servidores (y todos los demás hosts) se actualizan para que puedan acceder a Internet para descargar los paquetes de actualización. El servidor debe estar ejecutándose mientras el cortafuegos y otros hosts se actualizan para proporcionar DHCP y servicios de nombres. Para hacer esto, esta sala actualiza estos dos hosts uno a la vez.

Los nombres de estos dos hosts están contenidos en el [all_servers] grupo en el /etc/ansible/hosts archivo de inventario.

#######################################################################
#######################################################################
# Play 2 - Do servers 
#######################################################################
#######################################################################
- name: Play 2 - Install updates for servers yorktown and wally
  hosts: all_servers
  serial: 1
  remote_user: root
  vars:
    run: false
    reboot: false

  tasks:
#######################################################################
# Do some preliminary checking
#######################################################################
    - name: Install the latest version of the doUpdates script
      copy:
        src: /root/ansible/Updates/files/doUpdates
        dest: /usr/local/bin
        mode: 0774
        owner: root
        group: root

    - name: Check for currently available updates
      command: doUpdates -c
      register: check
    - debug: var=check.stdout_lines

#######################################################################
# Do the updates.
#######################################################################
# Install all available updates
    - name: Install all current updates
      dnf:
        name: "*"
        state: latest
      when: (check.stdout | regex_search('updates ARE available')) and run == "true"

    - name: Update the man Base de datos
      command: mandb
      when: run

    - name: Reboot if necessary and reboot extra variable is true
      reboot:
      when: (check.stdout | regex_search('reboot will be required')) and reboot == "true" and run == "true"

Todo sobre este segundo conjunto es casi igual que el primero, excepto por dos líneas.

en serie: esta instrucción adicional le dice a Ansible que realice esta lectura en un host a la vez, es decir, en serie en lugar de en paralelo. Si la todos_servidores grupo en el inventario tenía diez servidores, podría usar un límite más alto, por ejemplo dos, para que este juego se ejecutara contra dos servidores a la vez. En este caso, necesito wally, el cortafuegos, debe estar operativo para el yorktown El servidor tiene acceso a Internet para descargar paquetes actualizados. La secuencia de actualización de estos dos hosts no importa hasta que se ejecutan simultáneamente.

Para reiniciar: Ansible tiene una capacidad de reinicio incorporada, por lo que podemos usarla en este juego en lugar del comando de apagado de Linux. La característica esencial de la función de reinicio de Ansible es que verifica que el reinicio fue exitoso, que el host remoto está operativo y que la comunicación SSH está funcionando nuevamente. El tiempo de espera predeterminado para esto es de 10 minutos, luego de lo cual Ansible devuelve un error.

la tercera sala

Y aquí está la tercera pieza. Este juego actualiza todos los hosts restantes en mi red. Los nombres de estos hosts se encuentran en el [workstations] grupo de los /etc/ansible/hosts archivo de inventario.

#######################################################################
#######################################################################
# Play 3 - Do all workstations except david
#######################################################################
#######################################################################
- name: Play 3 - Install updates for all workstations except david
  hosts: workstations
  strategy: free
  remote_user: root
  vars:
    run: false
    reboot: false

  tasks:
#######################################################################
# Do some preliminary checking
#######################################################################
    - name: Install the latest version of the doUpdates script
      copy:
        src: /root/ansible/Updates/files/doUpdates
        dest: /usr/local/bin
        mode: 0774
        owner: root
        group: root

    - name: Check for currently available updates
      command: doUpdates -c
      register: check
    - debug: var=check.stdout_lines

#######################################################################
# Do the updates.
#######################################################################
# Install all available updates
    - name: Install all current updates
      dnf:
        name: "*"
        state: latest
      when: (check.stdout | regex_search('updates ARE available')) and run == "true"

    - name: Reboot if necessary and reboot extra variable is true
      reboot:
      when: (check.stdout | regex_search('reboot will be required')) and reboot == "true" and run == "true"

Solo hay un cambio en este libro de jugadas además de la lista de hosts.

estrategia: El gratis La estrategia le dice a Ansible que realice tareas en este juego libremente. Las tareas en este juego se realizan en cada host tan rápido como el host puede hacerlo. Esto significa que algunos hosts pueden completar la última tarea mucho antes de que otros hosts más lentos hayan completado la primera tarea del manual. Puede parecer una especie de autoservicio cuando lee el flujo de datos STDOUT.

Cada estrategia es un complemento separado, y hay algunos otros complementos que se pueden usar con esa palabra clave. El valor predeterminado es lineal, que realiza cada tarea en todos los hosts antes de pasar a la siguiente tarea. el host_pinned El complemento realiza todas las tareas del juego en cada host antes de pasar al siguiente host. el depurar El complemento realiza las tareas de forma interactiva para que el juego se pueda depurar.

Ejecutar el libro de jugadas

Estoy ejecutando este libro de jugadas usando el comando:

# ansible-playbook -e "run=true reboot=true" doUpdates.yml

el -e opción significa "variables adicionales". Aquí especifica valores para las dos variables definidas en cada parte. En este caso, establezca ambos en real permite actualizar y reiniciar (apagar) si es necesario.

No voy a reproducir el STDOUT flujo de datos aquí porque es bastante largo.

Pensamientos finales

Con algunas modificaciones para reflejar los detalles de su red, este libro de jugadas se puede utilizar para automatizar sus tareas de actualización. Hacer actualizaciones usando un libro de jugadas similar al mío es una buena manera de comenzar con Ansible. Aunque utiliza varias palabras clave que pueden realizar tareas complejas, es un libro de jugadas relativamente sencillo. Empecé con el primer juego para actualizar mi estación de trabajo personal, y el resto fue principalmente copiar y pegar, con algunos ajustes menores para satisfacer las necesidades de los diferentes grupos anfitriones.

Sí, hay otras formas de hacerlo. Probablemente podría haber usado diferentes tareas usando condiciones en uno o dos conjuntos en lugar de tres conjuntos. O podría haber usado condiciones y bloques para manejar hosts específicos de manera diferente. Personalmente, creo que las piezas individuales ayudan a separar la lógica lo suficiente como para que cambiar la forma en que se manejan las tareas en una habitación no afecte a las demás. En mi opinión, esta separación también es más elegante porque la lógica general es más fácil de escribir, comprender y administrar.

Recursos

El documento más completo y útil que he encontrado es el Guía del usuario de Ansible en el sitio web de Ansible. Este documento pretende ser una referencia y no un documento de procedimientos o de introducción.

opensource.com ha publicado numerosos artículos sobre Ansible a lo largo de los años, y la mayoría de ellos me han resultado muy útiles para mis propósitos. El sitio web Red Hat Enable Sysadmin también tiene muchos artículos de Ansible que he encontrado útiles.

También hay algunas páginas man buenas pero concisas disponibles.

Artículos de interés

Subir