Ansible: ejecutar comandos e IaC (5.5)

📋 En esta lección

La herramienta con la que la mayoría de equipos de red dan su primer paso serio en automatización. Aquí entiendes por qué Ansible encajó en redes donde otras no (agentless), su vocabulario completo (inventario, playbook, módulo, tarea, rol), el concepto que lo cambia todo — idempotencia — y escribes los dos playbooks que resuelven el 80% de los casos reales: ejecutar comandos en masa y aplicar configuración declarada.

Por qué Ansible ganó en redes

Las herramientas de gestión de configuración veteranas — Puppet y Chef — nacieron para servidores y se apoyan en un agente: un proceso instalado en cada máquina que consulta periódicamente al servidor central qué estado debe tener (modelo pull). En un servidor Linux es razonable; en un switch Cisco no puedes instalar nada.

Ansible es agentless: no instala nada en el destino. Se conecta por los canales que el equipo ya ofrece — SSH (la CLI de toda la vida, Módulo 3) o APIs como RESTCONF/NETCONF (11.3) — y empuja los cambios desde una máquina de control (modelo push). Esa decisión de diseño es exactamente lo que lo hizo viable en redes: si puedes hacer SSH al equipo, puedes automatizarlo con Ansible.

El examen (5.5) pide usar mecanismos de gestión de configuración como Ansible para ejecutar comandos — con Puppet y Chef como contexto comparativo.

El vocabulario

Cinco piezas y ya puedes leer cualquier repositorio de automatización de red:

• Inventario: el fichero con los equipos y cómo agruparlos.
• Playbook: el fichero YAML con lo que quieres que ocurra.
• Play: un bloque del playbook que apunta a un grupo de equipos.
• Tarea (task): un paso individual dentro de un play.
• Módulo: el código que ejecuta la tarea (cisco.ios.ios_command, cisco.ios.ios_config…). Los módulos de red vienen en colecciones por fabricante y plataforma.
• Rol: un conjunto de tareas, plantillas y variables empaquetado y reutilizable (el siguiente nivel de organización, cuando el repositorio crece).

El inventario

Quién es quién, en YAML:

# inventario.yml
all:
  children:
    switches_acceso:
      hosts:
        sw-acceso-01:
          ansible_host: 10.9.250.11
        sw-acceso-02:
          ansible_host: 10.9.250.12
    routers:
      hosts:
        r-frontera-01:
          ansible_host: 10.9.250.1
  vars:
    ansible_network_os: cisco.ios.ios
    ansible_connection: ansible.netcommon.network_cli
    ansible_user: automation

Los grupos (switches_acceso, routers) son la palanca de la escala: un playbook apunta a un grupo y alcanza a sus 200 miembros igual que a uno. ansible_network_os y ansible_connection le dicen a Ansible que hable IOS por CLI — no SSH genérico de servidor.

⚡ YAML en 30 segundos

Mismo modelo de datos que JSON (11.3), sintaxis por indentación con espacios (nunca tabuladores): clave: valor para pares, - elemento para listas, y la anidación por sangría. Un espacio de más o de menos cambia la estructura — el 90% de los "mi playbook no funciona" del primer día son de indentación.

Playbook 1: ejecutar comandos (el caso del examen)

Recoger la versión de IOS y el estado de las interfaces de toda la flota:

# auditoria.yml
- name: Auditoria de version e interfaces
  hosts: switches_acceso
  gather_facts: false

  tasks:
    - name: Ejecutar comandos show
      cisco.ios.ios_command:
        commands:
          - show version | include Version
          - show ip interface brief
      register: salida

    - name: Mostrar el resultado
      ansible.builtin.debug:
        var: salida.stdout_lines

$ ansible-playbook -i inventario.yml auditoria.yml

ios_command ejecuta comandos EXEC (los show del Módulo 3) y register guarda la salida en una variable para mostrarla, filtrarla o volcarla a un fichero. Con esto, la pregunta "¿qué versión de IOS tiene cada equipo?" pasa de una tarde de SSH a treinta segundos — y el resultado es un dato, no una impresión.

⚠️ ⚠️ ios_command no configura

Es de solo lectura por diseño: rechaza comandos de configuración. Para cambiar el equipo está ios_config. La separación es deliberada — que una auditoría no pueda modificar nada por accidente.

Playbook 2: configuración declarada (IaC)

El salto de la 11.2: no "ejecuta estos comandos" sino "que el equipo quede así".

# baseline.yml
- name: Baseline de seguridad en el acceso
  hosts: switches_acceso
  gather_facts: false

  tasks:
    - name: Servicios y logging corporativos
      cisco.ios.ios_config:
        lines:
          - service password-encryption
          - logging host 10.9.250.40
          - ntp server 10.9.250.20
          - no ip http server

    - name: Banner legal
      cisco.ios.ios_config:
        lines:
          - banner motd ^Acceso restringido. Actividad registrada.^

    - name: Guardar si hubo cambios
      cisco.ios.ios_config:
        save_when: modified

Idempotencia: el concepto que lo cambia todo

Ejecuta ese playbook diez veces seguidas. La primera aplica los cambios; las otras nueve no hacen nada, y lo dicen:

PLAY RECAP
sw-acceso-01  : ok=4  changed=3  unreachable=0  failed=0     ← primera ejecución
sw-acceso-01  : ok=4  changed=0  unreachable=0  failed=0     ← segunda: nada que hacer

Eso es idempotencia: el módulo lee el estado actual, lo compara con el declarado y solo actúa sobre la diferencia. Las consecuencias son enormes:

• Ejecutar es seguro. No hay que preguntarse "¿ya lo apliqué?" — se lanza y punto.
• changed se vuelve información valiosa: un equipo que reporta changed en un playbook que llevas meses ejecutando significa que alguien lo tocó a mano — la detección de deriva de la 11.2, gratis.
• Es lo que hace posible IaC: el playbook deja de ser un procedimiento y pasa a ser la declaración del estado deseado, versionable en Git.

Las redes de seguridad

De la lección 11.2: la automatización amplifica también los errores. Las tres protecciones que se usan siempre:

$ ansible-playbook -i inventario.yml baseline.yml --check --diff    ← simulacro: qué HARÍA
$ ansible-playbook -i inventario.yml baseline.yml --limit sw-acceso-01   ← piloto en uno
$ ansible-playbook -i inventario.yml baseline.yml                   ← despliegue completo

--check (dry-run) simula sin tocar nada y --diff enseña las líneas exactas que cambiarían; --limit restringe el alcance a un equipo o grupo — el piloto antes de la ola. Ese orden — simular, pilotar, desplegar — es el procedimiento profesional, no una precaución opcional.

Y los secretos: las credenciales nunca en el playbook ni en el inventario (el incidente de la 11.3: lo que entra en Git, en Git se queda). Ansible trae Vault para cifrar ficheros de variables:

$ ansible-vault encrypt credenciales.yml
$ ansible-playbook baseline.yml --ask-vault-pass

Qué automatizar primero

El orden por el que empiezan los equipos que tienen éxito — de menor a mayor riesgo:

1. Recoger información (auditorías, inventario de versiones): solo lectura, valor inmediato, cero riesgo.
2. Backups de configuración (la rutina de la 8.6, ahora sin nadie que se acuerde).
3. Verificación post-cambio: ¿quedaron todos los equipos como debían?
4. Baseline y despliegues: NTP, syslog, SNMP, banners, ACLs de gestión.
5. Cambios de servicio (VLANs, interfaces): cuando la confianza y los procedimientos ya están rodados.

Relación con otros conceptos

• YAML es el primo del JSON de la 11.3; los módulos hablan SSH (Módulo 3) o RESTCONF/NETCONF (11.3) por debajo.
• El modo declarativo + Git es la IaC de la 11.2, y la idempotencia es lo que hace detectable la deriva de configuración que allí se describía.
• Lo que despliegas son las configuraciones de los Módulos 5-10: baseline de syslog/NTP (8.4-8.5), ACLs de gestión (10.2), plantillas de puerto (5.10).
• Los backups automatizados son la rutina de la 8.6 industrializada.

Resumen

Ansible se impuso en redes por ser agentless (SSH/APIs, modelo push — frente al agente y el pull de Puppet/Chef) y usar YAML declarativo. Piezas: inventario (equipos agrupados + ansible_network_os/ansible_connection), playbook con plays y tareas, ejecutadas por módulos (cisco.ios.ios_command para show de solo lectura; cisco.ios.ios_config para configurar, con save_when: modified), organizables en roles. La propiedad clave es la idempotencia: se compara estado real contra declarado y solo se actúa sobre la diferencia — ejecutar mil veces es seguro, y un changed inesperado delata que alguien tocó el equipo a mano. Red de seguridad obligatoria: --check --diff (simular), --limit (pilotar), desplegar — y Vault para que las credenciales nunca acaben en Git. Empieza por lo de solo lectura: auditorías y backups.

Fuentes oficiales

• Ansible — documentación oficial
• Ansible — colección cisco.ios (los módulos ios_command e ios_config)
• Cisco DevNet Sandbox — laboratorios gratuitos contra equipos reales