# Automatización de servidores con Ansible

**Categoría:** DevOps y cloud · **Nivel:** Intermedio · **Lectura:** 10 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/devops-cloud/automatizacion-de-servidores-con-ansible/

## Respuesta rápida

**Ansible** es una herramienta de **gestión de configuración**: automatiza dejar uno o muchos servidores en el estado que querés —con ciertos paquetes instalados, ciertos servicios corriendo, ciertos archivos en su lugar—. En vez de entrar por [SSH](../../linux/administracion-de-servidores-linux-desde-cero/index.md) a cada servidor y repetir los comandos a mano, describís el estado deseado una vez y Ansible lo aplica a todos. Tiene tres ideas centrales. **No necesita agentes**: no instala nada en los servidores; se conecta por SSH desde tu máquina, lo que lo hace simple de adoptar. Es **idempotente**: podés correr la misma tarea muchas veces y el resultado es siempre el mismo estado final, sin efectos duplicados —si el paquete ya está, no lo reinstala—. Y se escribe en **playbooks**: archivos YAML legibles que listan las tareas, aplicadas a los servidores definidos en un **inventario**. Los secretos se cifran con **Ansible Vault**, nunca en texto plano. Ansible es complementario a [Terraform](../infrastructure-as-code-con-terraform/index.md): Terraform *crea* los servidores, Ansible *configura* lo que corre dentro.

## Qué es la gestión de configuración

Administrar un servidor implica dejarlo en cierto estado: con determinados paquetes instalados, ciertos servicios activos, archivos de configuración en su lugar, usuarios creados. Con un servidor, hacerlo a mano se aguanta. Con diez, o con cincuenta, aparece el problema: es lento, tedioso y —lo peor— cada servidor termina sutilmente distinto, porque alguien olvidó un paso en uno o lo hizo diferente en otro. A eso se lo llama *deriva de configuración*, y es una fuente enorme de problemas difíciles de diagnosticar.

> **Describir el estado, aplicarlo a todos**
>
> La **gestión de configuración** reemplaza los comandos manuales por una **descripción del estado deseado** que se aplica de forma automática y consistente a todos los servidores. Ansible es la herramienta más popular para esto. El resultado: cincuenta servidores configurados exactamente igual, en minutos, y una descripción versionada de cómo debe ser cada uno.

## Por qué no instala agentes

La primera decisión de diseño que distingue a Ansible es que **no instala nada** en los servidores que gestiona. Muchas herramientas de este tipo requieren un *agente* —un programa corriendo en cada servidor— que hay que instalar y mantener. Ansible no: se conecta a los servidores por **SSH**, el mismo mecanismo estándar con el que un administrador entra normalmente, y ejecuta las tareas de forma remota.

La consecuencia práctica es enorme: para empezar a usar Ansible con un servidor, alcanza con tener **acceso SSH** a él. No hay que preparar nada del otro lado. Todo vive en el **nodo de control** —tu máquina o un servidor de automatización—, que es el único lugar donde Ansible está instalado.

## La idempotencia

El concepto más importante de Ansible, y el que más lo diferencia de un simple [script](../../programacion/automatizacion-de-tareas-con-python/index.md), es la **idempotencia**: podés ejecutar el mismo playbook una vez o cien veces, y el resultado es siempre el mismo **estado final**, sin efectos acumulados.

> **Atención**
>
> Una tarea de Ansible no dice «instalá este paquete» sino «asegurate de que este paquete esté instalado». La diferencia es clave: antes de actuar, Ansible **comprueba el estado actual**. Si el paquete ya está, no hace nada; si falta, lo instala. Si un archivo ya tiene el contenido correcto, no lo toca. Por eso correr el playbook de más no rompe nada: converge al estado deseado y se queda ahí, informando en cada tarea si hubo cambio o no. Esto contrasta con un script imperativo, que ejecutaría los comandos otra vez con posibles efectos duplicados.

La idempotencia es lo que hace seguro correr Ansible una y otra vez para *garantizar* el estado, no solo para establecerlo una vez. Si un servidor se desvió, volver a correr el playbook lo devuelve al estado descrito.

## Playbook e inventario

Las tareas se describen en un **playbook**: un archivo YAML legible que lista, en orden, qué debe pasar. Y los servidores sobre los que se aplican se definen en un **inventario**, donde se los lista y agrupa.

```yaml
# Playbook: dejar los servidores web en el estado deseado
- hosts: web
  become: true
  tasks:
    - name: Asegurar que Nginx esté instalado
      ansible.builtin.package:
        name: nginx
        state: present
    - name: Asegurar que Nginx esté corriendo
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true
```

Ese playbook, aplicado al grupo `web` del inventario, deja todos esos servidores con Nginx instalado y corriendo, sin importar cuántos sean ni cuántas veces se ejecute. Para los **secretos** —contraseñas, claves—, Ansible provee **Ansible Vault**, que los cifra para poder guardarlos junto al código y descifrarlos solo al ejecutar. Nunca van en texto plano en el playbook ni en el inventario, siguiendo la [regla general de los secretos](../como-administrar-secretos-en-pipelines-y-aplicaciones/index.md).

## Errores frecuentes

- **Escribir tareas no idempotentes.** Un comando crudo que se ejecuta siempre pierde la gran ventaja de Ansible.
- **Secretos en texto plano.** Van cifrados con Ansible Vault, no escritos en el playbook o el inventario.
- **Usar Ansible como un lanzador de comandos sueltos.** Su valor está en describir el estado deseado, no en ejecutar órdenes puntuales.
- **No versionar los playbooks.** Son código; van en control de versiones y se revisan.
- **Confundirlo con Terraform.** Ansible configura servidores existentes; crear la infraestructura es tarea de Terraform.
- **Probar directo en producción.** Conviene un entorno de prueba y correr en modo de verificación primero.
- **Inventarios desordenados.** Agrupar bien los servidores evita aplicar la tarea equivocada a la máquina equivocada.

## Preguntas frecuentes

**¿Qué es Ansible y para qué sirve?**
Ansible es una herramienta de gestión de configuración que automatiza la tarea de dejar uno o muchos servidores en un estado deseado: con ciertos paquetes instalados, ciertos servicios corriendo, ciertos archivos de configuración en su lugar y ciertos usuarios creados. Sirve para resolver el problema que aparece cuando hay que administrar más de un servidor, donde hacerlo a mano se vuelve lento, tedioso y propenso a que cada máquina termine sutilmente distinta de las demás, algo conocido como deriva de configuración y que causa problemas difíciles de diagnosticar. En lugar de entrar por SSH a cada servidor y repetir los comandos manualmente, con Ansible se describe una sola vez el estado deseado y la herramienta lo aplica de forma consistente a todos los servidores indicados, dejándolos configurados exactamente igual en minutos. Además, esa descripción queda versionada, sirviendo como documentación siempre actualizada de cómo debe ser cada servidor.

**¿Por qué se dice que Ansible no necesita agentes?**
Porque, a diferencia de muchas herramientas de gestión de configuración que requieren instalar y mantener un programa especial —un agente— corriendo en cada servidor gestionado, Ansible no instala absolutamente nada en las máquinas que administra. En su lugar, se conecta a ellas usando SSH, que es el mecanismo estándar y seguro con el que un administrador entra normalmente a un servidor, y ejecuta las tareas de forma remota desde el nodo de control, que es la única máquina donde Ansible está instalado. La consecuencia práctica de este diseño sin agente es muy importante: para empezar a gestionar un servidor con Ansible alcanza con tener acceso SSH a él, sin necesidad de preparar, instalar ni mantener nada del otro lado. Esto reduce mucho la barrera de entrada y la complejidad operativa, y es una de las razones por las que Ansible se volvió tan popular frente a alternativas que sí dependen de agentes.

**¿Qué significa que Ansible es idempotente?**
La idempotencia es la propiedad por la cual ejecutar el mismo playbook una vez o muchas veces lleva siempre exactamente al mismo estado final, sin efectos acumulados ni duplicados. Esto es posible porque las tareas de Ansible no están redactadas como órdenes imperativas del tipo «instalá este paquete», sino como declaraciones del estado deseado del tipo «asegurate de que este paquete esté instalado». Antes de actuar, cada tarea comprueba el estado actual del sistema: si el paquete ya está instalado, no hace nada; si falta, lo instala; si un archivo ya tiene el contenido correcto, no lo toca. Gracias a esto, correr un playbook de más nunca rompe nada, sino que simplemente confirma que todo sigue en el estado deseado, informando en cada tarea si hubo un cambio o no. Esta propiedad es lo que hace seguro usar Ansible no solo para establecer una configuración una vez, sino para garantizarla de forma continua: si un servidor se desvió, volver a correr el playbook lo devuelve al estado descrito.

**¿Qué son los playbooks y el inventario?**
Son las dos piezas con las que se trabaja en Ansible. Un playbook es un archivo de texto en formato YAML, pensado para ser legible, en el que se describen en orden las tareas que Ansible debe aplicar: por ejemplo asegurar que cierto paquete esté instalado, copiar un archivo de configuración o garantizar que un servicio esté corriendo y habilitado para arrancar con el sistema. El inventario es el archivo donde se listan y agrupan los servidores que se van a gestionar, por ejemplo definiendo un grupo llamado web con varios servidores y otro grupo llamado base de datos con otros. Al ejecutar un playbook, se le indica sobre qué grupo del inventario debe aplicarse, y Ansible ejecuta esas tareas en todos los servidores de ese grupo a la vez. Ambos, playbooks e inventario, son texto y deben guardarse en un control de versiones, lo que los convierte en una descripción versionada, revisable y reproducible de cómo debe configurarse cada tipo de servidor.

**¿Cómo se guardan los secretos en Ansible?**
Con Ansible Vault, una funcionalidad incorporada que permite cifrar valores sensibles como contraseñas, claves y tokens, de modo que puedan guardarse cifrados junto al resto del código y descifrarse únicamente en el momento de ejecutar el playbook, mediante una clave que no se versiona. Lo que nunca hay que hacer es escribir secretos en texto plano dentro de los playbooks o del inventario, porque esos archivos se guardan en un control de versiones y se comparten con el equipo, de manera que cualquier credencial escrita sin cifrar quedaría expuesta a quien tenga acceso al repositorio. Con Ansible Vault, en cambio, el contenido sensible viaja cifrado y solo se revela en tiempo de ejecución. Es la aplicación concreta, dentro de Ansible, de la regla universal que rige para el código fuente, los contenedores, los pipelines y la infraestructura como código: los secretos viven protegidos por un mecanismo pensado para ello y jamás se incrustan en texto plano en lo que se versiona o distribuye.

**¿En qué se diferencian Ansible y Terraform?**
Resuelven problemas distintos y complementarios, y muchas veces se usan juntos. Terraform se ocupa de aprovisionar la infraestructura, es decir de crear y gestionar los recursos: levantar los servidores, definir las redes, crear las bases de datos. Ansible se ocupa de la gestión de configuración, es decir de preparar lo que corre dentro de esos servidores una vez que ya existen: instalar paquetes, configurar servicios, desplegar aplicaciones y mantener el sistema en el estado deseado. Una forma clara de recordarlo es que Terraform construye la casa y Ansible la amuebla y la deja lista para vivir. En un flujo de trabajo típico, Terraform crea primero la infraestructura y después Ansible configura las máquinas resultantes. Aunque existe cierto solapamiento y cada herramienta puede invadir un poco el terreno de la otra, la práctica más limpia y mantenible es usar cada una para aquello en lo que es mejor, en lugar de forzar una sola a cubrir ambos roles.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Sección GNU/Linux](https://underc0de.org/foro/gnu-linux/). Administración de servidores, SSH y automatización.
2. **Underc0de, foro.** [Sección Scripting](https://underc0de.org/foro/scripting/). Automatización de tareas de sistema.

### Documentación oficial

1. **Red Hat / Ansible.** [Documentación oficial de Ansible](https://docs.ansible.com/). La referencia del proyecto.
2. **Ansible.** [Working with playbooks](https://docs.ansible.com/ansible/latest/playbook_guide/index.html). Cómo se describen las tareas.
3. **Ansible.** [Ansible Vault](https://docs.ansible.com/ansible/latest/vault_guide/index.html). Cómo cifrar y gestionar secretos.
4. **Ansible.** [Building an inventory](https://docs.ansible.com/ansible/latest/inventory_guide/index.html). Cómo se listan y agrupan los servidores.

## Guías relacionadas

- [IaC con Terraform](../infrastructure-as-code-con-terraform/index.md)
- [Administración de servidores](../../linux/administracion-de-servidores-linux-desde-cero/index.md)
- [Administrar secretos](../como-administrar-secretos-en-pipelines-y-aplicaciones/index.md)
- [Backups y recuperación](../recuperacion-ante-desastres-y-backups-en-devops/index.md)
- [Índice de DevOps y cloud](../index.md)