Interfaz de Terraform: Semaphore UI vs Gaia

Gaia separa su aplicación web Java, su base de datos MongoDB y su runner de ejecución. El runner inicia Terraform en contenedores Docker o pods de Kubernetes, con un límite configurable de jobs paralelos. Docker Compose reúne estos servicios, mientras que un chart Helm experimental ofrece una opción de instalación en Kubernetes.

Semaphore UI se ejecuta como binario o paquete nativo, además de Docker o Kubernetes. Un equipo que traslada la automatización rutinaria desde los portátiles de los ingenieros puede empezar en un servidor existente y utilizar el mismo servicio para el aprovisionamiento con Terraform y el mantenimiento con Ansible. El modo de ejecución seleccionado determina si hacen falta contenedores para los jobs.

Gaia ejecuta módulos de Terraform mediante una secuencia generada de comandos de Terraform. Los provisioners de Terraform pueden invocar Ansible o programas de línea de comandos cuando la imagen del runner o el destino remoto dispone de las herramientas necesarias. Esto permite configurar un recurso recién aprovisionado, pero el comando permanece vinculado a una ejecución de Terraform y no se convierte en una operación independiente de Gaia. Su generación estándar de comandos no ofrece una plantilla separada para OpenTofu o Terragrunt.

Semaphore UI dispone de plantillas directas para Ansible, Terraform/OpenTofu, Terragrunt, Bash, PowerShell y Python. Un equipo puede crear infraestructura con OpenTofu, configurar paquetes con Ansible y ejecutar una comprobación de disponibilidad con Python. Más adelante, la configuración de Ansible o la operación de mantenimiento con PowerShell pueden ejecutarse por separado sin iniciar otro ciclo de vida de Terraform. El backend de estado incorporado de Pro también mantiene el estado de Terraform/OpenTofu y su historial junto a esos jobs.

El autor de un módulo de Gaia define el repositorio de origen, la versión de Terraform y el esquema de variables. Los usuarios crean stacks a partir de ese módulo e introducen los valores y las credenciales de la nube adecuados para su entorno. El stack se convierte en una instancia persistente con su propio estado y jobs, lo que encaja con un catálogo de infraestructura solicitada de forma independiente. Gaia valida los valores obligatorios y las expresiones regulares configurables. Los formularios de Semaphore UI validan campos obligatorios, enteros y opciones, sin una regla configurable de expresiones regulares equivalente.

Semaphore UI denomina plantilla de tareas a la operación guardada. Reúne un repositorio, la configuración de la herramienta, las variables y los inventarios o credenciales que necesita la operación. Los grupos de variables con nombre reutilizan ajustes de entorno entre plantillas, mientras los campos del formulario recogen los parámetros de lanzamiento. Por ejemplo, una plantilla de reinicio de servicios puede ofrecer una selección de servicio y entorno en lugar de pedir al compañero que construya un comando. Una plantilla de aprovisionamiento puede utilizar el mismo patrón para los parámetros del entorno.

Gaia ejecuta plan, apply y destroy sobre el módulo, los parámetros y las credenciales de la nube configurados en un stack. Su backend incorporado conserva el estado de ese stack, mientras su página reúne las salidas y el historial de jobs. Así, distintos entornos de prueba pueden mantener estados y registros de ejecución independientes aunque procedan del mismo módulo.

Semaphore UI utiliza una plantilla de tareas para seleccionar el repositorio, el workspace y la configuración de Terraform/OpenTofu. Los grupos de variables reutilizan ajustes entre jobs relacionados y los formularios recogen parámetros al iniciar. Un ingeniero puede preparar una operación de aprovisionamiento de entorno una vez y permitir después que sus compañeros la soliciten mediante esa configuración guardada. Cada entorno también necesita sus propias variables, credenciales y estado de backend. Gaia los representa como instancias de stack separadas. En Semaphore UI, el equipo prepara la configuración correspondiente de plantilla, workspace y backend. El aislamiento entre workspaces depende del backend, por lo que seleccionar un workspace no separa por sí solo el estado en todos los backends. Terragrunt y OpenTofu son opciones directas de plantilla junto con Terraform.

El estado es una parte separada de esta configuración. Gaia incluye un backend de estado para cada stack sin licencia comercial. Semaphore UI utiliza el backend configurado en el código de Terraform/OpenTofu, y Pro ofrece además un backend HTTP incorporado con historial y gestión desde la interfaz. Mantener ese backend en Semaphore UI sitúa el estado compartido junto a los jobs que lo modifican, en lugar de añadir otro servicio de estado.

Ninguno de los productos aplica por defecto un archivo de plan guardado previamente. Gaia 2.4.0 muestra el resultado de la planificación, pero su comando apply no utiliza el archivo de plan guardado. La ejecución predeterminada de Semaphore UI también planifica y aplica por separado. Si la aprobación debe cubrir el cambio exacto propuesto, el procedimiento necesita almacenar y reutilizar ese plan de forma explícita.

Gaia mantiene los recursos y las salidas de Terraform en cada stack. Una salida de Terraform puede proporcionar la dirección de host que necesita un provisioner u otro sistema, pero no crea un recurso de inventario de Ansible en la interfaz de Gaia. El Ansible invocado mediante un provisioner debe recibir o generar su inventario como parte de esa automatización.

Semaphore UI almacena inventarios de Ansible como recursos reutilizables del proyecto. Los equipos pueden editar una definición estática, utilizar un archivo en Git o dejar que los plugins de inventario de Ansible descubran hosts durante la ejecución de un job. El mismo inventario puede servir para despliegues, aplicación de parches y comprobaciones de certificados. Esto resulta especialmente útil cuando el aprovisionamiento es solo el comienzo del trabajo y los operadores vuelven a una flota existente durante toda su vida útil.

Gaia separa la aplicación de su runner. El runner solicita los pasos pendientes de Terraform y los ejecuta en contenedores Docker o pods de Kubernetes, con concurrencia configurable. Puede funcionar cerca de infraestructura privada siempre que alcance la API de Gaia y los servicios utilizados por el módulo. La imagen seleccionada aporta Terraform y los programas adicionales que requieren los provisioners.

Semaphore UI puede ejecutar jobs en el servidor de la aplicación o en runners situados cerca de los destinos. Esto permite que una instalación pequeña empiece sin una plataforma de contenedores y que una más grande acceda a redes separadas mediante runners. Pro añade runners de proyecto y ejecución de jobs en Docker, mientras que Enterprise añade pods de jobs en Kubernetes. Instalar la aplicación web en Docker y ejecutar cada job en su propio contenedor siguen siendo decisiones independientes.

Semaphore UI guarda programaciones cron y de una sola ejecución vinculadas a plantillas preparadas. Una copia de seguridad nocturna, una comprobación periódica de certificados o un job de aplicación de parches pueden reutilizar el inventario, las credenciales y los ajustes de lanzamiento elegidos por el autor. Las ejecuciones manuales y programadas aparecen después en el mismo historial.

Gaia 2.4.0 no incluye una interfaz de programación. Un programador externo puede crear un job RUN o DESTROY mediante POST /api/stacks/{id}/{jobType} e iniciar después su plan mediante POST /api/jobs/{jobId}/plan. La aplicación del cambio requiere un POST separado a /api/jobs/{jobId}/apply cuando termina el plan. El programador debe gestionar ese ciclo de vida e inspeccionar el resultado final del job, sin interpretar la creación de un ID de job como una ejecución completada.

Gaia guía un stack por la planificación y la aplicación. Su interfaz ofrece una confirmación separada después del plan, también para destruir un stack. Los provisioners de Terraform pueden realizar otras acciones dentro de ese ciclo de vida y un sistema externo puede coordinar varios jobs mediante la API. Gaia no proporciona un grafo visual de operaciones de Ansible, Terraform y scripts reutilizables de forma independiente.

Semaphore UI conecta plantillas guardadas mediante un workflow visual, con aprobaciones y rutas de éxito y fallo. Un despliegue puede aprovisionar infraestructura, esperar una aprobación, configurar hosts y ejecutar una verificación, mientras cada plantilla sigue disponible para el mantenimiento posterior. Los valores recopilados pueden transmitirse entre pasos mediante el ejecutor local del servidor o de un runner. Los archivos generados y los planes guardados de Terraform siguen necesitando almacenamiento accesible o una transferencia explícita. Ninguno de los productos aplica por defecto un plan de Terraform guardado previamente.

Gaia utiliza organizaciones para compartir módulos, con roles de administrador y usuario. El autor de un módulo puede poner una definición aprobada de Terraform a disposición de un equipo, mientras los usuarios aportan la configuración de sus propios stacks. Las integraciones con GitHub y GitLab combinan autenticación OAuth2 e importación de repositorios, y también se admite LDAP.

Semaphore UI Community organiza la automatización compartida en proyectos. Los roles de proyecto controlan quién puede ver, ejecutar o editar la automatización del proyecto. Los compañeros con permisos de ejecución pueden iniciar un despliegue, una copia de seguridad o un job de mantenimiento y revisar el resultado. El ingeniero prepara la operación, mientras el compañero utiliza su configuración guardada y sus parámetros de lanzamiento.

Enterprise añade roles personalizados y permisos de ejecución por plantilla cuando el acceso debe limitarse a determinadas operaciones. Por ejemplo, un equipo puede delegar una plantilla de reinicio de servicios sin conceder al operador permisos generales de edición del proyecto. Ese límite resulta de la combinación de los permisos del rol y la configuración de la operación, no solo del formulario. Pro añade autenticación LDAP y OIDC para los equipos que utilizan un proveedor de identidad central. Semaphore UI Pro también incorpora autenticación de dos factores TOTP para cuentas locales.

Gaia proporciona credenciales de la nube para AWS, Google Cloud y Azure. Su integración opcional con Vault utiliza el motor Transit para el cifrado y puede solicitar credenciales dinámicas de AWS a un motor de secretos de Vault. Estas credenciales sirven al ciclo de vida del stack de Terraform.

El almacén de claves de Semaphore UI admite las credenciales utilizadas en los procedimientos del equipo, incluidas las claves SSH y las contraseñas para hosts de Ansible. Una operación preparada referencia esas entradas almacenadas en lugar de exigir que el operador pegue las credenciales en cada lanzamiento. Pro añade consulta de secretos en HashiCorp Vault y OpenBao, mientras que Enterprise incorpora integraciones con AWS Secrets Manager, Azure Key Vault y Devolutions Server, además de CyberArk mediante su API PVWA.

Por ejemplo, un entorno puede utilizar una credencial de la nube para el aprovisionamiento y una clave SSH para la configuración posterior con Ansible. Siguen siendo credenciales distintas asociadas a la operación correspondiente. Ambas plataformas pueden trabajar con Vault, pero las funciones de cifrado y credenciales dinámicas de Gaia son distintas de consultar un secreto almacenado para un job. Los tipos de credenciales incorporados de Gaia no incluyen conectores para los demás almacenes de secretos citados. El código de Terraform puede recuperar secretos mediante sus propias fuentes de datos o comandos externos, con esa consulta configurada y mantenida en la automatización en lugar de la interfaz de credenciales de Gaia.

Gaia registra el usuario, el estado, los tiempos y los pasos plan/apply de un job de stack. Ese historial permite inspeccionar los cambios de aprovisionamiento de un entorno e investigar la salida de Terraform. Es un registro de operaciones de stacks, no una interfaz de informes de hosts de Ansible o de auditoría administrativa.

Semaphore UI conserva el historial de tareas de todas las herramientas compatibles. Los resúmenes de Ansible de Pro añaden resultados de hosts y tareas para identificar qué servidores fallaron al aplicar un parche o comprobar certificados. Su log de auditoría registra inicios de sesión y acciones administrativas compatibles por separado de la salida de tareas. Así, un equipo que realiza tanto aprovisionamiento como mantenimiento de hosts puede investigar esas operaciones en el mismo servicio sin tratar el estado de Terraform como un informe de todas las acciones realizadas en un servidor. Pro añade filtrado y exportación de auditoría, incluido el envío mediante Syslog y Splunk HEC para el sistema SIEM del equipo.

Gaia importa módulos de GitHub o GitLab y expone API para stacks, jobs y resultados. Un pipeline de CI o un servicio externo de solicitudes puede crear un job de stack, iniciar la planificación y decidir cuándo aplicarlo. Una configuración basada en webhooks necesita un adaptador que realice esas llamadas y siga el resultado. Semaphore UI ofrece una API REST y webhooks de integración entrantes que reconocen solicitudes y asignan sus valores a los parámetros de tareas preparadas.

Si el equipo conserva el catálogo de Terraform de Gaia, una integración mediante API puede activar una plantilla de configuración o mantenimiento con Ansible en Semaphore UI al terminar el aprovisionamiento. Semaphore UI gestiona entonces el inventario, las credenciales y el registro de ejecución de esa operación. Es una conexión implementada por el equipo, no una integración incorporada entre Gaia y Semaphore UI. Ambos proyectos también publican documentación y código fuente que un asistente de programación puede consultar al preparar esa conexión o investigar la configuración y la salida de los jobs.