Playbook de Ansible para Configuración de Servidores

Descripción General

Ansible es automatización sin agentes — ningún demonio en el destino, solo SSH y un playbook YAML. Esa única propiedad es por la que ganó la guerra de la gestión de configuración: aprovisiona una máquina una vez (con Terraform o a mano), y deja que un playbook describa cómo debería quedar, idempotente y versionado.

Antes de Ansible, los sysadmins entraban a cada servidor para instalar paquetes y reiniciar servicios — lento, irrepetible, inauditable. Un playbook sustituye eso con una descripción declarativa que configura cientos de hosts en minutos y vive en git junto a la app que despliega — que es también cómo se complementa con el pipeline de CI/CD que lo ejecuta y las imágenes Docker que empaqueta.

Cuándo Usar

Usa Ansible cuando el mismo cambio tiene que ocurrir en más de una máquina. Aprovisionar una base (paquetes, usuarios, claves SSH) en toda una flota, empujar una actualización de app a todos los servidores web a la vez, mantener configs idénticas de Nginx/Postgres/Redis en cada nodo, o ejecutar un comando puntual en todas partes — reiniciar tras un parche de seguridad, por ejemplo. Y cuando el playbook necesita una contraseña, Ansible Vault la cifra en vez de commitearla en claro.

Si solo tienes un servidor y no prevés crecer, un script de shell es sinceramente más simple. El playbook empieza a compensar en el momento en que existe un segundo host.

Sáltalo cuando el trabajo no es configuración en absoluto: construir imágenes golden es cosa de Packer, las imágenes de contenedor inmutables son cosa de tu Dockerfile, y los comandos puntuales (ansible webservers -m ping) no necesitan archivo de playbook. Ansible también sufre donde el destino no acepta SSH — para eso está la API del proveedor cloud o una herramienta con agente.

Solución

Una configuración mínima que funciona son tres archivos: un inventario, el playbook y un archivo de configuración. Este instala Nginx, despliega una config y recarga el servicio solo cuando el archivo cambia de verdad:

# inventory.ini — los hosts que gestiona el playbook
[webservers]
web1.example.com
web2.example.com ansible_user=deployer

[webservers:vars]
ansible_port=22

# site.yml — el playbook en sí
- name: Configure web servers
  hosts: webservers
  become: yes

  vars:
    nginx_worker_processes: 4

  tasks:
    - name: Install Nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: yes

    - name: Deploy nginx.conf
      ansible.builtin.template:
        src: templates/nginx.conf.j2
        dest: /etc/nginx/nginx.conf
        owner: root
        group: root
        mode: "0644"
      notify: Reload nginx

    - name: Ensure Nginx is running and enabled
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: yes

  handlers:
    - name: Reload nginx
      ansible.builtin.service:
        name: nginx
        state: reloaded

# ansible.cfg — configuración a nivel de proyecto
[defaults]
inventory = inventory.ini
retry_files_enabled = False
host_key_checking = False

Ejecútalo:

# Dry run — muestra qué cambiaría, sin cambiar nada
ansible-playbook site.yml --check --diff

# Ejecución real
ansible-playbook site.yml

# Solo contra un host
ansible-playbook site.yml --limit web1.example.com

Explicación

El play apunta al grupo webservers del inventario, y cada tarea invoca un módulo con un estado final declarado — state: present dice “asegura que esto esté instalado”, no “ejecuta apt-get”. Eso es lo que hace que la segunda ejecución sea un no-op: Ansible comprueba si el sistema ya coincide antes de hacer nada. La tarea de template registra un notify al handler Reload nginx, que dispara una vez al final del play y solo si el archivo renderizado difirió — sin recargas inútiles en cada ejecución.

become: yes a nivel de play eleva a root en toda la ejecución; ajústalo a become por tarea cuando un playbook mezcle trabajo privilegiado y no privilegiado (la sección de Errores Comunes muestra cómo). Y el par --check --diff es el hábito que más importa: --check simula, --diff muestra los cambios reales de archivo, y juntos son la diferencia entre un despliegue confiado y una plegaria.

Dos piezas del modelo de Ansible conviene interiorizar antes de escalar más allá de un playbook. Los facts son los datos por host que Ansible recolecta al inicio de cada play (familia de OS, IPs, memoria) — ansible_os_family == "Debian" en un when: es un fact haciendo trabajo real. La precedencia de variables decide cuál de los ocho lugares donde puedes definir nginx_worker_processes gana de verdad: las vars del playbook ganan a las del inventario, group_vars gana a los defaults del host, y extra_vars (-e) gana a todo. Cuando un playbook “ignora” tu variable, no la está ignorando — algo con mayor precedencia la está sobrescribiendo.

Cuando un playbook crece más allá de una pantalla de tareas, sepáralo en roles: un directorio roles/nginx/ con tasks/, handlers/, templates/ y defaults/ que un play consume como roles: [nginx]. Es la unidad que comparte Ansible Galaxy, y también cómo un monorepo evita que diez playbooks redeclaren la misma configuración de servidor web. Empieza plano, refactoriza a rol la segunda vez que copies un bloque de tareas — ese orden es deliberado, porque la estructura de roles prematura es su propio tipo de desorden.

Errores Comunes

Los errores se repiten en todas partes. Ejecutar un playbook sin --check primero — el modo check muestra qué cambiaría antes de que nada lo haga, y en producción eso no es opcional. Usar shell cuando existe un módulo: los módulos son idempotentes y manejan los casos borde que tu one-liner no maneja. Olvidar become: yes y perseguir un error de permisos críptico durante una hora. Hardcodear IPs en el inventario — se pudren; usa DNS o un inventario dinámico que se mantenga actualizado. Y reiniciar Nginx en cada tarea en vez de notificar a un handler — los handlers disparan una vez, al final, cuando algo cambió de verdad.

1. Saltarse el caché de facts. Recolectar facts es lento a escala de flota:

# ansible.cfg
[defaults]
gathering = smart
fact_caching = jsonfile
fact_caching_connection = ./.facts
fact_caching_timeout = 86400

2. Ejecutar todo como root. Usa become selectivo por tarea:

# Mal: todo corre como root
- hosts: all
  become: yes
  tasks:
    - name: Clone repo as root
      ansible.builtin.git:
        repo: https://github.com/myorg/myapp.git
        dest: /home/deployer/myapp

# Bien: become solo donde hace falta
- hosts: all
  tasks:
    - name: Install packages
      ansible.builtin.apt:
        name: nginx
        state: present
      become: yes

    - name: Clone repo as deployer
      ansible.builtin.git:
        repo: https://github.com/myorg/myapp.git
        dest: /home/deployer/myapp
      become: yes
      become_user: deployer

3. No usar --diff para auditar. Ve exactamente qué cambia en cada ejecución:

ansible-playbook site.yml --diff

Lo que Funciona

Los playbooks deberían ser aburridos — ese es el punto. Haz cada tarea idempotente: la segunda ejecución no debería cambiar nada, lo que significa state: present por encima de comandos shell que reinstalan a ciegas. Extrae las tareas compartidas a roles — eso es lo que las hace compartibles vía Galaxy o un repo interno en vez de copiar-pegar. Todo vive en git — playbooks, inventarios, variables — así los cambios se revisan y se revierten. Ejecuta ansible-lint antes de publicar; atrapa los errores que cuestan una ventana de despliegue. Y cifra los secretos con Ansible Vault; una contraseña en claro commiteada es un incidente esperando ocurrir.

Tips de Rendimiento

1. Ejecuta strategy: free para más velocidad. Los hosts dejan de esperarse entre sí:

- name: Fast parallel deployment
  hosts: webservers
  strategy: free
  tasks:
    - name: Deploy app
      ansible.builtin.git:
        repo: https://github.com/myorg/myapp.git
        dest: /var/www/myapp

2. Desactiva la recolección de facts cuando no se use. Ahorra 2-5 segundos por host:

- name: Simple task without facts
  hosts: webservers
  gather_facts: no
  tasks:
    - name: Restart service
      ansible.builtin.service:
        name: nginx
        state: restarted

3. Usa async para tareas largas. No bloquees el playbook:

- name: Run slow backup
  ansible.builtin.shell: pg_dump mydb > /tmp/backup.sql
  async: 300
  poll: 5

Archivos complementarios: el repo companion de ansible-playbook tiene los tres archivos de arriba — inventory.ini, site.yml, ansible.cfg — listos para ejecutar.

Lectura Adicional

• Ansible Documentation — Playbooks — la guía oficial
• Red Hat — Ansible Best Practices — consejos de la fuente