Semaphore: UI para Ansible cuando el equipo crece

Actualizado: 2026-05-03

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; AWX necesita típicamente ~4 GB.
• 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

1. El equipo tiene un repo Git con playbooks Ansible.
2. Se crea proyecto en Semaphore apuntando al repo.
3. Se define inventory (producción, staging, etc).
4. Se carga la SSH key con acceso a los hosts.
5. Se crean templates: “deploy web service”, “rotate certs”, “restart postgres”.
6. 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. Muchas veces, lo simple es lo correcto.

1. Semaphore