Primeros pasos con Ansible: Guía esencial para sysadmins Linux

Por qué Ansible sigue siendo el estándar en 2026

Ansible lleva una década dominando la gestión de configuración en entornos Linux, y en 2026 sigue siendo la opción por defecto para sysadmins que manejan entre 1 y 500 servidores. Su modelo declarativo basado en YAML, sin agentes en los nodos gestionados y con un catálogo enorme de módulos para todo el ecosistema Linux, lo convierte en la herramienta más pragmática para homelabs y para producción mediana. Frente a alternativas más nuevas como Salt, Puppet o incluso Pulumi, Ansible gana en legibilidad: un playbook nuevo lo lee alguien que nunca tocó DevOps y entiende qué va a pasar.

Esta guía cubre los primeros pasos: desde la instalación hasta escribir el primer playbook idempotente que configura paquetes, servicios y usuarios en un parque de servidores Debian o Ubuntu. Está orientada a sysadmins que ya manejan la línea de comando y quieren saltar a la automatización sin pelearse con conceptos innecesarios.

Instalación en Debian, Ubuntu y Fedora

La instalación varía según la distribución. En Debian y Ubuntu el paquete ansible-core está en los repos oficiales desde 22.04 y bookworm. En Fedora también, aunque hay matices con la versión de Python del sistema. Evita instalar con pip install ansible en el Python del sistema: rompe dependencias de paquetes del sistema operativo y termina siendo un dolor de cabeza cuando actualices Python.

# Debian 12 (bookworm) y Ubuntu 22.04+
sudo apt update
sudo apt install -y ansible-core
# Fedora 41+
sudo dnf install -y ansible-core
# Verificar versión
ansible --version
# ansible [core 2.17.x]
#   config file = /etc/ansible/ansible.cfg
#   python version = 3.12.x

Si necesitas módulos de la colección community (por ejemplo community.general para cosas no cubiertas por core), instala Ansible completo en lugar de ansible-core. Para homelab y servidores pequeños, ansible-core alcanza.

El inventario: cómo Ansible encuentra tus servidores

El inventario es el archivo donde le dices a Ansible qué servidores existen y cómo conectarse a ellos. La forma más simple es un archivo INI plano en /etc/ansible/hosts o en tu directorio de trabajo como inventory.ini. Cada línea es un host, y los corchetes agrupan hosts en grupos.

# /home/sysadmin/ansible/inventory.ini
[webservers]
web1.example.com ansible_user=deploy
web2.example.com ansible_user=deploy
[dbservers]
db1.example.com ansible_user=deploy
[production:children]
webservers
dbservers
[all:vars]
ansible_python_interpreter=/usr/bin/python3

El grupo production:children es un meta-grupo que agrupa todos los hijos. Esto sirve para correr un playbook contra todo el entorno de producción sin tener que listar cada grupo. Para sysadmins que empiezan, este archivo en texto plano es la opción correcta. YAML, JSON, inventarios dinámicos contra AWS o DigitalOcean vienen después, cuando la infraestructura crece.

Conectividad por SSH: llaves y become

Ansible se conecta por SSH a los nodos gestionados. La forma idiomática es subir tu llave pública SSH a cada servidor en ~/.ssh/authorized_keys. Una vez hecho, Ansible no te pide contraseña nunca más, lo cual es exactamente lo que quieres: la automatización no debe depender de contraseñas escritas a mano.

# Generar llave dedicada para Ansible (opcional pero recomendado)
ssh-keygen -t ed25519 -f ~/.ssh/ansible_id -C "ansible@$(hostname)"
# Copiar a cada servidor
ssh-copy-id -i ~/.ssh/ansible_id.pub [email protected]
# Test de conexión
ansible all -i inventory.ini -m ping
# web1.example.com | SUCCESS => {
#     "changed": false,
#     "ping": "pong"
# }

El módulo ping no usa ICMP: verifica que Ansible puede ejecutar Python en el servidor. Si devuelve SUCCESS, la conexión SSH, la autenticación por llave y la presencia de Python en el servidor remoto están todas funcionando. Si falla, el error suele estar en el SSH (puerta cerrada, usuario equivocado) o en Python faltante en el servidor remoto (raro en Debian/Ubuntu modernos).

Tu primer playbook: instalar nginx y reiniciar el servicio

El playbook es donde vive la lógica de configuración. Cada playbook es un archivo YAML con una lista de plays, y cada play mapea un grupo de hosts a un conjunto de tareas. La idempotencia (poder correr el playbook muchas veces sin efectos colaterales) está en el corazón del diseño.

---
# /home/sysadmin/ansible/playbooks/nginx.yml
- name: Configurar nginx en servidores web
  hosts: webservers
  become: true
  tasks:
    - name: Instalar nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: yes
        cache_valid_time: 3600
    - name: Iniciar y habilitar el servicio nginx
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: yes
    - name: Copiar configuración personalizada
      ansible.builtin.copy:
        src: files/nginx.conf
        dest: /etc/nginx/nginx.conf
        owner: root
        group: root
        mode: '0644'
      notify: Reiniciar nginx
  handlers:
    - name: Reiniciar nginx
      ansible.builtin.service:
        name: nginx
        state: restarted

El patrón clave es notify + handlers: la tarea de copiar la configuración no reinicia nginx directamente, solo lo notifica. Los handlers corren al final del play, y solo si alguna tarea los notificó. Esto evita reiniciar nginx 5 veces si tocás 4 archivos de configuración en el mismo play. Corré el playbook con ansible-playbook -i inventory.ini nginx.yml.

Variables y templates Jinja2

Las variables permiten que el mismo playbook funcione en servidores con configuraciones distintas (distinto puerto SSH, distinto hostname, distintas credenciales de base de datos). Ansible combina variables del inventario, group_vars, host_vars y variables pasadas por CLI, y las hace disponibles en los templates Jinja2.

# group_vars/webservers.yml
nginx_listen_port: 80
nginx_worker_processes: 4
# templates/nginx.conf.j2
worker_processes {{ nginx_worker_processes }};
events {
    worker_connections 1024;
}
http {
    server {
        listen {{ nginx_listen_port }};
        server_name {{ ansible_fqdn }};
    }
}

# Playbook que usa el template
- name: Plantilla nginx
  ansible.builtin.template:
    src: nginx.conf.j2
    dest: /etc/nginx/nginx.conf
    mode: '0644'
  notify: Reiniciar nginx

ansible_fqdn es una fact automática que Ansible recolecta de cada host. Las facts son variables mágicas que Ansible descubre antes de ejecutar el play (hostname, IPs, memoria, distro, kernel, etc.) y son accesibles como cualquier otra variable. Para listar todas las facts de un host: ansible hostname -m setup.

Roles: organizar playbooks cuando crecen

Cuando tienes más de 5-10 playbooks o repetís las mismas tareas en varios playbooks, es hora de mover a roles. Un rol es un directorio con estructura estándar que agrupa variables, tareas, templates, handlers y archivos. Ansible los busca automáticamente en roles/ relativo al playbook.

roles/
  nginx/
    tasks/main.yml
    handlers/main.yml
    templates/nginx.conf.j2
    vars/main.yml
    defaults/main.yml
    meta/main.yml

Para usar el rol en un playbook: roles: - nginx. Ansible carga defaults/main.yml con valores por defecto que el usuario puede sobreescribir, y vars/main.yml con valores internos del rol. Para sysadmins que manejan 3-10 servidores, los roles empiezan a valer la pena cuando comparten la misma configuración entre varios proyectos. Antes de eso, un playbook monolítico es más legible.

Vault: cifrar secretos en el repositorio

Ansible Vault cifra archivos YAML completos (variables, playbooks) con AES-256. La contraseña del vault se pasa al correr el playbook. Para un homelab esto puede parecer overkill, pero en el momento en que metés el playbook en git, quieres cifrar todo lo que sea secreto (llaves SSH privadas, contraseñas de base de datos, tokens de API).

# Crear archivo cifrado
ansible-vault create secrets.yml
# Te pide contraseña y abre editor
# Editar archivo cifrado
ansible-vault edit secrets.yml
# Cifrar archivo existente
ansible-vault encrypt db_password.yml
# Correr playbook con vault
ansible-playbook site.yml --ask-vault-pass
# O con archivo de contraseña:
ansible-playbook site.yml --vault-password-file ~/.vault_pass

El archivo de contraseña ~/.vault_pass debe tener permisos 0600 y NO debe estar en git. La forma más limpia de manejar varios vaults es tener un password file por entorno: ~/.vault_pass_prod, ~/.vault_pass_staging. El password file se puede montar desde un gestor de secretos corporativo (HashiCorp Vault, AWS Secrets Manager) cuando la infraestructura crece.

Ansible AWX: la interfaz web cuando hay equipo

AWX es la versión open source de Ansible Tower (el producto comercial de Red Hat). Provee interfaz web, scheduling de jobs, control de acceso, auditoría y API REST para correr playbooks desde CI/CD. Para un sysadmin solo no aporta mucho, pero en el momento en que hay un equipo de 3+ personas tocando la misma infraestructura, AWX evita el clásico problema de "quién corrió qué contra qué servidor y cuándo".

AWX corre en contenedor Docker o Kubernetes, consume bastante RAM (mínimo 8GB recomendados para entornos no triviales), y su API REST permite integrarlo con GitLab CI, GitHub Actions o Jenkins para hacer deployments automatizados con approval gates. Para el caso típico de un sysadmin Linux, el flujo es: AWX en un servidor interno, playbooks en git, CI dispara AWX, AWX ejecuta contra staging, humano aprueba, AWX ejecuta contra producción.

Troubleshooting común

Los errores más frecuentes al empezar con Ansible son:

• "Permission denied" al tocar archivos del sistema: te falta become: true en el play. Sin eso, Ansible corre como el usuario SSH (típicamente deploy), que no puede tocar /etc/.
• "sudo: a password is required": el usuario remoto puede hacer sudo pero necesita contraseña. configura NOPASSWD en /etc/sudoers.d/ansible para el usuario de Ansible, o usa ansible_become_password en el inventario.
• "SSH Error: data could not be sent to remote host": el inventario apunta a un host que no responde o al que no llegas por SSH. prueba ssh usuario@host manual antes de correr el playbook.
• El handler no se ejecuta: cambiaste el archivo pero no lo notificaste. El handler corre solo si la tarea reporta changed. Cambia copy por algo que siempre reporte changed, o forzá el handler con ansible-playbook site.yml --force-handlers.

Cuándo NO usar Ansible

Ansible no es bala de plata. Para infraestructura efímera en la nube (contenedores, funciones Lambda, deployments inmutables), Terraform + imágenes preconstruidas rinden mejor. Ansible brilla en servidores longevos donde la configuración acumula estado. Si tu entorno es 100% Kubernetes, los Helm charts + ArgoCD cubren mejor el caso. Si estás migrando un servidor Windows con estado complejo, Ansible también funciona pero vas a extrañar las herramientas nativas de PowerShell DSC. La decisión pragmática es: si tu parque son VMs o bare-metal Linux con configuración mutable, Ansible. Si tu parque es 100% cloud efímero, mira Terraform primero.

Resumen

Ansible sigue siendo la herramienta más legible y práctica para automatizar configuraciones Linux en 2026. Empieza con un playbook monolítico para nginx, sumá variables cuando tengas 3+ servidores, pasa a roles cuando tengas 5+ playbooks, y meté AWX cuando haya equipo. El salto de productividad llega en la tercera semana, cuando dejás de tocar servidores a mano y empezás a delegar todo a playbooks versionados en git.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux