Semaphore: UI para Ansible cuando el equipo crece

Semaphore^[1] es la interfaz web open source para ejecutar playbooks de Ansible: simple, ligera, auto-hosteable. Nació como alternativa pragmática a AWX (upstream open-source de Ansible Tower / Red Hat Ansible Automation Platform), menos features, pero muchísimo más simple de operar. Para equipos medianos que han superado "ejecutar desde laptop" pero no necesitan la complejidad de AWX, es la opción sensata.

Puntos clave

• Semaphore resuelve los cuatro problemas de escala de Ansible: auditoría, permisos, historial de ejecuciones y secretos centralizados.

• La arquitectura es mínima: un binario Go, PostgreSQL, y Ansible disponible en el servidor o container.

• El RBAC cubre cinco roles bien delimitados (admin, project owner, manager, task runner, guest).

• Semaphore consume ~500 MB de RAM frente a los ~4 GB de AWX.

• Para equipos de menos de 50 con necesidades moderadas, Semaphore es la elección correcta. AWX para equipos grandes con workflows complejos.

Qué resuelve Semaphore

Los problemas que aparecen cuando el equipo crece:

• Auditoría: ¿quién ejecutó qué playbook cuándo y sobre qué hosts?

• Permisos: ¿qué usuarios pueden correr qué playbooks sobre qué inventory?

• Historial: ¿qué salida dio esa ejecución de hace una semana?

• Schedules: playbooks periódicos sin dedicar un cron host.

• Secretos centralizados: vault keys, SSH keys, sin distribuir por laptops.

Sin UI centralizada, todo esto se vuelve ad-hoc y frágil. El mismo principio aplica a la gestión de infraestructura con GitOps: la visibilidad del estado de automatización es tan importante como la automatización en sí.

Arquitectura

Componentes mínimos:

• Servidor Semaphore (Go, binario único).

• Base de datos: MySQL/MariaDB, PostgreSQL, o BoltDB embebido.

• Ansible disponible en el servidor o container.

No hay workers distribuidos ni colas complejas. Para equipos con menos de 100 ejecuciones simultáneas, basta.

Instalación Docker

version: "3.8"
services:
  semaphore:
    image: semaphoreui/semaphore:latest
    ports:
      - "3000:3000"
    environment:
      SEMAPHORE_DB_DIALECT: postgres
      SEMAPHORE_DB_HOST: postgres
      SEMAPHORE_DB_USER: semaphore
      SEMAPHORE_DB_PASS: ${DB_PASS}
      SEMAPHORE_DB: semaphore
      SEMAPHORE_PLAYBOOK_PATH: /tmp/semaphore
      SEMAPHORE_ADMIN_PASSWORD: ${ADMIN_PASS}
      SEMAPHORE_ADMIN_NAME: admin
      SEMAPHORE_ADMIN_EMAIL: admin@example.com
    volumes:
      - semaphore_data:/etc/semaphore
      - semaphore_tmp:/tmp/semaphore
    depends_on:
      - postgres

  postgres:
    image: postgres:16
    environment:
      POSTGRES_USER: semaphore
      POSTGRES_PASSWORD: ${DB_PASS}
      POSTGRES_DB: semaphore
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  semaphore_data:
  semaphore_tmp:
  postgres_data:

Arrancar y loguearse en http://localhost:3000 con admin. Exponer detrás de Traefik en Swarm o Nginx con HTTPS es el siguiente paso habitual.

Conceptos clave

• Project: espacio aislado con su inventory, keys, templates.

• Inventory: lista de hosts, estático o dinámico (script, AWS, etc).

• Key Store: SSH keys, passwords, vault passwords.

• Repository: repo Git donde viven los playbooks. Semaphore hace pull y ejecuta.

• Task Template: asocia un playbook + inventory + keys. Es lo que se ejecuta.

• Schedule: un template que corre en cron.

Flujo típico

• El equipo tiene un repo Git con playbooks Ansible.

• Se crea proyecto en Semaphore apuntando al repo.

• Se define inventory (producción, staging, etc).

• Se carga la SSH key con acceso a los hosts.

• Se crean templates: desplegar servicio web, rotar certificados, reiniciar postgres.

• Los miembros del equipo ejecutan templates desde UI, con log en vivo.

Todo con permisos: admin puede todo, el resto solo lo que se les asigne.

Permisos y RBAC

Cinco roles bien delimitados:

• Admin global: manage usuarios, settings.

• Project owner: manage su proyecto.

• Manager: puede ejecutar y editar templates.

• Task runner: solo ejecutar templates existentes.

• Guest: read-only.

Para equipos con separación dev/ops clara, esto cubre. Para multi-tenancy complejo, AWX tiene más granularidad.

Integración con CI/CD

Semaphore expone API REST. Patrones comunes:

• Gitea / GitHub Actions llama a Semaphore API tras PR merge.

• Webhook de repo a Semaphore para rebuild de inventory dinámico.

• ChatOps: bot de Slack que ejecuta templates vía API.

• Monitorización: alertas que disparan templates de remediación.

curl -X POST https://semaphore.example.com/api/project/1/tasks 
  -H "Cookie: semaphore=..." 
  -d '{"template_id": 5, "debug": false}'

Semaphore vs AWX

Semaphore para equipos de menos de 50 con necesidades moderadas. AWX para equipos grandes con requisitos complejos.

Seguridad operacional

Lista básica:

• HTTPS obligatorio vía reverse proxy (Traefik, Nginx).

• Auth integrada con OIDC o LDAP.

• SSH keys con passphrase o Vault para secrets.

• Backup regular del volumen data + dump DB.

• Monitorización de intentos fallidos de login.

Conclusión

Semaphore es la opción pragmática para equipos medianos que quieren una UI para Ansible sin la complejidad de AWX. Su foco en simplicidad es su fuerza: instalas en minutos, operas sin dolor, cubre los casos reales. Para organizaciones grandes con requisitos de workflow complejos, SSO empresarial y multi-tenancy, AWX sigue siendo la referencia.

La elección debe basarse en tamaño del equipo y sofisticación de necesidades. Para un equipo mediano, lo simple es lo correcto.

Fuentes:

1. Semaphore UI: documentación oficial^[2]
2. Ansible: documentación oficial de Ansible^[3]
3. GitHub: repositorio oficial de semaphoreui/semaphore^[4]

Preguntas frecuentes

¿Cuántos recursos necesita Semaphore comparado con AWX?

Semaphore consume alrededor de 500 MB de RAM, frente a los ~4 GB de AWX. La arquitectura es mínima: un binario Go, una base de datos (MySQL/MariaDB, PostgreSQL o BoltDB embebido) y Ansible disponible en el servidor o contenedor, sin workers distribuidos ni colas complejas. Para equipos con menos de 100 ejecuciones simultáneas basta. AWX, en cambio, recomienda Kubernetes para el despliegue y tiene una curva de aprendizaje media-alta, aunque ofrece RBAC avanzado, workflows en grafo y soporte comercial de Red Hat.

¿Qué roles de permisos ofrece Semaphore y son suficientes para mi equipo?

Cinco roles bien delimitados: admin global (gestiona usuarios y settings), project owner (gestiona su proyecto), manager (ejecuta y edita templates), task runner (solo ejecuta templates existentes) y guest (solo lectura). Para equipos con una separación dev/ops clara y menos de 50 personas con necesidades moderadas, esto cubre los casos reales. Si necesitas multi-tenancy complejo, SSO empresarial o granularidad fina, AWX ofrece más. La autenticación puede integrarse con OIDC o LDAP.

¿Puedo lanzar playbooks en Semaphore desde mi pipeline de CI/CD o desde Slack?

Sí, mediante su API REST: los patrones habituales son cuatro. Gitea o GitHub Actions llaman a la API de Semaphore tras el merge de un PR; los webhooks del repositorio fuerzan el rebuild de un inventory dinámico. Un bot de Slack (ChatOps) ejecuta templates, y las alertas de monitorización disparan templates de remediación. Un POST a /api/project/1/tasks con el template_id en el cuerpo lanza una ejecución; conviene exponer Semaphore solo por HTTPS detrás de Traefik o Nginx.

Fuentes

1. Semaphore
2. Semaphore UI: documentación oficial
3. Ansible: documentación oficial de Ansible
4. GitHub: repositorio oficial de semaphoreui/semaphore