Técnico
Semaphore UI 2.19: playbooks, llaves y prueba de salida
Semaphore UI ordena playbooks de Ansible y scripts con inventario, credenciales cifradas, horarios, logs y prueba de restauración para pymes.
Un playbook de Ansible actualiza servidores; Semaphore UI 2.19.12 agrega usuario, inventario, credencial, horario y log alrededor de esa ejecución. Para una pyme que todavía corre scripts por SSH desde una notebook, la diferencia aparece cuando alguien pregunta quién tocó producción y con qué llave. Esta guía muestra qué dato guarda, quién puede ejecutarlo y cómo probar la salida.
Dónde se corta la ejecución manual
El síntoma aparece cuando un script funciona solo en la máquina de una persona. La contraseña quedó en el historial, el inventario vive en un archivo sin dueño y el log se perdió al cerrar la terminal. El antagonista es el script SSH compartido con privilegios amplios y sin registro de aprobación. Semaphore UI v2.19.12 mantiene una idea práctica: una consola web para correr Ansible, Terraform/OpenTofu, Shell, PowerShell y Python. La documentación oficial indica que puede correr como binario Go o imagen Docker y guardar datos en SQLite, PostgreSQL u otra base soportada. El proyecto organiza tareas en proyectos, inventarios, llaves, repositorios, plantillas, schedules y miembros. La escala global vuelve visible el problema. GitHub informó en Octoverse 2025 que los desarrolladores fusionaron 43,2 millones de pull requests por mes en 2025. Esa cifra muestra cuántos cambios chicos llegan a producción. En una organización local, cada cambio de servidor necesita una historia más corta: qué se ejecutó, sobre qué host y con qué resultado. El objeto concreto es una llave SSH llamada soporte-general, copiada durante años entre proveedores. Cuando esa llave ejecuta un playbook, nadie puede separar mantenimiento legítimo de acceso heredado. Semaphore UI obliga a nombrar proyecto, inventario y usuario antes de correr la tarea. Esa fricción mínima baja el cambio técnico a un registro que dirección puede leer. Una ejecución sin registro se convierte en discusión cuando falla el siguiente turno.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, el equipo crea un proyecto para una aplicación, una sede o un entorno. Segundo, conecta un repositorio Git con playbooks o scripts. Tercero, carga un inventario con hosts y grupos. Cuarto, guarda llaves y variables en el Key Store o en grupos de variables. Quinto, define una plantilla de tarea: comando, repositorio, inventario, entorno y permisos. Sexto, un usuario autorizado ejecuta la tarea bajo demanda o por schedule. Séptimo, Semaphore registra salida, estado, duración y responsable. La documentación de projects aclara que cada recurso pertenece a un proyecto: plantillas, tareas, inventarios, llaves, repositorios, integraciones, schedules, runners y miembros. PostgreSQL puede guardar proyectos, usuarios, permisos y ejecuciones si se elige esa base para producción. Semaphore recibe una solicitud de ejecución y entrega log, estado y resultado. El backup copia base, archivo de configuración y claves cifradas; la restauración se prueba levantando una instancia de ensayo y ejecutando un playbook inocuo contra un host de prueba.
Qué se instala o configura primero
El primer piloto instala Semaphore UI con Docker o binario, PostgreSQL, proxy TLS, un repositorio Git, una cuenta de servicio SSH, dos grupos de usuarios y un backup diario. Con dólar oficial venta de ARS 1535, un alcance inicial puede ubicarse entre USD 600 y USD 1.500, es decir entre ARS 921.000 y ARS 2.302.500. Incluye instalación, tres playbooks, inventario, roles, logs, backup y restauración. No incluye escribir todos los playbooks ni cambiar firewalls de terceros. UMSA puede empezar con un caso reducido: reinicio controlado de servicios, actualización de paquetes y chequeo de espacio en disco para 8 servidores. El entregable verificable es una tarea por operación, cada una con responsable, inventario, llave usada, salida esperada y evidencia de rollback. Si una tarea requiere una llave compartida, queda marcada para reemplazo. El diseño se relaciona con una nota anterior sobre Kestra frente a cron. Kestra ordena flujos de datos y reintentos; Semaphore UI sirve mejor cuando el trabajo baja a servidores, playbooks, inventarios y llaves.
Dónde se rompe y cómo probarlo
El primer riesgo es dar permisos de ejecución a demasiada gente. La señal aparece cuando usuarios de lectura pueden correr tareas sobre producción. La prueba crea un usuario lector, intenta ejecutar una plantilla y exige rechazo. El segundo riesgo es guardar una llave SSH con alcance excesivo. La señal aparece cuando la misma llave entra a todos los hosts. La prueba usa un inventario de ensayo y confirma que la llave solo abre el grupo autorizado. El tercer riesgo es tratar el log como evidencia suficiente. La señal aparece cuando el log dice éxito y el servicio sigue caído. La prueba agrega una verificación posterior: consulta HTTP, salida de systemctl o archivo centinela. El cuarto riesgo es restaurar Semaphore sin llaves ni repositorios. La prueba levanta la copia, conecta el repo, ejecuta una tarea de bajo impacto y compara salida, usuario y horario. La decisión operativa es elegir tres tareas repetidas y prohibir su ejecución fuera del tablero durante una semana.
