Saltar al contenido principal

Introducción a Ansible: fundamentos e instalación

Este es el capítulo 1. Ver el índice completo del curso de Ansible.

Bienvenido al curso de Ansible. Este primer capítulo cubre el bloque de fundamentos: qué es Ansible, cómo está construido por dentro y cómo dejarlo listo para empezar a automatizar.

📋 Contenido del capítulo​

  1. Introducción: ¿Qué es Ansible? — Definición, casos de uso y por qué se ha vuelto omnipresente en DevOps.
  2. Fundamentos y arquitectura — Push vs pull, control node y managed nodes, idempotencia, IaC.
  3. Instalación y configuración — Requisitos, instalación paso a paso, primer ping, ansible.cfg.
Vídeo asociado

Cada capítulo del curso se corresponde con un único vídeo del canal de YouTube. Si preferimos aprender en formato vídeo, aquí tenemos el de este capítulo:

¿Qué es Ansible y cómo funciona? (Instalación y Laboratorio) - Curso Ansible #1

Introducción: ¿Qué es Ansible? 🚀​

Bienvenido al curso de Ansible. En esta introducción descubrimos qué es Ansible, por qué es una de las herramientas de automatización más populares del mundo DevOps, y cómo puede transformar la forma en que gestionamos nuestra infraestructura.

🎯 ¿Qué es Ansible?​

Definición​

Ansible es una plataforma de automatización IT open-source que permite:

  • Gestión de configuraciones: Mantener servidores en un estado deseado
  • Despliegue de aplicaciones: Automatizar el deployment de software
  • Orquestación: Coordinar tareas complejas entre múltiples sistemas
  • Aprovisionamiento: Configurar infraestructura desde cero

La filosofía: simplicidad y potencia​

Complejidad tradicional → Ansible → Simplicidad radical
      ↓                      ↓              ↓
  Scripts caóticos    YAML legible    Infraestructura predecible

Ansible fue creado en 2012 por Michael DeHaan con un objetivo claro: hacer la automatización IT accesible para todos, no solo para expertos en programación. En 2015 fue adquirido por Red Hat (ahora IBM), consolidándose como estándar de la industria.

🌟 Casos de uso principales​

1. Gestión de configuración​

Mantenemos la coherencia en todos nuestros servidores. Si tenemos 100 servidores web, nos aseguramos de que todos tengan la misma configuración de Nginx, los mismos certificados SSL y las mismas políticas de seguridad.

Ejemplo práctico:

- name: Configurar servidores uniformemente
  hosts: servers
  tasks:
    - name: Instalar Nginx
      apt:
        name: nginx
        state: present

    - name: Configurar firewall
      ufw:
        rule: allow
        port: '80,443'
        proto: tcp

2. Despliegue continuo (CI/CD)​

Integramos Ansible en nuestros pipelines de Jenkins, GitLab CI o GitHub Actions para desplegar aplicaciones de forma automatizada y consistente.

3. Orquestación multi-tier​

Coordinamos despliegues complejos que involucran bases de datos, load balancers, servidores de aplicación y más, en el orden correcto.

4. Gestión de la nube​

Aprovisionamos y gestionamos recursos en AWS, Azure, Google Cloud, OpenStack y otras plataformas cloud.

5. Cumplimiento y auditoría​

Garantizamos que nuestra infraestructura cumple con estándares de seguridad (PCI-DSS, HIPAA, SOC2) aplicando configuraciones de forma automática y auditable.

6. Disaster recovery​

Automatizamos la reconstrucción completa de nuestra infraestructura en minutos, convirtiendo un desastre en un inconveniente menor.

⚔️ Ansible vs otras herramientas (Chef, Puppet, SaltStack)​

Comparativa rápida​

CaracterísticaAnsibleChefPuppetSaltStack
Agentes❌ No (Agentless)✅ Sí✅ Sí✅ Sí
LenguajeYAML (Declarativo)Ruby (Imperativo)DSL propioYAML + Python
Curva de aprendizaje🟢 Baja🔴 Alta🟡 Media🟡 Media
ModeloPushPullPullPush/Pull
SSH nativo✅ Sí❌ No❌ No✅ Opcional
Velocidad inicial🚀 Muy rápida🐌 Lenta🐌 Lenta🏃 Rápida

Ventajas de Ansible​

1. Sin agentes (Agentless)​

Beneficios:

  • No necesitamos instalar/mantener software adicional en nuestros servidores
  • Menor superficie de ataque (seguridad)
  • Arranque inmediato: si tiene SSH, podemos gestionarlo

Chef/Puppet:

Inconvenientes:

  • Debemos instalar y mantener agentes en cada servidor
  • Los agentes consumen recursos (CPU, RAM)
  • Si el agente falla, perdemos control del servidor
2. YAML legible​

Ansible usa YAML, un formato de datos human-readable que podemos entender aunque no sepamos programar.

Ansible (YAML):

- name: Asegurar que Apache está corriendo
  service:
    name: apache2
    state: started
    enabled: yes

Chef (Ruby DSL):

service 'apache2' do
  action [:enable, :start]
  supports :restart => true, :reload => true
end

Puppet (DSL propio):

service { 'apache2':
  ensure => 'running',
  enable => true,
}
3. Modelo Push vs Pull​

Ansible (Push):

  • NOSOTROS decidimos cuándo se ejecutan los cambios
  • Control total del timing
  • Ideal para CI/CD y despliegues bajo demanda

Chef/Puppet (Pull):

  • Los agentes consultan periódicamente al master
  • Cambios eventuales (cada 30min por defecto)
  • Mejor para mantener estado a largo plazo

¿Cuándo es mejor cada uno?

  • Push (Ansible): Despliegues puntuales, CI/CD, cambios críticos inmediatos
  • Pull (Chef/Puppet): Infraestructura masiva que debe autocurarse continuamente
4. Curva de aprendizaje​

Tiempo para ser productivo:

  • Ansible: 🟢 1-2 días (si sabemos SSH y YAML básico)
  • SaltStack: 🟡 1-2 semanas
  • Chef: 🔴 2-4 semanas (requiere conocimientos de Ruby)
  • Puppet: 🔴 2-4 semanas (requiere aprender su DSL)

Cuándo NO usar Ansible​

Ansible no siempre es la mejor opción:

❌ Infraestructura gigante (10,000+ nodos) con cambios frecuentes: SaltStack es más rápido en ejecución masiva paralela.

❌ Necesitamos un agente siempre monitorizando: Puppet/Chef tienen agentes que pueden detectar drift (desviación) y autocorregir sin intervención manual.

❌ Lógica de negocio compleja en Ruby: Si nuestro equipo ya es experto en Ruby y Chef, migrar puede no aportar valor.

✅ La mayoría de los demás casos: Ansible es la opción más pragmática.

🏗️ Arquitectura de Ansible: visión general​

Componentes principales​

1. Control Node (nodo de control)​

Es donde instalamos y ejecutamos Ansible. Puede ser:

  • Nuestro portátil local
  • Un servidor bastión/jump host
  • Un runner de CI/CD (Jenkins, GitHub Actions, GitLab Runner)

Requisitos:

  • Sistema operativo: Linux, macOS, WSL (no Windows nativo)
  • Python 3.8+
  • Ansible instalado (pip install ansible)

2. Managed Nodes (nodos gestionados)​

Los sistemas que automatizamos. No necesitan Ansible instalado, solo:

  • Linux/Unix: SSH habilitado + Python 2.7 o 3.5+
  • Windows: WinRM habilitado + PowerShell 3.0+
  • Dispositivos de red: API REST o SSH

3. Inventario (Inventory)​

Un archivo (INI, YAML o script dinámico) que lista nuestros hosts y los agrupa.

Ejemplo (hosts.ini):

[madrid]
target1 ansible_host=localhost ansible_port=55000
target2 ansible_host=localhost ansible_port=55001

[barcelona]
target3 ansible_host=localhost ansible_port=55002

[servers:children]
madrid
barcelona

4. Módulos (Modules)​

Unidades de código reutilizable que ejecutan tareas específicas:

  • apt, yum: Gestión de paquetes
  • service: Gestión de servicios
  • file, copy, template: Gestión de archivos
  • user, group: Gestión de usuarios
  • docker_container, k8s: Contenedores
  • Más de 3,000 módulos incluidos + colecciones comunitarias

5. Playbooks​

Archivos YAML que definen el estado deseado de nuestra infraestructura. Son como "recetas" o "partituras" que Ansible ejecuta.

6. Plugins​

Extensiones que amplían las capacidades de Ansible:

  • Connection plugins: SSH, WinRM, Docker, kubectl
  • Inventory plugins: AWS EC2, Azure, GCP, VMware
  • Filter plugins: Transformaciones de datos (Jinja2)

Flujo de ejecución​

📋 Prerrequisitos para este curso​

Conocimientos recomendados​

Esenciales (debemos tener)​
  • ✅ Linux básico: Navegación por terminal, comandos básicos (ls, cd, cat, vim/nano)
  • ✅ SSH: Saber conectarnos a un servidor remoto (ssh user@host)
  • ✅ YAML básico: Entender la sintaxis (o aprender en el curso)
Útiles (ayudan mucho)​
  • 🟡 Git: Control de versiones para nuestros playbooks
  • 🟡 Docker: Para practicar sin romper nada
  • 🟡 Cloud básico: AWS/Azure/GCP conceptos generales
No necesarios (los aprenderemos aquí)​
  • ❌ Programación avanzada
  • ❌ Experiencia previa con IaC
  • ❌ Certificaciones

Entorno de práctica​

Para seguir el curso necesitaremos:

  1. Un sistema de control (nuestro PC)

    • Linux, macOS o Windows con WSL
    • Python 3.8+ instalado
    • Editor de texto (VS Code recomendado con extensión YAML)

  2. Nodos de práctica (al menos uno):

    Opción A: Máquinas virtuales locales

    • VirtualBox/VMware + Ubuntu Server
    • Vagrant para automatizar VMs

    Opción B: Contenedores Docker

    • Más ligero y rápido
    • Ideal para experimentar

    Opción C: VPS en la nube

    • AWS EC2 free tier
    • DigitalOcean Droplet ($5/mes)
    • Linode, Vultr, etc.

  3. Configuración SSH

    • Claves SSH generadas (ssh-keygen)
    • Acceso sin contraseña configurado (ssh-copy-id)

Verificación de prerrequisitos​

Antes de empezar, verificamos que tenemos todo listo:

# ¿Tienes Python 3?
python3 --version  # Debe ser 3.8 o superior

# ¿Tienes SSH?
ssh -V  # OpenSSH debe estar instalado

# ¿Tienes un servidor accesible? (ejemplo)
ssh usuario@ip_servidor  # Debe conectar sin errores

# ¿Puedes crear archivos YAML?
echo "clave: valor" > test.yml && cat test.yml

Si todos estos comandos funcionan, ¡estamos listos! 🎉

🎓 Qué aprenderemos en este curso​

Este curso está estructurado en módulos progresivos:

Fundamentos (módulos 1-6)​

  • ✅ Arquitectura y conceptos core
  • ✅ Instalación en diferentes sistemas
  • ✅ Inventarios y comandos ad-hoc
  • ✅ Escribir playbooks efectivos
  • ✅ Variables, facts y templating
  • ✅ Condicionales, bucles y manejo de errores

Avanzado (módulos 7-9)​

  • ✅ Roles y estructura modular
  • ✅ Ansible Vault (secretos seguros)
  • ✅ Jinja2 templates avanzados
  • ✅ Ansible Tower/AWX (GUI empresarial)
  • ✅ Integración con CI/CD
  • ✅ Futuro de Ansible y tendencias

Todos ellos acompañados de una parte práctica, como debe ser.

🚀 ¿Por qué aprender Ansible en 2026?​

Demanda laboral​

  • +40% de ofertas DevOps mencionan Ansible (Stack Overflow 2025)
  • Salarios: DevOps Engineers con Ansible ganan 15-25% más que sin automatización
  • Empresas: Usado por Red Hat, NASA, Apple, Cisco, Bloomberg

Comunidad y ecosistema​

  • 100,000+ Ansible roles en Ansible Galaxy
  • 3,000+ módulos oficiales + miles de colecciones comunitarias
  • Documentación exhaustiva y comunidad activa en GitHub

Futuro-proof​

  • Ansible Automation Platform 2.x (Red Hat) con soporte empresarial
  • Event-Driven Ansible: Reacciona automáticamente a eventos (próxima generación)
  • Integración con Kubernetes: Ansible Operator para gestionar apps cloud-native

Fundamentos y arquitectura de Ansible 🏗️​

Video pendiente de grabación

Suscríbete al canal de YouTube para recibir la notificación.

¿qué es ansible? iac y evolución​

🎻 La analogía: el director de orquesta​

Imaginemos que tenemos que dirigir una orquesta de 100 músicos.

  • Método Manual (SysAdmin tradicional): Vamos músico por músico diciéndole qué nota tocar en cada momento. Nos volvemos locos y la música suena fatal.
  • Scripts (Bash/Python): Les damos una partitura, pero si uno se pierde, la canción se rompe.
  • Ansible (IaC): Somos el director. Tenemos una partitura maestra (Playbook). Nosotros marcamos el ritmo y el estado deseado ("¡Más fuerte los violines!"). Si un músico desafina, Ansible se encarga de corregirlo automáticamente para que coincida con la partitura.

🧠 Concepto visual​

📘 Explicación técnica​

Ansible es una herramienta de Infraestructura como Código (IaC) open-source que automatiza el aprovisionamiento de software, la gestión de configuraciones y el despliegue de aplicaciones.

A diferencia de los scripts tradicionales que son imperativos (haz esto, luego esto, luego esto), Ansible tiende a ser declarativo. Nosotros definimos el estado final deseado (queremos que Nginx esté instalado y corriendo) y Ansible se encarga de los pasos necesarios para llegar ahí.

💻 Código: Script vs Ansible​

El método antiguo (Bash Script - Imperativo):

# script_instalar.sh
# Si ejecutas esto dos veces, apt podría quejarse o fallar
apt-get update
apt-get install -y nginx
service nginx start

El método Ansible (YAML - Declarativo):

# playbook.yml
- name: Asegurar que Nginx está presente
  apt:
    name: nginx
    state: present  # <-- ESTADO DESEADO

- name: Asegurar que Nginx está corriendo
  service:
    name: nginx
    state: started
    enabled: yes

📝 Resumen​

  • Ansible permite definir nuestra infraestructura como código (IaC).
  • Es declarativo: nos centramos en el "qué" (estado final), no en el "cómo".
  • Escala masivamente: gestiona 1 o 1000 servidores con el mismo esfuerzo.

Arquitectura "Agentless"​

🕵️ La analogía: la llave maestra​

Imaginemos que somos consultores que visitamos oficinas.

  • Con Agente (Puppet/Chef): Tenemos que instalar un robot en cada oficina antes de poder trabajar. Si el robot se rompe, no podemos hacer nada.
  • Agentless (Ansible): Usamos la puerta estándar (SSH) que ya tienen todas las oficinas. Solo necesitamos la llave (credenciales) para entrar, hacer nuestro trabajo y salir sin dejar rastro.

🧠 Concepto visual​

📘 Explicación técnica​

Ansible es Agentless. No requiere instalar ningún software adicional en los nodos que vamos a gestionar (ni demonios, ni bases de datos).

Utiliza protocolos estándar existentes:

  • Linux/Unix: SSH (Secure Shell).
  • Windows: WinRM (Windows Remote Management).

Esto reduce drásticamente la carga administrativa y los agujeros de seguridad, ya que no hay un "agente de Ansible" escuchando en un puerto extraño que debas parchear.

💻 Requisitos técnicos​

En el nodo de control (nuestro PC):

  • Python instalado.
  • Ansible instalado.

En los nodos gestionados (servidores):

  • Python instalado (para ejecutar los módulos que envía Ansible).
  • Acceso SSH habilitado.

📝 Resumen​

  • Ansible no instala agentes en los servidores destino.
  • Usa SSH para Linux y WinRM para Windows.
  • Es más seguro y ligero al no dejar procesos corriendo en segundo plano.

Idempotencia​

💡 La analogía: el interruptor de la luz​

Entramos en una habitación y queremos luz.

  • Si el interruptor está apagado, lo pulsamos -> Cambio de estado (Luz ON).
  • Si el interruptor ya está encendido, lo miramos y no hacemos nada -> Estado mantenido (Luz ON).
  • Si pulsamos el interruptor 50 veces hacia la posición "ON", el resultado es el mismo: la luz está encendida y no explota la bombilla. Eso es idempotencia.

🧠 Concepto visual​

📘 Explicación técnica​

La idempotencia es la propiedad de realizar una operación varias veces sin cambiar el resultado más allá de la aplicación inicial.

En Ansible, la mayoría de los módulos son idempotentes. Si ejecutamos un playbook 100 veces, Ansible solo realizará cambios la primera vez. Las 99 veces restantes verificará que el estado es correcto y reportará "OK" (sin cambios). Esto es vital para la estabilidad.

💻 Caso práctico​

Supongamos que queremos crear un usuario 'deployer'.

Ejecución 1 (El usuario no existe):

TASK [Crear usuario deployer] **************************************************
changed: [servidor1]  <-- Ansible lo crea. Estado: CHANGED (Amarillo)

Ejecución 2 (El usuario YA existe):

TASK [Crear usuario deployer] **************************************************
ok: [servidor1]       <-- Ansible verifica y no hace nada. Estado: OK (Verde)

📝 Resumen​

  • Idempotencia significa que podemos ejecutar el mismo código múltiples veces sin efectos secundarios negativos.
  • Garantiza la consistencia: el resultado final siempre es el estado deseado.
  • Ansible nos informa si hubo cambios (changed) o si ya estaba todo correcto (ok).

Nodo de control vs nodos gestionados​

🎮 La analogía: la consola y el personaje​

  • Nodo de Control: Es nuestro mando de la consola. Desde aquí enviamos las órdenes. Es donde está nuestra inteligencia.
  • Nodos Gestionados: Son los personajes del videojuego. Reciben las órdenes y actúan. Pueden ser guerreros (Linux), magos (Windows) o incluso el entorno (Routers).

🧠 Concepto visual​

📘 Explicación técnica​

  1. Nodo de Control (Control Node):

    • Es la máquina donde instalamos y ejecutamos Ansible.
    • Puede ser nuestro portátil, un servidor bastión o un runner de CI/CD (Jenkins/GitHub Actions).
    • Limitación: No soporta Windows nativo como nodo de control (debemos usar WSL).

  2. Nodos Gestionados (Managed Nodes):

    • Son los dispositivos que automatizas (Servidores, Nube, Redes).
    • No necesitan Ansible instalado.
    • Se organizan en un Inventario.

💻 Configuración típica​

Inventario (hosts.ini):

[madrid]
target1 ansible_host=localhost ansible_port=55000
target2 ansible_host=localhost ansible_port=55001

[barcelona]
target3 ansible_host=localhost ansible_port=55002

[servers:children]
madrid
barcelona

Comando desde el nodo de control:

# Hacemos ping a todos los nodos del inventario
ansible all -i hosts.ini -m ping

📝 Resumen​

  • Control Node: Donde ejecutas los comandos. Solo Linux/Unix (o WSL).
  • Managed Node: Donde se aplican los cambios. Cualquier sistema con SSH/WinRM y Python.
  • La relación es 1 a N: Un nodo de control puede gestionar miles de nodos gestionados.

Instalación y configuración ⚙️​

Preparamos nuestro entorno de trabajo para empezar a automatizar.

Requisitos previos (python)​

📋 Requisitos técnicos​

1. En el nodo de control (nuestro ordenador)​

Es donde instalamos Ansible.

  • Sistema Operativo: Linux, macOS, o WSL (Windows Subsystem for Linux). No soporta Windows nativo.
  • Python: Versión 3.8 o superior recomendada.
2. En los nodos gestionados (nuestros servidores)​

Son las máquinas que vamos a controlar.

  • Python: Necesitan tener Python instalado (versión 2.7+ o 3.5+).
  • SSH: Acceso vía SSH y credenciales válidas.

Si vemos un número, ¡estamos listos para repostar e instalar el Ferrari!

Instalación (Ubuntu/RHEL/macOS)​

Vamos a instalar Ansible en nuestro Nodo de Control. Recordemos que NO necesitamos instalar nada en los servidores que vamos a gestionar (agentless, ¿recordamos?).

📦 Guía de instalación por S.O.​

Elegimos nuestro sistema operativo y seguimos los pasos.

En Ubuntu, lo ideal es usar el PPA oficial para tener la última versión, ya que los repositorios por defecto suelen traer versiones antiguas.

# 1. Actualizar índices
sudo apt update

# 2. Instalar software-properties-common
sudo apt install -y software-properties-common

# 3. Añadir el repositorio oficial de Ansible (PPA)
sudo add-apt-repository --yes --update ppa:ansible/ansible

# 4. Instalar Ansible
sudo apt install -y ansible

✅ Verificación​

Una vez termine la instalación, verificamos que todo ha ido bien preguntándole a Ansible su versión:

ansible --version

Deberíamos ver una salida similar a esta:

ansible [core 2.14.x]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ...
  ansible python module location = ...
  python version = 3.10.x

¡Listo! Ya tenemos el poder de la automatización en nuestras manos.

1. Laboratorio práctico​

Para aprender Ansible necesitamos romper cosas. Y mejor romper un entorno de pruebas que el servidor de producción de nuestra empresa.

Vamos a montar un entorno local usando Docker. Si no sabemos de docker o simplemente queremos repasar, recordamos que tenemos un curso completo de Docker aquí

He creado un repositorio que automatiza el proceso, por lo que no tenemos que saber nada. Si preferimos montárnoslo por nuestra cuenta, también podemos replicarlo con 3 VMs a las que tengamos permisos de administrador y acceso SSH.

Clona el repositorio pabpereza/ansible-laboratory.

git clone https://github.com/pabpereza/ansible-laboratory.git

Le damos permisos de ejecución al script de setup:

cd ansible-laboratory
chmod +x setup.sh

Ejecutamos el script para montar el laboratorio y seguimos los pasos del menú interactivo:

./setup.sh

Para este curso, recomendamos usar la opción Local, esta requiere tener Docker instalado. Nos dará a elegir el número de targets (o servidores); recomendamos 3 para el curso.

Además, si no queremos usar nuestro host como nodo de control, el script nos da la opción de montar un contenedor extra que hará de nodo de control y lenvanta una instalacia de VS Code Server para que podamos editar nuestros playbooks desde el navegador y no manchemos nuestro entorno local.

2. Archivo ansible.cfg​

Ansible funciona "out of the box", pero para trabajar como un profesional, necesitamos configurarlo a nuestro gusto.

🧠 Precedencia de configuración​

Ansible es muy flexible buscando su configuración. No hay un solo sitio, busca en varios lugares en un orden específico. El primero que encuentra, gana.

💡 Best practice​

La mejor práctica es tener un archivo ansible.cfg en la carpeta de nuestro proyecto.

  • Así, la configuración viaja con nuestro código (Git).
  • Nuestros compañeros tendrán la misma configuración que nosotros.
  • Evitamos romper otros proyectos si cambiamos la configuración global.

📝 Ejemplo de ansible.cfg básico​

Creamos un archivo llamado ansible.cfg en nuestra carpeta de proyecto con este contenido recomendado para empezar:

[defaults]
# Dónde está tu lista de servidores por defecto
inventory = ./hosts.ini

# Usuario con el que te conectas a los servidores remotos
remote_user = ansible 

# Desactiva la comprobación de huellas SSH (útil para laboratorios, CUIDADO en prod)
host_key_checking = False

# Número de procesos paralelos (por defecto es 5, súbelo si tienes muchos hosts)
forks = 5

[privilege_escalation]
# Activar sudo automáticamente
become = True
# Método de elevación
become_method = sudo
# Usuario al que elevar (root)
become_user = root

Con esto, Ansible sabrá dónde mirar y cómo comportarse sin que tengamos que pasarle mil parámetros por línea de comandos.

3. Crear nuestro inventario​

Creamos un archivo llamado hosts.ini (o inventory) en la misma carpeta. Recordamos ajustar esta información con los puertos que nos haya puesto automáticamente el script de setup para cada target.

[servers]
target1 ansible_port=55000 ansible_host=localhost
target2 ansible_port=55001 ansible_host=localhost
target3 ansible_port=55002 ansible_host=localhost

[all:vars]
# Conectamos a localhost y cada host usa un puerto distinto redirigido al contenedor
ansible_user=ansible
ansible_ssh_pass=ansible # Contraseña por defecto del laboratorio, en producción usarías claves SSH o Ansible Vault para esto, lo veremos más adelante.
4. ¡Prueba de fuego! 🔥​

Ejecutamos nuestro primer comando ad-hoc para ver si hay conexión (ping):

ansible all -i hosts.ini -m ping

Si vemos algo verde que dice "ping": "pong", ¡felicidades! 🎉 Tenemos nuestro laboratorio de Ansible funcionando.

🧹 Limpieza​

Cuando terminemos de jugar, podemos ir a docker y parar todos los contenedores. Si queremos eliminar o reinstalar el laboratorio, seguimos el menú interactivo:

./setup.sh