Interfaz de Ansible: Semaphore UI vs Ansible Automation Platform (AAP)

AAP 2.6 admite una instalación en contenedores Podman sobre RHEL y una instalación basada en Operator sobre OpenShift. Su instalador RPM anterior sigue admitido en RHEL 9 en 2.6 para migraciones, pero está obsoleto. Red Hat documenta topologías compatibles y un ciclo de vida de producto para esos despliegues. Kubernetes no es un requisito de todas las instalaciones de AAP.

Semaphore UI puede ejecutarse como binario o paquete nativo en un host existente, además de mediante Docker o Kubernetes. Un equipo que incorpora una interfaz compartida para Ansible puede elegir una instalación convencional en servidor y reutilizar los repositorios y la infraestructura que ya opera. Enterprise añade alta disponibilidad cuando el servicio necesita instancias redundantes de aplicación. El servidor de Semaphore UI también funciona de forma nativa en Windows, mientras que la ejecución de Ansible necesita WSL, un contenedor o un runner Linux.

Semaphore UI puede compartir jobs de aplicación de parches y despliegue desde un servidor existente. La topología de despliegue de AAP depende de los componentes seleccionados y de la capacidad de ejecución que el equipo deba mantener.

AAP utiliza playbooks de Ansible y execution environments, imágenes de contenedor que incluyen Ansible y las dependencias necesarias. Sus integraciones de Terraform incluyen colecciones para coordinar servicios de Terraform, y los playbooks pueden invocar otras herramientas de línea de comandos. Es un modelo coherente cuando Ansible ya orquesta todo el procedimiento.

Semaphore UI también se centra en operaciones prácticas de Ansible, pero ofrece plantillas de tareas propias para Terraform/OpenTofu, Terragrunt, Bash, PowerShell y Python. Para Terraform/OpenTofu, el ingeniero selecciona en la interfaz el repositorio, el directorio de configuración, el workspace y el grupo de variables. La herramienta de IaC se ejecuta directamente, sin un playbook de Ansible escrito solo para invocarla. Así, un despliegue de Ansible, un job de aprovisionamiento de Terraform y una tarea de verificación de Python pueden compartir proyecto conservando sus propios ajustes de ejecución.

Por ejemplo, un entorno temporal de pruebas puede necesitar crear infraestructura, configurar la aplicación y comprobar que está lista. Semaphore UI mantiene esos pasos en sus herramientas existentes y los conecta mediante un workflow. Esto resulta útil para equipos cuya automatización ha crecido entre varios repositorios y lenguajes, pero que quieren un único lugar donde iniciar y revisar la operación.

Hay que configurar direcciones de estado/backend separadas o workspaces compatibles para desarrollo, preproducción y producción. La compatibilidad con workspaces depende del backend seleccionado. Semaphore UI Pro puede alojar ese estado mediante su backend HTTP incorporado, con historial de versiones y gestión desde la interfaz. Para un equipo que crea entornos temporales, la plantilla de aprovisionamiento, su estado y la configuración posterior de Ansible permanecen en el mismo servicio. Las integraciones documentadas de Terraform de AAP utilizan servicios de Terraform o un backend externo configurado para el estado. Semaphore UI también puede conservar un backend externo si el equipo ya dispone de uno.

Si el proceso debe aprobar y aplicar exactamente un plan Terraform guardado, configure su almacenamiento y reutilización de forma explícita. La ejecución predeterminada de Semaphore UI separa plan y apply, y sus comandos utilizan -lock=false salvo que se modifiquen. Disponer de un backend de estado no cambia esos ajustes de comandos.

Una Job Template de AAP guarda el proyecto, el playbook, el inventario, las credenciales y el execution environment de una operación. Iniciarla crea un job. Un formulario recoge los parámetros habilitados para ese lanzamiento, de modo que el operador puede ejecutar un procedimiento preparado sin reconstruir su configuración.

Semaphore UI utiliza Task Templates para el mismo patrón de lanzamiento reutilizable en Ansible y sus demás herramientas de automatización. Una plantilla de Ansible selecciona el repositorio, el playbook, el inventario y las credenciales. Los grupos de variables con nombre contienen configuración reutilizada entre plantillas, mientras los campos de formulario recogen los valores necesarios para cada ejecución. AAP puede reutilizar variables mediante inventarios y archivos en Git.

Por ejemplo, en un procedimiento de reinicio de servicios compartido con soporte, el ingeniero prepara el playbook y la configuración del entorno, y solicita el nombre del servicio y la referencia del cambio en el formulario de lanzamiento. El compañero selecciona la operación, introduce esos datos y puede seguir su estado y su salida. Otras plantillas pueden ofrecer un despliegue, una copia de seguridad o una renovación de certificados utilizando los mismos recursos del proyecto.

Ambos productos también programan plantillas guardadas. AAP ofrece programaciones únicas y periódicas, mientras que Semaphore UI admite expresiones cron y ejecuciones únicas con parámetros configurados. La copia de seguridad utilizada antes de una ventana de mantenimiento manual también puede ejecutarse por la noche según una programación. Así se reutiliza el procedimiento operativo sin mantener por separado un comando cron y la configuración de lanzamiento web.

AAP sincroniza las fuentes de inventario con hosts y grupos gestionados, con facts almacenados e inventarios construidos para operaciones de Ansible más complejas. El operador puede inspeccionar y gestionar la información de cada host en la misma plataforma donde inicia jobs. Esto resulta útil cuando mantener esos registros y combinar fuentes de inventario forma parte del trabajo diario. AAP puede actualizar las fuentes de inventario mediante una programación o antes del lanzamiento, y conservar opcionalmente los facts de hosts en una caché gestionada.

Semaphore UI reutiliza definiciones de inventario estáticas o de Git y plugins de descubrimiento de Ansible, incluidos los de NetBox y las API de la nube. Los operadores pueden editar definiciones INI/YAML en la interfaz o mantener Git y el descubrimiento externo como origen de la información de hosts. La plantilla selecciona el inventario que necesita al ejecutar la operación. El descubrimiento dinámico se realiza durante la ejecución. Sigue disponible la caché de facts configurada en Ansible, mientras que Semaphore UI no proporciona una caché de facts gestionada por el controlador.

Para un equipo que ya mantiene su infraestructura fuera de la interfaz de automatización, esto evita introducir un segundo proceso de gestión de hosts solo para compartir jobs. El mismo inventario puede servir para aplicar parches, comprobar certificados y desplegar, con plantillas y parámetros separados para cada operación. La vista sincronizada de hosts y grupos de AAP sigue aportando valor cuando los operadores necesitan esa representación gestionada, no solo un inventario sobre el que ejecutar.

Ambos productos guardan referencias a credenciales junto a la operación preparada. Un ingeniero puede configurar una vez el acceso al repositorio, las credenciales de máquinas y otros secretos, y reutilizarlos en despliegues y jobs de mantenimiento. Quienes inician la operación no necesitan volver a proporcionar esas credenciales en cada ejecución.

AAP admite objetos de credenciales y consultas de secretos externos, incluidas integraciones con HashiCorp Vault, AWS Secrets Manager, Azure y CyberArk. Semaphore UI ofrece un almacén de claves de proyecto y conecta HashiCorp Vault u OpenBao en Pro. Enterprise añade AWS Secrets Manager, Azure Key Vault, Devolutions Server y CyberArk mediante su API PVWA. AAP puede utilizar la colección Ansible de Devolutions dentro de playbooks si está instalada en el execution environment. Sus conectores incorporados de credenciales no incluyen una consulta específica de OpenBao. AAP también ofrece conectores para Centrify Vault y Thycotic Secret Server o DevOps Secrets Vault, que Semaphore UI no expone como almacenes incorporados. Cuando no existe un conector de plataforma, una colección de consulta de Ansible o un comando pueden recuperar secretos para una operación, con esa integración mantenida en la automatización. Por tanto, la elección puede basarse en el almacén de secretos existente y en las conexiones que el equipo quiere configurar en la propia plataforma.

AAP ejecuta jobs en execution environments que incluyen Ansible y las dependencias del playbook. Los nodos de ejecución realizan el trabajo separados de los servicios de control. Automation mesh conecta esos nodos y puede utilizar nodos de salto intermedios para alcanzar redes remotas. Esto sirve a una infraestructura distribuida de Ansible con imágenes de ejecución y rutas de red definidas.

Semaphore UI puede ejecutar automatización en su servidor o en runners situados cerca de los sistemas de destino. Por ejemplo, un runner dentro de una red privada puede ejecutar un job de mantenimiento con Ansible sobre sus hosts locales mientras la interfaz compartida permanece en otra ubicación. Los runners globales están disponibles en Community, y Pro añade runners asignados a proyectos y enrutamiento por etiquetas para distintos entornos de ejecución.

Un equipo puede empezar con ejecución directa y añadir máquinas separadas o contenedores por tarea cuando sus cargas de trabajo lo necesiten. Pro proporciona ejecución de tareas en Docker y Enterprise añade ejecución en Kubernetes. Esto permite pasar de un único host a una ejecución separada para los playbooks existentes sin exigir un despliegue de automation mesh. Poner el servidor de la aplicación en un contenedor es una decisión distinta de contenerizar cada tarea.

Las Workflow Job Templates de AAP conectan Job Templates, actualizaciones de proyectos, actualizaciones de inventarios y otros workflows. Los pasos de aprobación pausan la ejecución y los valores set_stats de Ansible pueden transmitirse a jobs posteriores. Insertar un workflow resulta útil cuando varios procedimientos comparten una secuencia completa que debe mantenerse una sola vez.

Los workflows de Semaphore UI conectan directamente plantillas de tareas de Ansible, Terraform/OpenTofu, Terragrunt, Bash, PowerShell y Python, con ramas de éxito y fallo, aprobaciones y esperas. Un workflow de aprovisionamiento puede crear infraestructura con Terraform/OpenTofu, configurarla con Ansible y comprobar su disponibilidad con Python. Un workflow de mantenimiento puede empezar por una copia de seguridad, aplicar actualizaciones y realizar verificaciones, reutilizando plantillas que los compañeros también pueden ejecutar por separado. AAP puede orquestar el mismo procedimiento mediante Job Templates de Ansible e integraciones de Terraform. La diferencia está en si la configuración de ejecución de cada herramienta vive en su propia plantilla o en los playbooks e integraciones que hay detrás de los jobs de Ansible.

Semaphore UI 2.20 transmite valores set_stats de Ansible, salidas de Terraform/OpenTofu/Terragrunt y JSON de Bash, PowerShell o Python a los parámetros de tareas posteriores. Así, una dirección o un identificador de recurso devueltos por el aprovisionamiento pueden convertirse en un parámetro de la siguiente operación. AAP transmite valores set_stats entre jobs de Ansible. Ambos ofrecen una transmisión útil de valores, con diferencias en cómo se produce y consume el resultado. La plantilla receptora declara el parámetro, que su playbook o configuración de inventario utiliza después para dirigirse al nuevo host.

AAP ofrece un permiso Approve asignable para aprobar workflows. Semaphore UI 2.20 vincula la aprobación al permiso para ejecutar tareas del proyecto. Se ha anunciado un rol de aprobador independiente para 2.21.0. Esto importa cuando la responsabilidad de aprobar necesita un permiso propio.

Un workflow de aprovisionamiento y configuración puede transmitir valores recopilados entre tareas de Semaphore UI mediante el ejecutor local, en el servidor o en un runner remoto. Los ejecutores Docker y Kubernetes no recopilan esas salidas, por lo que un workflow que dependa de ellas necesita otra disposición de ejecución. Las plantillas individuales siguen siendo reutilizables entre workflows. Si varios procedimientos necesitan reutilizar un workflow completo de varios pasos, los workflows anidados de AAP evitan mantener esas secuencias por separado. En ambas plataformas, archivos como los planes guardados de Terraform requieren almacenamiento accesible o una transferencia explícita entre jobs.

AAP concede acceso a recursos individuales y admite roles personalizados. Los operadores pueden recibir permisos para utilizar inventarios y credenciales concretos independientemente de las plantillas de jobs. Esto encaja con equipos cuyo trabajo diario incluye combinar recursos autorizados de Ansible en operaciones nuevas.

Semaphore UI organiza el acceso en torno a proyectos y operaciones preparadas. Los roles de proyecto de Community ya permiten separar a los ingenieros que mantienen la automatización de los compañeros que la ejecutan. Un proyecto puede reunir las plantillas de despliegue, copias de seguridad y mantenimiento de un equipo junto con sus recursos configurados.

Enterprise añade roles personalizados y permisos de ejecución por plantilla cuando el acceso debe limitarse a operaciones concretas. Por ejemplo, el personal de soporte puede recibir acceso a una plantilla de reinicio de servicios mientras el despliegue queda en manos de otro rol. El inventario, las credenciales y las opciones de sobrescritura habilitadas al iniciar forman parte de la configuración preparada. Es un modelo centrado en delegar operaciones, mientras que AAP ofrece permisos independientes sobre los recursos subyacentes.

Ambos admiten integración LDAP. Semaphore UI Pro también ofrece autenticación OIDC, mientras que AAP admite OIDC, SAML y otros proveedores de identidad configurados centralmente. Semaphore UI no proporciona una integración SAML incorporada. Semaphore UI Pro también añade autenticación de dos factores TOTP para cuentas locales.

Los resultados operativos son lo primero cuando un compañero necesita saber si terminó un despliegue o un job de mantenimiento. Ambos productos conservan la salida y el historial de ejecución. Semaphore UI registra el estado de la tarea, la revisión del repositorio y los detalles de lanzamiento, y Pro añade un resumen de hosts de Ansible que muestra las tareas fallidas de cada servidor. Tras un job de parches o certificados, el operador puede identificar los hosts afectados e inspeccionar la salida correspondiente.

La auditoría administrativa tiene otro fin. El flujo de actividad de AAP registra cambios en recursos de la plataforma y sus integraciones de logging reenvían eventos de jobs y del sistema. Semaphore UI ofrece un log de auditoría para administradores que recoge inicios de sesión, cambios de permisos y otras acciones registradas. Pro añade filtros, exportación a archivos y reenvío mediante TLS Syslog o Splunk HEC para incorporar esos eventos a las investigaciones de seguridad y los registros SIEM de la organización.

Automation hub de AAP distribuye colecciones e imágenes de ejecución y ofrece acceso a contenido Red Hat Certified y validado. Event-Driven Ansible evalúa eventos mediante rulebooks y activa automatizaciones. Son servicios de plataforma para gestionar e iniciar automatización en toda una organización, más allá de un webhook entrante para un job guardado.

Semaphore UI se integra con los sistemas existentes de CI, monitorización y solicitudes mediante su API REST e integraciones de webhooks con reglas de coincidencia y extracción de parámetros. Un pipeline de compilación puede publicar una versión y solicitar un despliegue preparado, mientras un procesador de eventos puede solicitar una operación de diagnóstico. Semaphore UI conserva el inventario, las credenciales y el registro de ejecución de esa operación. El sistema que llama gestiona la autenticación y comprueba el resultado cuando el proceso que lo rodea necesita esperar a su finalización.

Tanto Semaphore UI como automation controller ofrecen formularios de lanzamiento para jobs preparados. AAP también ofrece un Ansible automation portal desplegado por separado y basado en Red Hat Developer Hub, con un catálogo de autoservicio, sincronización de plantillas e integraciones personalizadas. El uso de Developer Hub para ese portal está incluido en la suscripción de AAP. Para los equipos que necesitan compartir ejecuciones de jobs sin ese catálogo, Semaphore UI proporciona una interfaz centrada en Ansible y otras herramientas de automatización.

AAP ofrece un servidor MCP oficial que expone operaciones de la plataforma a asistentes compatibles. Puede desplegarse con la plataforma o como contenedor independiente. AAP también proporciona en su interfaz un asistente inteligente de automatización opcional, conectado a un proveedor de modelos configurado. Esto extiende su enfoque de plataforma integrada a las operaciones asistidas por IA.

Semaphore UI dispone de un conector MCP de la comunidad para su API y ha anunciado soporte MCP oficial para Pro en la versión 2.21.0. Claude Code o Codex también pueden consultar su documentación pública, código fuente y definiciones de API para ayudar a preparar plantillas, escribir integraciones o investigar una ejecución fallida a partir de la configuración y la salida proporcionadas. Un equipo puede utilizar esa ayuda junto a su servicio de automatización existente sin adoptar una plataforma más amplia.