Terraform UI: Semaphore UI vs Gaia

O Gaia separa sua aplicação web Java, banco MongoDB e runner. O runner inicia Terraform em contêineres Docker ou pods Kubernetes, com limite configurável de jobs paralelos. O Docker Compose reúne esses serviços, enquanto um chart Helm experimental oferece instalação em Kubernetes.

O Semaphore UI executa como binário ou pacote nativo, além de Docker ou Kubernetes. Uma equipe que tira a automação rotineira dos notebooks dos engenheiros pode começar em um servidor existente e usar o mesmo serviço para provisionamento Terraform e manutenção Ansible. O modo de execução escolhido determina se contêineres de jobs são necessários.

O Gaia executa módulos Terraform por uma sequência gerada de comandos Terraform. Provisioners do Terraform chamam Ansible ou programas de linha de comando quando a imagem do runner ou o destino remoto fornece as ferramentas necessárias. Isso configura um recurso recém-provisionado, mas o comando permanece ligado a uma execução Terraform, sem se tornar uma operação Gaia independente. A construção padrão dos comandos não fornece um modelo separado de OpenTofu ou Terragrunt.

O Semaphore UI tem modelos diretos para Ansible, Terraform/OpenTofu, Terragrunt, Bash, PowerShell e Python. Uma equipe cria infraestrutura com OpenTofu, configura pacotes com Ansible e executa uma verificação de prontidão Python. Depois, a configuração Ansible ou manutenção PowerShell pode executar isoladamente, sem iniciar outro ciclo Terraform. O backend de state integrado do Pro também mantém state Terraform/OpenTofu e seu histórico junto a esses jobs.

O autor de um módulo Gaia define repositório de origem, versão do Terraform e esquema de variáveis. Usuários criam stacks a partir dele e fornecem valores e credencial de nuvem adequados ao ambiente. A stack se torna uma instância durável com state e jobs próprios, adequada a um catálogo de infraestrutura solicitada independentemente. O Gaia valida valores obrigatórios e expressões regulares configuráveis. Formulários do Semaphore UI validam campos obrigatórios, inteiros e escolhas, sem regra regex configurável equivalente.

O Semaphore UI chama a operação salva de Task Template. Ele reúne repositório, configuração da ferramenta, variáveis e os inventários ou credenciais necessários. Variable Groups nomeados reutilizam configurações de ambiente entre modelos, enquanto campos de formulário coletam entradas. Por exemplo, um modelo de reinicialização pode oferecer escolhas de serviço e ambiente em vez de pedir ao colega que construa um comando. Um modelo de provisionamento pode usar o mesmo padrão para parâmetros de ambiente.

O Gaia executa plan, apply e destroy com módulo, entradas e credenciais de nuvem configurados na stack. Seu backend integrado mantém o state da stack, enquanto a página da stack reúne outputs e histórico de jobs. Assim, ambientes separados de testes mantêm state e registros independentes mesmo quando vêm do mesmo módulo.

O Semaphore UI usa um Task Template para selecionar repositório, workspace e configuração Terraform/OpenTofu. Variable Groups reutilizam configurações entre jobs relacionados, e formulários coletam entradas ao iniciar. Um engenheiro prepara uma operação de provisionamento de ambiente uma vez e permite que colegas a solicitem por essa configuração salva. Cada ambiente também precisa de variáveis, credenciais e state de backend próprios. O Gaia os representa como instâncias separadas de stacks. No Semaphore UI, a equipe prepara a configuração correspondente de modelo, workspace e backend. O isolamento por workspace depende do backend, portanto selecionar um workspace não separa o state em todo backend. Terragrunt e OpenTofu são opções diretas de modelos, ao lado do Terraform.

O state é uma parte separada da configuração. O Gaia inclui um backend de state por stack sem licença comercial. O Semaphore UI usa o backend configurado no código Terraform/OpenTofu, e o Pro também fornece backend HTTP integrado com histórico e gestão pela interface. Manter esse backend no Semaphore UI coloca o state compartilhado junto aos jobs que o alteram, em vez de acrescentar outro serviço de state.

Nenhum produto aplica por padrão um arquivo de plano salvo anteriormente. O Gaia 2.4.0 mostra o resultado do planejamento, mas seu comando apply não usa o arquivo de plano salvo. A execução padrão do Semaphore UI também faz plan e apply separadamente. Se a aprovação deve abranger exatamente a mudança proposta, o procedimento precisa armazenar e reutilizar esse plano explicitamente.

O Gaia mantém recursos Terraform e outputs em cada stack. Um output Terraform fornece o endereço de host necessário a um provisioner ou outro sistema, mas não cria um recurso de inventário Ansible na interface Gaia. Ansible chamado por um provisioner precisa receber ou gerar seu inventário nessa automação.

O Semaphore UI armazena inventários Ansible como recursos reutilizáveis do projeto. A equipe edita uma definição estática, usa um arquivo Git ou deixa plugins de inventário Ansible descobrirem hosts durante a execução. O mesmo inventário atende a implantação, patches e verificações de certificados. Isso é especialmente útil quando provisionar é só o começo e operadores voltam a um parque existente durante sua vida.

O Gaia separa a aplicação do runner. O runner solicita etapas Terraform pendentes e as executa em contêineres Docker ou pods Kubernetes, com concorrência configurável. Pode ficar próximo à infraestrutura privada desde que alcance a API Gaia e os serviços usados pelo módulo. A imagem selecionada fornece Terraform e programas adicionais exigidos pelos provisioners.

O Semaphore UI executa jobs no servidor da aplicação ou em runners próximos aos destinos. Isso permite começar sem plataforma de contêineres em uma instalação pequena e alcançar redes separadas por runners em uma maior. O Pro acrescenta runners de projeto e execução Docker de jobs, enquanto o Enterprise acrescenta pods Kubernetes. Instalar a aplicação web no Docker e executar cada job em um contêiner próprio continuam sendo escolhas separadas.

O Semaphore UI salva agendamentos cron e únicos em modelos preparados. Backup noturno, verificação recorrente de certificados ou patches reutilizam inventário, credenciais e configurações escolhidos pelo autor. Execuções manuais e agendadas aparecem no mesmo histórico.

O Gaia 2.4.0 não inclui interface de agendamento. Um agendador externo cria um job RUN ou DESTROY por POST /api/stacks/{id}/{jobType} e inicia o plan por POST /api/jobs/{jobId}/plan. Aplicar a mudança exige outro POST para /api/jobs/{jobId}/apply após concluir o plan. O agendador precisa tratar esse ciclo e consultar o resultado final, sem considerar a criação de um identificador de job como execução concluída.

O Gaia conduz uma stack pelo planejamento e aplicação. Sua interface oferece confirmação separada após o plan, inclusive para destruir uma stack. Provisioners Terraform realizam outras ações dentro desse ciclo, e um sistema externo coordena vários jobs pela API. O Gaia não fornece um grafo visual de operações Ansible, Terraform e scripts reutilizáveis independentemente.

O Semaphore UI conecta modelos salvos por um workflow visual, com aprovação e caminhos de sucesso e falha. Uma implantação pode provisionar infraestrutura, aguardar aprovação, configurar hosts e executar verificação, enquanto cada modelo permanece disponível para manutenção posterior. Valores coletados passam entre etapas pelo executor local no servidor ou runner. Arquivos gerados e planos Terraform salvos ainda precisam de armazenamento acessível ou transferência explícita. Nenhum produto aplica um plano Terraform salvo anteriormente por padrão.

O Gaia usa organizações para compartilhar módulos, com funções de administrador e usuário. O autor disponibiliza uma definição Terraform aprovada à equipe, enquanto usuários fornecem a configuração das próprias stacks. Integrações GitHub e GitLab combinam login OAuth2 com importação de repositórios, e LDAP também é suportado.

O Semaphore UI Community organiza a automação compartilhada em projetos. Funções controlam quem pode visualizar, executar ou editar automações no projeto. Colegas com permissão de execução iniciam implantações, backups ou manutenção e consultam os resultados. O engenheiro prepara a operação, enquanto o colega usa a configuração salva e as entradas de execução.

O Enterprise acrescenta funções personalizadas e permissões de execução por modelo quando o acesso deve se limitar a operações selecionadas. Por exemplo, uma equipe pode delegar um modelo de reinicialização de serviço sem dar ao operador direitos gerais de edição do projeto. Esse limite decorre das permissões de função e da configuração da operação em conjunto, não apenas do formulário. O Pro acrescenta login LDAP e OIDC para equipes que usam um provedor central de identidade. O Semaphore UI Pro também acrescenta autenticação de dois fatores por TOTP para contas locais.

O Gaia fornece credenciais de nuvem para AWS, Google Cloud e Azure. Sua integração opcional com Vault usa o mecanismo Transit para criptografia e pode solicitar credenciais AWS dinâmicas a um mecanismo de segredos do Vault. Essas credenciais atendem ao ciclo de vida da stack Terraform.

O Key Store do Semaphore UI oferece as credenciais usadas nos procedimentos da equipe, incluindo chaves SSH e senhas de hosts Ansible. Uma operação preparada referencia essas entradas salvas em vez de exigir que o operador cole credenciais a cada execução. O Pro acrescenta consultas de segredos ao HashiCorp Vault e OpenBao, enquanto o Enterprise acrescenta integrações com AWS Secrets Manager, Azure Key Vault e Devolutions Server, além de CyberArk pela API PVWA.

Por exemplo, um ambiente pode usar uma credencial de nuvem no provisionamento e uma chave SSH na configuração Ansible posterior. Elas permanecem como credenciais separadas associadas à operação correspondente. As duas plataformas podem trabalhar com Vault, mas os recursos de criptografia e credenciais dinâmicas do Gaia diferem da consulta de um segredo armazenado para um job. Os tipos de credenciais integrados do Gaia não incluem conectores para os demais armazenamentos de segredos listados acima. O código Terraform pode recuperar segredos por suas próprias fontes de dados ou comandos externos, com essa consulta configurada e mantida na automação, e não na interface de credenciais do Gaia.

O Gaia registra usuário, status, duração e etapas de plan/apply de um job da stack. Esse histórico ajuda a equipe a consultar mudanças de provisionamento do ambiente e investigar a saída do Terraform. É um registro de operações de stacks, e não uma interface de relatórios de hosts Ansible ou auditoria administrativa.

O Semaphore UI mantém o histórico de tarefas das ferramentas suportadas. Os resumos Ansible do Pro acrescentam resultados de hosts e tarefas, ajudando o operador a identificar quais servidores falharam em uma verificação de patches ou certificados. Seu log de auditoria registra logins e ações administrativas suportadas separadamente da saída das tarefas. Assim, uma equipe que executa provisionamento e manutenção de hosts pode investigar essas operações no mesmo serviço, sem tratar o state do Terraform como relatório de toda ação em um servidor. O Pro acrescenta filtros e exportação de auditoria, incluindo entrega via Syslog e Splunk HEC para o pipeline SIEM da equipe.

O Gaia importa módulos do GitHub ou GitLab e expõe APIs para stacks, jobs e resultados. Um pipeline CI ou serviço externo de solicitações pode criar um job de stack, iniciar o planejamento e decidir quando aplicá-lo. Uma configuração acionada por webhook precisa de um adaptador que faça essas chamadas e acompanhe o resultado. O Semaphore UI fornece uma API REST e webhooks de integração de entrada que identificam solicitações e mapeiam valores para entradas de tarefas preparadas.

Para uma equipe que mantém o catálogo Terraform do Gaia, uma integração via API pode acionar um modelo de configuração ou manutenção Ansible no Semaphore UI após concluir o provisionamento. O Semaphore UI passa a gerenciar inventário, credenciais e registro de execução dessa operação. A equipe implementa essa conexão, que não é uma integração nativa Gaia–Semaphore. Os dois projetos também disponibilizam documentação e código-fonte que um assistente de programação pode consultar ao elaborar essa conexão ou investigar configurações e saídas de jobs.