Despliegue de AWX

Qué configuramos y por qué

En el mundo moderno de la infraestructura de TI, donde el número de servidores, servicios y configuraciones crece constantemente, la gestión manual se vuelve ineficiente y propensa a errores. Ansible es una potente herramienta de automatización que permite describir la infraestructura como código y gestionarla de forma declarativa. Sin embargo, trabajar con Ansible desde la línea de comandos puede ser complejo para equipos grandes o requerir herramientas adicionales para la planificación, auditoría y gestión centralizada de credenciales.

Aquí es donde entra en juego AWX. AWX es la versión de código abierto de Red Hat Ansible Tower, que proporciona una interfaz web para Ansible. Transforma Ansible de una herramienta de línea de comandos en una plataforma de automatización completa, accesible a través del navegador. Con AWX, podrá gestionar centralizadamente los siguientes aspectos:

• Inventario: Gestión dinámica y estática de la lista de servidores y dispositivos.
• Credenciales: Almacenamiento seguro de claves SSH, contraseñas, tokens de API y otros secretos.
• Proyectos: Sincronización de sus playbooks de Ansible desde repositorios Git (GitHub, GitLab, Bitbucket, etc.).
• Plantillas de tareas (Job Templates): Creación de tareas listas para ejecutar con parámetros predefinidos, que pueden ser iniciadas incluso por usuarios no técnicos.
• Programación: Configuración de ejecuciones regulares de automatización según un horario.
• Monitorización y auditoría: Visualización de los resultados de todas las ejecuciones, registros, historial de cambios y quién ejecutó qué.
• Control de acceso: Delegación de derechos y roles a los miembros del equipo.

¿Qué obtendrá el lector al final? Obtendrá una plataforma AWX completamente funcional en su VPS, lista para automatizar su infraestructura. Esto le permitirá a usted y a su equipo gestionar servidores de manera eficiente, desplegar aplicaciones, actualizar software y realizar otras tareas rutinarias con Ansible, utilizando una cómoda interfaz web.

Alternativas: Cloud-managed vs. Self-hosted

Existen dos enfoques principales para el uso de plataformas de automatización: servicios gestionados en la nube y despliegue propio (self-hosted). Red Hat ofrece la plataforma comercial Ansible Automation Platform (anteriormente Ansible Tower) como una solución gestionada, así como servicios en la nube que proporcionan capacidades similares sin la necesidad de gestionar la infraestructura subyacente. Sin embargo, el enfoque self-hosted en un VPS tiene sus ventajas:

• Control total: Usted controla completamente los datos, la seguridad y la configuración del sistema.
• Ahorro: A menudo, una solución self-hosted en un VPS es más económica, especialmente para equipos pequeños y medianos, en comparación con una suscripción mensual a alternativas en la nube.
• Flexibilidad: Posibilidad de ajuste fino para requisitos específicos de su infraestructura o políticas de seguridad.
• Aprendizaje y desarrollo: Una excelente oportunidad para profundizar sus conocimientos en el despliegue y la gestión de aplicaciones en contenedores.

El despliegue en un VPS es ideal para quienes buscan un equilibrio entre control, costo y conveniencia. Permite obtener una potente herramienta de automatización sin la necesidad de invertir en costosas infraestructuras de hardware o confiar completamente sus datos a proveedores de la nube externos.

Qué configuración de VPS se necesita para esta tarea

AWX, como cualquier aplicación web compleja, tiene ciertos requisitos de recursos. Dado que AWX funciona dentro de contenedores Docker e incluye varios componentes (PostgreSQL, Redis, RabbitMQ, interfaz web, ejecutores), requiere suficientes recursos para un funcionamiento estable. Los requisitos presentados a continuación son válidos para el año 2026 y están calculados para un uso típico de AWX para gestionar 10-50 nodos con varias tareas simultáneas.

Requisitos mínimos:

• CPU: 2 núcleos. AWX utiliza activamente la CPU durante la sincronización de proyectos, la ejecución de tareas y el procesamiento de solicitudes web.
• RAM: 4 GB. Este es un recurso crítico. AWX, PostgreSQL y otros contenedores pueden consumir una cantidad significativa de memoria. Menos de 4 GB resultará en un intercambio constante y bajo rendimiento.
• Disco: 40 GB SSD. Para el sistema operativo, imágenes Docker, la base de datos PostgreSQL y los registros. Se recomienda encarecidamente SSD para el rendimiento de la base de datos.
• Red: 100 Mbps. Para el acceso a la interfaz web, la sincronización de repositorios Git y la ejecución de tareas en nodos remotos.
• Sistema operativo: Ubuntu 24.04 LTS (o una versión LTS más reciente), CentOS Stream 9 (o RHEL 9).

Plan de VPS recomendado para la tarea:

Para un funcionamiento cómodo y la posibilidad de escalar en el futuro, se recomienda la siguiente configuración:

• CPU: 4 núcleos.
• RAM: 8 GB.
• Disco: 80-100 GB SSD (NVMe preferible).
• Red: 1 Gbps.

Con estas características, puede adquirir un VPS con las especificaciones indicadas para asegurar el funcionamiento estable de AWX y tener un margen de recursos para el crecimiento. Si planea gestionar cientos o miles de nodos, ejecutar decenas de tareas simultáneas o almacenar enormes volúmenes de registros, entonces debería considerar configuraciones más potentes.

Cuándo se necesita un dedicado, no un VPS

Un servidor dedicado se vuelve necesario cuando su proyecto excede las capacidades de un VPS, incluso los más potentes. Esto suele ocurrir en los siguientes casos:

• Escala: Gestión de miles de nodos, cientos de tareas ejecutándose simultáneamente, o cuando AWX es una parte críticamente importante de la pipeline CI/CD de una gran empresa.
• Rendimiento: Requisitos de rendimiento máximo del subsistema de disco (IOPS), CPU o RAM, que la virtualización no puede proporcionar.
• Aislamiento: Aislamiento completo de los "vecinos" del hipervisor, garantizando la estabilidad del rendimiento y la ausencia de factores de influencia externos.
• Políticas de seguridad propias: Necesidad de instalar hardware específico o requisitos de seguridad muy estrictos que son más fáciles de implementar en equipos totalmente controlados.

Para la mayoría de los escenarios descritos en esta guía (hasta 100-200 nodos), un VPS potente será suficiente. Si escala a nivel corporativo, considere alquilar un servidor dedicado adecuado.

Ubicación: en qué influye

La elección de la ubicación del servidor VPS influye en varios aspectos clave:

• Latencia: Cuanto más cerca esté el servidor de sus usuarios principales (el equipo que trabajará con AWX) y de los nodos gestionados, menor será la latencia. Una latencia baja es importante para una respuesta rápida de la interfaz web de AWX y para la ejecución oportuna de comandos de Ansible.
• Cumplimiento normativo: En algunos casos, se requiere almacenar datos en una jurisdicción específica debido a requisitos regulatorios (por ejemplo, GDPR en Europa).
• Velocidad de sincronización: Si sus repositorios Git o nodos gestionados están lejos del servidor AWX, la sincronización de proyectos y la ejecución de tareas pueden tardar más.

Se recomienda elegir una ubicación lo más cercana posible a su equipo y a la infraestructura principal que gestionará AWX.

Preparación del servidor

Antes de instalar AWX, es necesario realizar una configuración básica de seguridad e instalar las utilidades necesarias. Se asume que está utilizando una instalación limpia de Ubuntu 24.04 LTS y tiene acceso SSH como root o un usuario con privilegios sudo.

1. Actualización del sistema

Siempre comience actualizando el gestor de paquetes y los paquetes instalados para obtener las últimas versiones de software y parches de seguridad.

sudo apt update && sudo apt upgrade -y
# Actualiza la lista de paquetes y todos los paquetes instalados

sudo apt autoremove -y && sudo apt clean
# Elimina paquetes innecesarios y limpia la caché

2. Creación de un nuevo usuario con privilegios sudo

No se recomienda trabajar directamente como root. Cree un nuevo usuario y otórguele privilegios sudo.

sudo adduser awxadmin
# Crea un nuevo usuario con el nombre awxadmin

Siga las instrucciones para crear la contraseña y completar la información del usuario. Luego, añada el usuario al grupo sudo:

sudo usermod -aG sudo awxadmin
# Añade el usuario awxadmin al grupo sudo

Ahora, cierre la sesión de root e inicie sesión con el nuevo usuario awxadmin.

3. Configuración de claves SSH (recomendado)

El uso de claves SSH en lugar de contraseñas mejora significativamente la seguridad. Si aún no tiene una clave SSH, genérela en su máquina local:

ssh-keygen -t rsa -b 4096 -C "[email protected]"
# Genera una nueva clave SSH (en la máquina local)

Luego, copie la clave pública a su servidor. Reemplace your_user y your_server_ip con sus datos.

ssh-copy-id awxadmin@your_server_ip
# Copia la clave pública al servidor

Después de esto, puede deshabilitar la autenticación por contraseña para SSH en el archivo /etc/ssh/sshd_config, cambiando PasswordAuthentication yes a no y reiniciando el servicio SSH. Esto aumentará significativamente la seguridad, pero asegúrese de que su clave SSH funcione antes de deshabilitar las contraseñas.

sudo nano /etc/ssh/sshd_config
# Abre el archivo de configuración SSH

Encuentre la línea #PasswordAuthentication yes, descoméntela y cámbiela a:

PasswordAuthentication no

También se recomienda cambiar el puerto SSH de 22 a otro (por ejemplo, 2222), si no utiliza Fail2ban u otras herramientas de protección contra ataques de fuerza bruta:

Port 2222

Guarde el archivo y reinicie el servicio SSH:

sudo systemctl restart sshd
# Reinicia el servicio SSH

Ahora podrá conectarse al servidor solo con la clave SSH y, si lo cambió, con el nuevo puerto: ssh -p 2222 awxadmin@your_server_ip.

4. Configuración del firewall (UFW)

UFW (Uncomplicated Firewall) es una interfaz fácil de usar para iptables. Lo configuraremos para permitir solo los puertos necesarios.

sudo apt install ufw -y
# Instalación de UFW

sudo ufw allow OpenSSH
# Permitir SSH (si cambió el puerto SSH, reemplace con 'sudo ufw allow 2222/tcp')
sudo ufw allow http
# Permitir HTTP (puerto 80)
sudo ufw allow https
# Permitir HTTPS (puerto 443)
sudo ufw enable
# Habilitar el firewall. Confirme 'y'.
sudo ufw status verbose
# Verificar el estado del firewall

5. Instalación de Fail2ban

Fail2ban protege el servidor contra ataques de fuerza bruta, bloqueando las direcciones IP desde las cuales se realizan demasiados intentos de inicio de sesión fallidos.

sudo apt install fail2ban -y
# Instalación de Fail2ban

Cree un archivo de configuración local para que sus cambios no sean sobrescritos al actualizar el paquete:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
# Copia el archivo de configuración principal al local

Abra /etc/fail2ban/jail.local y configúrelo a su gusto. Asegúrese de que para la sección [sshd], enabled = true. Si cambió el puerto SSH, especifíquelo en port:

sudo nano /etc/fail2ban/jail.local

Ejemplo de cambios en jail.local (busque las secciones [DEFAULT] y [sshd]):

[DEFAULT]
bantime = 10m
findtime = 10m
maxretry = 5
banaction = ufw

[sshd]
enabled = true
port = ssh,2222 # Si cambió el puerto SSH, añádalo aquí
mode = aggressive

Guarde el archivo y reinicie Fail2ban:

sudo systemctl restart fail2ban
sudo systemctl enable fail2ban
# Reinicia y habilita el inicio automático de Fail2ban
sudo fail2ban-client status sshd
# Verifica el estado del jail sshd

Ahora su servidor está listo para la instalación de AWX con un nivel básico de seguridad.

Instalación de software — paso a paso

AWX se despliega utilizando Docker y Docker Compose. Utilizaremos las versiones actuales de estas herramientas y de AWX (para 2026, asumimos Docker 25.x+, Docker Compose 2.x+, AWX 24.x+).

1. Instalación de Docker y Docker Compose

Primero, instalaremos los paquetes necesarios para Docker.

sudo apt install ca-certificates curl gnupg lsb-release -y
# Instalación de utilidades necesarias para trabajar con repositorios

Añadiremos la clave GPG oficial de Docker:

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
# Añade la clave GPG de Docker

Añadiremos el repositorio de Docker a APT:

echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
# Añade el repositorio de Docker

Actualizaremos la lista de paquetes e instalaremos Docker Engine, Docker CLI y containerd:

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io -y
# Instalación de Docker Engine, CLI y containerd

Añadiremos el usuario actual al grupo docker para no tener que usar sudo con cada comando de Docker:

sudo usermod -aG docker awxadmin
# Añade el usuario awxadmin al grupo docker

Aplique los cambios de grupo. Para ello, cierre y vuelva a iniciar sesión, o ejecute:

newgrp docker
# Aplica los cambios de grupo sin cerrar la sesión

Verificaremos la instalación de Docker:

docker run hello-world
# Ejecuta un contenedor de prueba de Docker

Ahora instalaremos Docker Compose. Generalmente se distribuye como un plugin de Docker CLI.

sudo apt install docker-compose-plugin -y
# Instalación de Docker Compose como plugin

Verificaremos la versión de Docker Compose:

docker compose version
# Verifica la versión de Docker Compose

2. Instalación de Git y Ansible

AWX requerirá Git para la sincronización de proyectos y Ansible para la ejecución de tareas. Aunque AWX viene con Ansible dentro de un contenedor, tenerlo en el host es útil para la depuración y la gestión manual.

sudo apt install git ansible -y
# Instalación de Git y Ansible

3. Descarga del operador e instalador de AWX

AWX se despliega normalmente mediante un operador de Kubernetes o a través de un script de instalador que utiliza Docker Compose para una instalación local. Utilizaremos el instalador basado en Docker Compose.

mkdir ~/awx_install && cd ~/awx_install
# Creación del directorio para la instalación de AWX

Descargaremos la última versión estable de AWX. Para 2026, asumimos que la versión actual de AWX es 24.x.x. Siempre puede encontrar la última versión en la página de GitHub de AWX.

git clone https://github.com/ansible/awx.git
# Clonación del repositorio de AWX

cd awx/installer
# Navega al directorio del instalador

4. Configuración del instalador de AWX

El instalador de AWX utiliza el archivo inventory para la configuración. Ábralo para editarlo.

nano inventory
# Edición del archivo de inventario de AWX

En el archivo inventory, encuentre las siguientes líneas y configúrelas:

• admin_password: Establezca una contraseña segura para el administrador de AWX.
• secret_key_path: Asegúrese de que esta ruta exista o se creará.
• docker_compose_dir: Ruta donde se almacenarán los archivos de Docker Compose.
• pg_password, rabbitmq_password: Puede dejar los valores predeterminados si es una instalación de prueba, pero para producción es mejor generar contraseñas únicas.

Ejemplo de cambios (encuentre y modifique):

[all:vars]
admin_password='YourStrongAdminPassword123!' # Establezca su contraseña
secret_key_path=/var/lib/awx/awxsecret.key # Ruta al archivo de clave secreta
docker_compose_dir=~/awx_install/awx-compose # Directorio para los archivos de Docker Compose

# ... (los demás parámetros se pueden dejar por defecto para la primera instalación)

Guarde los cambios (Ctrl+O, Enter, Ctrl+X).

5. Ejecución del instalador de AWX

Ahora ejecutaremos el script del instalador. Utiliza Ansible para desplegar todos los componentes de AWX mediante Docker Compose.

ansible-playbook -i inventory install.yml
# Ejecuta el playbook para la instalación de AWX

Este proceso tomará algún tiempo, ya que Docker descargará todas las imágenes necesarias y configurará los contenedores. Una vez completado, verá un mensaje de instalación exitosa.

6. Verificación del funcionamiento de los contenedores

Una vez finalizada la instalación, asegúrese de que todos los contenedores de AWX estén en ejecución y funcionando correctamente.

docker compose -f ~/awx_install/awx-compose/docker-compose.yml ps
# Verifica el estado de los contenedores de AWX

Debería ver una lista de contenedores (awx_web, awx_task, awx_postgres, awx_redis) con el estado Up. Si algún contenedor no está en ejecución, revise los logs con el comando docker compose logs <container_name>.

AWX estará disponible por defecto en el puerto 80 (HTTP). En la siguiente sección, configuraremos HTTPS.

Configuración

Después de una instalación exitosa de AWX, es necesario realizar la configuración inicial, asegurar el acceso a través de HTTPS y verificar la operatividad del sistema.

1. Acceso a la interfaz web de AWX

AWX está disponible por defecto a través de HTTP en el puerto 80. Abra su navegador web y navegue a la dirección IP de su VPS o nombre de dominio (si ya ha configurado DNS): http://your_server_ip_or_domain.

Verá la página de inicio de sesión de AWX. Utilice las siguientes credenciales:

• Nombre de usuario: admin
• Contraseña: La contraseña que estableció en el archivo inventory (admin_password).

Después de iniciar sesión, accederá al panel de control de AWX.

2. Configuración de TLS/HTTPS con Caddy

El uso de HTTP para acceder a AWX no es seguro, ya que todos los datos, incluidas las credenciales, se transmiten en texto plano. Configuraremos HTTPS utilizando Caddy, un servidor web moderno con gestión automática de certificados Let's Encrypt. Caddy es fácil de configurar y renueva automáticamente los certificados.

2.1. Instalación de Caddy

Primero, detenga AWX para que Caddy pueda usar el puerto 80/443:

cd ~/awx_install/awx/installer
ansible-playbook -i inventory -e "awx_component_state=absent" install.yml
# Detención y eliminación de los contenedores de AWX para liberar los puertos 80/443
# (AWX se reinstalará con la configuración del puerto 8052 para acceso interno)

Instale Caddy:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy -y
# Instalación de Caddy desde el repositorio oficial

2.2. Configuración de Caddyfile

Cree el archivo de configuración de Caddy para AWX. Supongamos que su dominio para AWX es awx.yourdomain.com.

sudo nano /etc/caddy/Caddyfile
# Apertura del archivo de configuración de Caddy

Elimine todo el contenido existente e inserte lo siguiente. Reemplace awx.yourdomain.com con su dominio real.

awx.yourdomain.com {
    reverse_proxy localhost:8052 # AWX por defecto escucha en 8052 después de la instalación con Caddy
    # Optional: Enable Caddy's automatic HTTPS
    tls {
        # email [email protected] # Optional: Specify email for Let's Encrypt notifications
    }
    # Optional: Log requests
    log {
        output file /var/log/caddy/awx_access.log
        format json
    }
}

Guarde el archivo (Ctrl+O, Enter, Ctrl+X).

2.3. Reconfiguración de AWX para trabajar con Caddy

Ahora necesitamos modificar el archivo inventory de AWX para que no intente usar los puertos 80/443, sino que escuche en un puerto interno, por ejemplo, 8052.

cd ~/awx_install/awx/installer
nano inventory
# Apertura del archivo de inventario de AWX

Encuentre la sección [all:vars] y añada o modifique las siguientes líneas:

# ...
awx_web_port=8052
awx_nginx_port=8052
# ...

Guarde el archivo y ejecute de nuevo el instalador de AWX. Ahora AWX estará configurado para escuchar en el puerto 8052, y Caddy proxyará las solicitudes hacia él.

ansible-playbook -i inventory install.yml
# Reinicio del instalador de AWX con la nueva configuración de puerto

2.4. Inicio de Caddy

Después de la reinstalación exitosa de AWX, inicie y habilite Caddy:

sudo systemctl enable caddy
sudo systemctl restart caddy
# Habilitar e iniciar el servicio Caddy
sudo systemctl status caddy
# Comprobar el estado de Caddy

Asegúrese de que Caddy funcione sin errores. Ahora puede acceder a AWX a través de https://awx.yourdomain.com. Caddy obtendrá y configurará automáticamente un certificado Let's Encrypt.

3. Verificación de la operatividad

Después de configurar HTTPS, verifique el acceso a AWX y sus funciones principales.

• Acceso por HTTPS: Abra https://awx.yourdomain.com en el navegador. Asegúrese de que la conexión sea segura (candado verde en la barra de direcciones).
• Inicio de sesión: Inicie sesión con las credenciales admin.
• Creación del primer proyecto:
  • Vaya a la sección Projects.
  • Haga clic en Add.
  • Especifique el Name (por ejemplo, "Mi Primer Proyecto").
  • Seleccione SCM Type: Git.
  • Especifique la SCM URL (por ejemplo, https://github.com/ansible/ansible-examples.git).
  • Haga clic en Save.
  • Luego, haga clic en el icono de sincronización junto al proyecto para que AWX descargue los playbooks del repositorio.
• Creación de un inventario:
  • Vaya a la sección Inventories.
  • Haga clic en Add y seleccione Inventory.
  • Especifique el Name (por ejemplo, "Mi Inventario Localhost").
  • Haga clic en Save.
  • Dentro del inventario, vaya a la pestaña Hosts, haga clic en Add y añada el host localhost.
• Creación de una plantilla de trabajo (Job Template):
  • Vaya a la sección Templates.
  • Haga clic en Add y seleccione Job Template.
  • Especifique el Name (por ejemplo, "Ping Localhost").
  • Seleccione Inventory: Mi Inventario Localhost.
  • Seleccione Project: Mi Primer Proyecto.
  • Especifique Playbook: ping.yml (este playbook está en ansible-examples).
  • Seleccione Credential (si es necesario, pero no es obligatorio para ping localhost).
  • Haga clic en Save.
  • Ejecute la plantilla haciendo clic en el icono de "cohete" junto a ella. Asegúrese de que la tarea se complete con éxito.

Estos pasos confirmarán la operatividad básica de AWX y su preparación para un uso posterior.

Copias de seguridad y mantenimiento

La copia de seguridad es un aspecto crítico de cualquier sistema, especialmente uno como AWX, que gestiona su infraestructura. La pérdida de datos de AWX puede significar la pérdida de todo el historial de automatización, inventario y credenciales.

1. Qué respaldar

Para AWX, es necesario respaldar los siguientes componentes:

• Base de datos PostgreSQL: Contiene todos los metadatos de AWX: inventario, proyectos, credenciales, plantillas de trabajo, historial de ejecuciones, usuarios y sus roles. Este es el componente más importante.
• Archivos de configuración de AWX: Principalmente el archivo inventory que utilizó para la instalación y, posiblemente, otros archivos si los modificó.
• Clave secreta de AWX (secret_key_path): Esta clave se utiliza para cifrar datos confidenciales en la base de datos. Sin ella, la restauración de la base de datos es imposible. Asegúrese de que también se realice una copia de seguridad.
• Datos de proyectos: Si almacena proyectos localmente (aunque normalmente se sincronizan desde Git), asegúrese de que también se incluyan en la copia de seguridad.

2. Script simple de copia de seguridad automática

AWX proporciona una utilidad de copia de seguridad integrada. La utilizaremos para crear un script simple que se ejecute según un horario.

Cree el archivo awx_backup.sh en el directorio, por ejemplo, /usr/local/bin/:

sudo nano /usr/local/bin/awx_backup.sh

Inserte el siguiente contenido, reemplazando YOUR_AWX_INSTALL_DIR con la ruta a su directorio de instalación de AWX (por ejemplo, ~/awx_install/awx/installer) y /path/to/backup/destination con su ruta de destino para las copias de seguridad.

#!/bin/bash

# Ruta al directorio del instalador de AWX
AWX_INSTALL_DIR="/home/awxadmin/awx_install/awx/installer"

# Directorio para almacenar las copias de seguridad
BACKUP_DIR="/var/backups/awx"

# Fecha actual para el nombre del archivo de copia de seguridad
DATE=$(date +%Y%m%d%H%M%S)

# Nombre del archivo de copia de seguridad
BACKUP_FILE="${BACKUP_DIR}/awx_backup_${DATE}.tar.gz"

# Creamos el directorio para las copias de seguridad si no existe
mkdir -p "${BACKUP_DIR}"

echo "Iniciando copia de seguridad de AWX en ${DATE}..."

# Ejecución del script de copia de seguridad de AWX
# El playbook del instalador de AWX tiene un objetivo incorporado para la copia de seguridad
cd "${AWX_INSTALL_DIR}" || { echo "Error: Directorio de instalación de AWX no encontrado."; exit 1; }
ansible-playbook -i inventory install.yml -e "mode=backup"

# La copia de seguridad de AWX crea un tar.gz en el directorio donde se encuentra docker-compose.yml
# Lo movemos a nuestro directorio de copias de seguridad
# El nombre del archivo será awx-backup-YYYY-MM-DD-HHMMSS.tar.gz
LATEST_BACKUP=$(ls -t ~/awx_install/awx-compose/awx-backup-*.tar.gz | head -1)

if [ -f "$LATEST_BACKUP" ]; then
    mv "$LATEST_BACKUP" "${BACKUP_FILE}"
    echo "Copia de seguridad de AWX creada con éxito: ${BACKUP_FILE}"
    # Limpieza de copias de seguridad antiguas (mantener los últimos 7 días)
    find "${BACKUP_DIR}" -type f -name "awx_backup_*.tar.gz" -mtime +7 -delete
    echo "Copias de seguridad antiguas limpiadas."
else
    echo "Error: Archivo de copia de seguridad de AWX no encontrado después de ejecutar el playbook."
    exit 1
fi

echo "Copia de seguridad de AWX finalizada."

Haga el script ejecutable:

sudo chmod +x /usr/local/bin/awx_backup.sh

Configure la ejecución del script usando Cron. Por ejemplo, para una copia de seguridad diaria a las 03:00 de la mañana:

sudo crontab -e
# Abrir crontab para el usuario root

Añada la siguiente línea al final del archivo:

0 3 * * * /usr/local/bin/awx_backup.sh >> /var/log/awx_backup.log 2>&1
# Ejecución diaria de la copia de seguridad a las 03:00 de la mañana

3. Dónde almacenar las copias de seguridad

Almacenar las copias de seguridad en el mismo servidor que AWX es altamente desaconsejable. En caso de fallo del servidor, perderá tanto el sistema como sus copias de seguridad. Opciones recomendadas:

• Almacenamiento externo compatible con S3: Servicios como AWS S3, Backblaze B2, DigitalOcean Spaces o MinIO en otro servidor son una excelente opción para un almacenamiento duradero y fiable. Utilice utilidades como s3cmd, rclone o aws cli para enviar archivos.
• VPS separado: Puede configurar otro VPS, menos potente, exclusivamente para almacenar copias de seguridad. Utilice rsync o scp para transferir archivos.
• Compartición NFS/SMB: Si dispone de almacenamiento de red centralizado.

Extienda el script awx_backup.sh para que envíe el archivo .tar.gz creado a un almacenamiento remoto después de su creación.

4. Actualizaciones: Rolling vs. Ventana de mantenimiento

La actualización de AWX y sus dependencias (Docker, SO) requiere un enfoque cuidadoso.

• Actualización del SO y Docker: Se recomienda realizarla en una "ventana de mantenimiento" cuando la carga del servidor sea mínima. Estas actualizaciones pueden requerir un reinicio del servidor o del demonio de Docker, lo que provocará una indisponibilidad temporal de AWX.
• Actualización de AWX: La actualización de la plataforma AWX en sí se realiza normalmente descargando una nueva versión del instalador y ejecutando de nuevo ansible-playbook -i inventory install.yml. El instalador se encargará de actualizar los contenedores y migrar la base de datos. Lea siempre las notas de la versión (release notes) antes de actualizar AWX para estar al tanto de posibles cambios y requisitos.
• Estrategia:
  • Realice siempre una copia de seguridad completa antes de cualquier actualización importante.
  • Pruebe las actualizaciones en un servidor de staging, si es posible.
  • Evite las "actualizaciones continuas" (rolling updates) para AWX en un solo VPS, ya que no es una solución en clúster. Planifique una pequeña ventana de indisponibilidad.

El mantenimiento regular y las actualizaciones oportunas son importantes para la seguridad y estabilidad de su plataforma de automatización.

Solución de problemas + Preguntas frecuentes

Esta sección recopila respuestas a preguntas frecuentes y soluciones a problemas comunes que pueden surgir durante el despliegue y la operación de AWX.

AWX no se inicia o los contenedores están en estado "Exited"

Qué verificar:

1. Logs de los contenedores: El primer paso es revisar los logs del contenedor problemático. Use el comando docker compose -f ~/awx_install/awx-compose/docker-compose.yml logs <имя_контейнера> (por ejemplo, awx_web, awx_task, awx_postgres).
2. Disponibilidad de puertos: Asegúrese de que los puertos necesarios (80, 443, 8052) no estén ocupados por otros procesos. Use sudo lsof -i :80 o sudo netstat -tulnp | grep :80.
3. Recursos disponibles: Verifique el uso de RAM y disco. AWX requiere recursos significativos. Los comandos free -h y df -h ayudarán. La falta de memoria a menudo provoca la detención de los contenedores.
4. Archivo de inventario: Asegúrese de que en ~/awx_install/awx/installer/inventory no haya errores tipográficos, especialmente en las contraseñas.

Cómo solucionarlo: Corrija los errores encontrados en los logs. Si el problema está en los puertos, detenga el servicio en conflicto o cambie el puerto de AWX/Caddy. Si la RAM es insuficiente, considere actualizar el VPS.

No se puede acceder a AWX a través de la interfaz web

Qué verificar:

1. Firewall (UFW): Asegúrese de que los puertos 80 (HTTP) y 443 (HTTPS) estén permitidos en UFW: sudo ufw status verbose.
2. Caddy/Nginx: Si utiliza un proxy inverso (Caddy o Nginx), verifique si está en ejecución y configurado correctamente. sudo systemctl status caddy.
3. Registro DNS: Si utiliza un nombre de dominio, asegúrese de que el registro DNS (registro A) para su dominio (por ejemplo, awx.yourdomain.com) apunte a la dirección IP de su VPS.
4. Puerto interno de AWX: Verifique en qué puerto AWX está escuchando dentro del contenedor (por defecto 8052 después de la configuración con Caddy). Caddy debe hacer proxy a este puerto.

Cómo solucionarlo: Abra los puertos en UFW, reinicie Caddy, actualice el registro DNS.

Los proyectos no se sincronizan desde el repositorio Git

Qué verificar:

1. URL del repositorio: Asegúrese de que la URL del repositorio Git esté especificada correctamente (por ejemplo, https://github.com/user/repo.git).
2. Credenciales SCM: Si el repositorio es privado, asegúrese de que se hayan creado y adjuntado las credenciales SCM correctas en AWX (nombre de usuario/contraseña de Git o clave SSH).
3. Disponibilidad del host Git: Asegúrese de que el servidor AWX pueda conectarse al host Git (por ejemplo, ping github.com).
4. Logs del proyecto: En AWX, vaya a Projects, seleccione su proyecto y revise los logs de la última sincronización. Allí se indicará la causa del error.

Cómo solucionarlo: Corrija la URL, actualice las credenciales, verifique la disponibilidad de la red. Para las claves SSH, asegúrese de que la clave se haya añadido a AWX y que no tenga una frase de contraseña, a menos que esté previsto.

Las tareas de Ansible terminan con el error "Host Key Verification Failed"

Qué verificar:

1. Hosts conocidos: AWX, al igual que Ansible normal, añade las claves de los hosts a known_hosts. Si la dirección IP del servidor remoto ha cambiado o la clave ha sido comprometida, puede ocurrir este error.
2. Credenciales SSH: Asegúrese de que las credenciales SSH utilizadas en la plantilla de la tarea sean correctas y tengan los permisos necesarios en el host remoto.

Cómo solucionarlo: En AWX, existe la opción "Enable Host Key Checking" en la plantilla de la tarea. Para iniciar la depuración, puede deshabilitarla temporalmente (no recomendado para producción). Es mejor añadir la clave del host manualmente: conéctese al host remoto desde el servidor AWX con el comando ssh root@remote_host_ip (o con otro usuario), para que la clave se añada a ~/.ssh/known_hosts dentro del contenedor AWX-task. O configure AWX para la gestión automática de claves de host.

¿Qué configuración mínima de VPS es adecuada?

Para una instalación mínima de AWX, capaz de servir a un pequeño número de nodos (hasta 10-15) y ejecutar varias tareas al día, se requerirá un VPS con 2 núcleos de CPU, 4 GB de RAM y 40 GB de disco SSD. Sin embargo, para un trabajo más cómodo y escalabilidad, especialmente si planea gestionar más de 20 nodos o ejecutar tareas paralelas, se recomienda encarecidamente una configuración con 4 núcleos de CPU, 8 GB de RAM y 80-100 GB de SSD (NVMe).

¿Qué elegir: VPS o dedicado para esta tarea?

La elección entre un VPS y un servidor dedicado depende de la escala de su automatización y de los requisitos de rendimiento/aislamiento. Para la mayoría de los desarrolladores individuales, equipos pequeños o fundadores en solitario que gestionan hasta 100-200 nodos, un VPS potente será suficiente. Ofrece un excelente equilibrio entre costo, flexibilidad y rendimiento. Un servidor dedicado se justifica si gestiona cientos o miles de nodos, tiene requisitos muy altos de rendimiento del subsistema de disco, necesita un aislamiento de hardware completo o tiene estrictos requisitos de seguridad corporativos que no pueden satisfacerse en hardware virtualizado.

Conclusiones y próximos pasos

¡Felicidades! Ha desplegado AWX con éxito en su VPS, creando una plataforma centralizada para la gestión de la automatización basada en Ansible. Ahora tiene una herramienta poderosa que ayudará a su equipo a gestionar la infraestructura de manera eficiente, estandarizar los procesos de despliegue y reducir la cantidad de errores manuales.

¿Hacia dónde avanzar?

1. Integración con CI/CD: Incluya AWX en su pipeline de integración continua/entrega continua. Ejecute tareas de AWX automáticamente después de una compilación de código exitosa o la fusión de ramas.
2. Expansión del inventario: Configure un inventario dinámico desde proveedores de la nube (AWS, Azure, GCP) o sistemas de monitoreo para que AWX siempre esté al tanto de su infraestructura actual.
3. Monitoreo y registro: Integre los logs de AWX con sistemas de monitoreo centralizados (Prometheus, Grafana) y agregación de logs (ELK Stack, Loki) para una mejor visión general del estado de su automatización.
4. Gestión de secretos: Utilice las capacidades de AWX para el almacenamiento y la gestión segura de credenciales, y considere la integración con almacenes de secretos externos, como HashiCorp Vault, para mejorar la seguridad.