Interface do Ansible: AWX vs Semaphore UI

Denis GukovFundador e CTO do Semaphore UI
18 min de leitura

AWX e Semaphore UI oferecem interfaces web e APIs para executar automações em equipe. Esta comparação abrange o AWX 24.6.1 e o Semaphore UI 2.20.0, das ferramentas compatíveis e opções de implantação aos workflows, controle de acesso e manutenção contínua.

Converse sobre este artigo com IA

Visão geral

Um playbook do Ansible pode começar como um comando que um engenheiro executa no notebook. À medida que implantações, aplicação de patches e renovação de certificados passam a ser responsabilidades compartilhadas, a equipe precisa de um local comum para iniciar essas tarefas, fornecer entradas, gerenciar credenciais e consultar resultados. AWX e Semaphore UI oferecem essa camada compartilhada, com configurações de tarefas salvas, agendamentos, permissões e histórico de execução.

O AWX organiza a automação em torno do Ansible. As equipes associam playbooks armazenados no Git a inventários e credenciais, salvam essas configurações como modelos de job e combinam jobs em workflows. Organizações, equipes e permissões determinam quem pode usar cada recurso. O AWX é um projeto de código aberto, enquanto o Red Hat Ansible Automation Platform (AAP) é uma oferta comercial separada, com suporte e ciclo de vida próprios.

O Semaphore UI também se baseia em tarefas reutilizáveis, com playbooks do Ansible e modelos específicos para Terraform/OpenTofu, Terragrunt, Bash, PowerShell e Python. Os projetos reúnem esses modelos, repositórios, inventários, credenciais e variáveis. Um workflow pode conectar o provisionamento de infraestrutura como código (IaC) à configuração dos hosts e à manutenção posterior, concentrando as operações dessas ferramentas em uma única interface.

Modelos de tarefas do Semaphore UI para Ansible, OpenTofu, Terragrunt, Bash e PowerShell em um projeto.
Semaphore UI. Ferramentas de automação diferentes compartilham a lista de modelos do projeto, com colunas configuráveis.
Lista de modelos do AWX com modelos de job do Ansible e modelos de workflow reutilizáveis em uma organização.
AWX. Modelos de job e de workflow do Ansible compartilham uma lista com controles de organização e execução.

Comparação rápida

Jobs salvos, credenciais e agendamentos atendem às operações rotineiras do Ansible nos dois produtos. As diferenças mais amplas estão na variedade de ferramentas, na implantação e na gestão de recursos. Estas são as principais características de cada um.

Ferramentas de automação, instalação, execução, workflows, inventários, controle de acesso, credenciais, variáveis, licença
Critérios Semaphore UI AWX
Ferramentas de automação Ansible, Terraform/OpenTofu, Terragrunt, Bash, PowerShell, Python AnsibleOutras ferramentas por meio de playbooks
Instalação Binário, pacotes, Docker, Kubernetes Kubernetes (Operator), Docker (desenvolvimento/testes)
Plataformas do servidor Linux, macOS, Windows, FreeBSD Contêineres Linux (Kubernetes / Docker)
Execução de tarefas No servidor ou em máquinas remotas de execução Em servidores de execução ou pods de jobs no Kubernetes
Workflows Sim, workflows visuais entre ferramentas de automação Sim, workflows visuais do Ansible com subworkflows reutilizáveis
Agendamento Expressões cron, execuções únicas Agendamentos únicos e recorrentes
Gestão de inventários Inventários estáticos e no Git, plugins dinâmicos, NetBox e outras fontes externas Inventários estáticos e dinâmicos, atualizações gerenciadas, inventários construídos
Controle de acesso RBAC, funções de projeto, funções personalizadas, permissões de modelosLDAP, OIDC, TOTP local RBAC, funções de organização e equipe, permissões por recursoLDAP, OIDC, SAML, MFA por meio de um provedor de identidade
Credenciais Key Store, chaves SSH, senhas, integrações com cofres externos Objetos de credenciais, chaves SSH, senhas, integrações com cofres externos
Variáveis Grupos de variáveis reutilizáveis, variáveis extras, variáveis de ambiente, formulários de entrada Variáveis de inventário, host e grupo, variáveis extras, formulários de entrada
Licença MIT (Community)Condições comerciais separadas para as edições pagas Apache 2.0

Para jobs rotineiros do Ansible, ambos oferecem execução, agendamento e histórico. As principais diferenças estão na gestão de inventários e permissões, nas ferramentas que executam diretamente e nas opções de implantação.

Os recursos do Semaphore UI apresentados abrangem Community, Pro e Enterprise. As notas de disponibilidade identificam a edição mínima. A seção Licenciamento e suporte explica as opções comerciais.

Comparação de funcionalidades

Uma implantação pode provisionar infraestrutura, configurar hosts e aguardar aprovação antes de alterar o ambiente de produção. Onde essas etapas são executadas, como trocam resultados e quem as controla são as diferenças mais relevantes entre os produtos.

Instalação e configuração

A instalação recomendada do AWX usa Kubernetes. O Semaphore UI também oferece implantações independentes, portanto a infraestrutura necessária para hospedar o serviço é uma das primeiras diferenças a considerar.

SuportadoParcialmente suportadoNão suportado
Instalação e configuração: AWX e Semaphore UI
Critérios Semaphore UI AWX
Binário independente Sim Não
Pacotes nativos para Linux SimDEB / RPM Não
Implantação com Docker Sim ParcialmenteSomente desenvolvimento e testes
Implantação no Kubernetes SimChart Helm SimAWX Operator
Servidor nativo para Windows SimO Ansible exige WSL, contêiner ou runner Linux NãoContêineres Linux
Alta disponibilidade SimEnterpriseBanco de dados compartilhado, Redis, balanceador de carga SimRéplicas, failover do banco de dados configurado separadamente

A implantação recomendada do AWX combina Kubernetes Operator, PostgreSQL e execução de jobs em contêineres. Sua configuração com Docker se destina a desenvolvimento e testes. Para uma equipe que já usa Kubernetes, o Operator segue um modelo operacional conhecido. Introduzir um cluster somente para o AWX acrescenta infraestrutura a manter.

O Semaphore UI também oferece Kubernetes por meio de Helm, além de instalações com binário, pacotes nativos e Docker, usando SQLite, MySQL ou PostgreSQL. Uma instalação independente pode aproveitar um servidor existente sem exigir um cluster, permitindo começar com uma implantação menor e escolher o modelo operacional.

O sistema operacional do servidor é independente da execução dos jobs. O Semaphore UI tem um binário nativo de servidor para Windows, enquanto o Ansible ainda precisa de Linux, macOS, um contêiner adequado ou WSL. Um runner Linux pode executar jobs para um serviço web hospedado em outro ambiente. As duas plataformas podem gerenciar destinos Windows por meio do Ansible.

Para alta disponibilidade, as opções de escalabilidade do AWX e a implantação HA do Semaphore UI Enterprise exigem planejamento de failover e recuperação do banco de dados. Instalações desconectadas também precisam de um meio de disponibilizar pacotes, imagens de execução, atualizações e a ativação de licenças pagas, quando aplicável.

Ferramentas de automação

Uma implantação pode provisionar recursos com Terraform/OpenTofu, configurá-los com Ansible e concluir com Python. O AWX chama as outras ferramentas por meio de playbooks, enquanto o Semaphore UI oferece modelos de tarefas diretos.

SuportadoParcialmente suportadoNão suportado
Ferramentas de automação: AWX e Semaphore UI
Critérios Semaphore UI AWX
Playbooks do Ansible Sim Sim
Terraform/OpenTofu SimModelo de tarefa nativo ParcialmentePor meio de playbooks do Ansible
Terragrunt SimModelo de tarefa nativo ParcialmentePor meio de playbooks do Ansible
Bash SimModelo de tarefa nativo ParcialmentePor meio de playbooks do Ansible
PowerShell SimModelo de tarefa nativo ParcialmentePor meio de playbooks do Ansible
Python SimModelo de tarefa nativo ParcialmentePor meio de playbooks do Ansible

O AWX mantém o Ansible no centro da execução. Os playbooks podem chamar Terraform/OpenTofu, Terragrunt, Bash, PowerShell ou Python por meio de módulos ou comandos, desde que o ambiente de execução contenha as dependências. Isso atende a equipes que já descrevem o provisionamento no Ansible.

O Semaphore UI oferece modelos próprios para essas ferramentas. As equipes podem iniciar automações existentes diretamente e combiná-las em workflows, sem manter playbooks adicionais apenas para chamar outra ferramenta. Uma tarefa OpenTofu pode provisionar a infraestrutura, uma tarefa Ansible configurar os hosts e uma tarefa Python concluir uma operação relacionada, tudo em uma única interface.

O Semaphore UI Pro oferece um backend HTTP integrado para o state do Terraform/OpenTofu, além de workspaces e opções de execução. As equipes podem manter o state compartilhado no Semaphore UI em vez de operar um backend separado. No AWX, o processo Terraform chamado usa o backend configurado pela equipe. A fonte de inventário Terraform State do AWX lê o state para descobrir hosts, mas não o armazena.

A execução do Terraform no Semaphore UI 2.20 tem duas limitações importantes. Uma execução normal exibe um plano antes de aplicá-lo, mas não salva automaticamente esse plano para depois aplicar exatamente o mesmo arquivo. Se a aprovação precisar abranger exatamente a alteração proposta, configure o processo para salvar o plano e passá-lo ao apply. Os comandos padrão do Terraform também desativam o bloqueio do state, a menos que sejam sobrescritos, mesmo quando o backend oferece bloqueio. Revise ambas as configurações ao preparar execuções em produção.

Modelos e agendamento

No AWX, uma configuração Ansible salva é chamada de Job Template. No Semaphore UI, ela é chamada de Task Template. Cada execução cria um job separado no AWX ou uma tarefa no Semaphore UI, com status, logs e resultado próprios. O modelo mantém as configurações reutilizáveis, enquanto os formulários e agendamentos controlam as entradas e o momento de cada execução.

SuportadoParcialmente suportadoNão suportado
Modelos e agendamento: AWX e Semaphore UI
Critérios Semaphore UI AWX
Configuração de tarefa salva Sim Sim
Formulários de entrada na execução Sim Sim
Conjuntos de variáveis reutilizáveis SimVariable Groups compartilhados entre modelos ParcialmenteVariáveis de inventário ou arquivos no Git
Branch do repositório na execução Sim Sim
Execuções agendadas SimExpressões cron e execuções únicas SimAgendamentos únicos e recorrentes

No Job Template do AWX, você seleciona um projeto, playbook, inventário e credenciais, além de um ambiente de execução para as dependências de execução. No Ansible Task Template do Semaphore UI, você seleciona repositório, playbook e inventário, com Variable Groups reutilizáveis e opções do Ansible no mesmo formulário. Os engenheiros preparam essa configuração uma vez, e os colegas podem iniciar a operação sem refazê-la a cada execução.

Editor de Ansible Task Template do Semaphore UI mostrando repositório, playbook, inventário, Variable Groups e solicitações de entrada ao iniciar.
Semaphore UI. Um Ansible Task Template com variáveis compartilhadas e opções de execução.
Editor de Job Template do AWX mostrando projeto, inventário, playbook, credenciais e ambiente de execução.
AWX. Um Ansible Job Template com seleção de recursos e solicitações de entrada ao iniciar.

Os formulários de entrada permitem que colegas forneçam os dados de execução sem editar um playbook. O AWX oferece validações como limites de comprimento de texto. As Survey Variables do Semaphore UI incluem entradas tipadas, texto multilinha, segredos e escolhas únicas ou múltiplas. Variable Groups reutilizáveis mantêm a configuração compartilhada separada dos valores fornecidos na execução. O AWX permite compartilhar configurações por variáveis de inventário, host e grupo ou arquivos no Git, em vez de um objeto Variable Groups separado selecionável em vários modelos.

Ambos podem executar uma branch diferente do repositório quando configurados para permitir isso. O AWX pode solicitar inventário, credenciais e outras configurações do job. O Semaphore UI oferece substituições configuradas de inventário do Ansible e de linha de comando. Essas opções dão flexibilidade aos engenheiros e permitem que os procedimentos aprovados exponham um formulário de execução mais restrito.

Os agendamentos automatizam essas execuções. O AWX usa data e hora de início e configurações de recorrência. O Semaphore UI oferece expressões cron e execuções únicas. Por exemplo, 0 2 * * * executa diariamente às 02:00 no fuso horário configurado no agendador, que por padrão é UTC. As duas abordagens atendem a backups, verificações de hosts ou desligamento de máquinas fora de produção após o horário de trabalho.

Diálogo de agendamento do Semaphore UI com expressão cron diária, modelo de tarefa e horário da próxima execução.
Semaphore UI. Um agendamento cron com entradas da tarefa e previsão da próxima execução.
Formulário de agendamento do AWX com recorrência diária, fuso horário, condições de término e exceções.
AWX. Um agendamento com fuso horário, recorrência, condições de término e exceções.

Inventário

Os dois produtos podem usar arquivos estáticos e descoberta dinâmica. A principal diferença é se os hosts descobertos se tornam registros gerenciados pela plataforma ou são resolvidos pelo Ansible quando o job é executado.

SuportadoParcialmente suportadoNão suportado
Inventário: AWX e Semaphore UI
Critérios Semaphore UI AWX
Inventários estáticos SimEditor e arquivos INI/YAML SimRegistros de hosts/grupos e arquivos importados
Inventários no Git SimRepositório de inventário compartilhado ou separado SimFontes de projetos SCM
Inventários dinâmicos SimPlugins do Ansible e scripts executáveis SimPlugins, scripts e fontes gerenciadas
Atualização de inventário ParcialmenteDescoberta durante a execução SimAtualizações agendadas e ao iniciar
Grupos de inventário calculados SimPlugin constructed do Ansible SimInventários construídos gerenciados
Cache de facts gerenciado NãoCache do Ansible configurado separadamente SimFacts dos hosts armazenados pelo AWX
Edição de hosts e grupos ParcialmenteEdição das definições INI/YAML SimControles individuais de hosts e grupos

O AWX mantém registros de hosts e grupos e os atualiza por meio de jobs de atualização de inventário, usando arquivos estáticos, plugins de inventário do Ansible ou scripts executáveis. O Semaphore UI permite editar inventários INI/YAML ou carregá-los do Git, inclusive de um repositório separado. Plugins e scripts descobrem hosts durante a execução. A principal distinção é se a plataforma gerencia o ciclo de vida do inventário ou reutiliza a configuração Ansible da equipe.

Editor de inventário Ansible do Semaphore UI com dois hosts web de homologação definidos em YAML estático.
Semaphore UI. Um inventário YAML estático com grupos de hosts e variáveis de conexão.
Inventário do AWX mostrando hosts individuais de homologação, seu grupo web e controles para ativar cada host.
AWX. Registros individuais de hosts com grupos associados e controles por host.

Por exemplo, o plugin netbox.netbox.nb_inventory descobre dispositivos e máquinas virtuais, filtra destinos e cria grupos a partir dos dados do NetBox. O NetBox continua sendo a fonte de verdade. O AWX acrescenta controles de atualização e registros armazenados, enquanto o Semaphore UI passa a configuração para o Ansible. Ambos usam o plugin do Ansible, em vez de um conector nativo separado do NetBox. Outras fontes incluem AWS, Azure e Google Cloud, e a documentação do Semaphore UI apresenta um script Python hospedado no Git para o Consul.

Os inventários construídos do AWX combinam inventários de entrada salvos e gerenciam os hosts resultantes. O Semaphore UI pode usar o plugin constructed do Ansible para criar grupos e variáveis a partir de fontes anteriores. Plugins de cache do Ansible podem preservar facts, mas o Semaphore UI não oferece o cache de facts gerenciado do AWX. Armazenamento, expiração e compartilhamento do cache entre runners continuam fazendo parte da configuração do Ansible.

O Semaphore UI planeja adicionar relatórios do Ansible no estilo ARA na versão 2.21.0. O recurso complementará as funcionalidades de inventário com uma visão de cada host e de seu histórico de automação, ajudando os operadores a identificar quais tarefas foram executadas em cada servidor, quando ocorreram e onde houve falhas.

Escolha o modelo de inventário do AWX quando os operadores precisarem consultar, atualizar e gerenciar registros de hosts na plataforma. O Semaphore UI atende a uma configuração em que o Git define o inventário ou o Ansible descobre hosts em sistemas como NetBox e APIs de nuvem durante a execução.

Segredos

Jobs salvos precisam de credenciais sem exigir que os operadores colem senhas ou tokens de nuvem a cada execução. As opções de armazenamento e consulta determinam como essas credenciais chegam ao job.

SuportadoParcialmente suportadoNão suportado
Segredos: AWX e Semaphore UI
Critérios Semaphore UI AWX
Armazenamento de credenciais Sim Sim
HashiCorp Vault SimPro Sim
OpenBao SimPro NãoSem integração nativa, a compatibilidade com Vault precisa ser testada
AWS Secrets Manager SimEnterprise Sim
Azure Key Vault SimEnterprise Sim
Devolutions Server SimEnterprise NãoSem integração nativa, conexão personalizada possível

Os objetos de credenciais do AWX e o Key Store do Semaphore UI fornecem credenciais aos jobs salvos sem exigir que um operador as cole em cada execução. Ambos se integram com HashiCorp Vault, AWS Secrets Manager e Azure Key Vault, permitindo que as equipes continuem usando esses serviços existentes.

Formulário de armazenamento Vault do Semaphore UI mostrando URL do servidor, mount, namespace e opções de origem do token.
Semaphore UI. Configurações de conexão com Vault, mount e origem do token.
Formulário de credencial HashiCorp Vault Secret Lookup do AWX mostrando campos de conexão e autenticação.
AWX. Campos de conexão e autenticação para consulta ao Vault. Há configurações adicionais abaixo da área visível.

Outras integrações diferenciam os produtos. O AWX oferece CyberArk Central Credential Provider, CyberArk Conjur e tipos de credenciais personalizados. O Semaphore UI fornece integrações específicas com OpenBao e Devolutions Server. A consulta Vault do AWX pode funcionar com um serviço compatível, mas a compatibilidade com OpenBao precisa ser verificada para a operação desejada.

Compare a integração com o cofre que a equipe já utiliza, incluindo o método de autenticação e os tipos de segredo necessários aos jobs. Serviços sem integração nativa podem exigir código personalizado para recuperar segredos.

Execução

Um job precisa de capacidade de execução que consiga alcançar seus destinos. Workers remotos e imagens de contêiner resolvem, separadamente, a localização na rede e as dependências de execução.

SuportadoParcialmente suportadoNão suportado
Execução: AWX e Semaphore UI
Critérios Semaphore UI AWX
Execução remota Sim Sim
Capacidade de execução dedicada SimProRunners de projeto SimGrupos de instâncias atribuídos a recursos
Roteamento da execução SimProTags de runners nos modelos ou inventários SimGrupos de instâncias atribuídos a recursos
Roles e collections do Ansible SimInstalação a partir de requirements.yml SimInstalação durante a sincronização do projeto
Tarefas em contêineres SimProExecutor Docker SimImagens de ambiente de execução do Ansible
Pods de jobs no Kubernetes SimEnterprise Sim
Controles de concorrência SimLimites por modelo, projeto e instância SimJobs simultâneos e capacidade dos grupos de instâncias

O AWX envia trabalho a nós de execução, reunidos em grupos de instâncias que podem ser atribuídos a organizações, inventários ou modelos. O Semaphore UI executa jobs no servidor ou os envia a runners. Em ambos os modelos, as máquinas de execução podem ficar próximas dos sistemas de destino enquanto a interface web permanece centralizada.

Um runner do Semaphore UI dentro de uma rede privada pode aplicar patches nos hosts ou renovar certificados sem conectividade direta a partir do servidor web. Os runners de projeto atribuem capacidade a um projeto, enquanto tags nos modelos ou inventários encaminham jobs aos runners correspondentes. Isso atende a locais distribuídos e ambientes de clientes. As tags de roteamento selecionam máquinas, mas não impõem isolamento de rede ou de contas de nuvem.

O ambiente de execução determina o que será executado nessas máquinas. O AWX usa imagens de ambiente de execução com Ansible e suas dependências, e os grupos de contêineres podem criar um pod Kubernetes por job. O Semaphore UI oferece execução Docker por tarefa no Pro e execução Kubernetes no Enterprise. Essas opções são independentes da hospedagem do serviço web em um contêiner. Os dois produtos podem instalar roles e collections do Ansible a partir dos requisitos do repositório, enquanto outras bibliotecas e ferramentas devem estar na máquina de execução ou em sua imagem.

Os controles de concorrência limitam o trabalho simultâneo. O AWX combina as configurações de jobs concorrentes com a capacidade de execução e os limites dos grupos de instâncias. O Semaphore UI aplica limites de instância, projeto e modelo.

O AWX também pode dividir automaticamente um inventário grande em jobs paralelos. O Semaphore UI pode distribuir o trabalho em execuções separadas com limites de hosts do Ansible, usando tags de runners para selecionar as máquinas de execução. A equipe mantém esses subconjuntos e suas execuções. Para atualizações graduais, a configuração serial do Ansible controla lotes sequenciais. Esses recursos atendem a execuções direcionadas e implantações em etapas, enquanto o slicing do AWX fornece divisão automática para operações paralelas em toda a frota.

Workflows

O provisionamento pode exigir um plano, aprovação, implantação e configuração dos hosts, com caminhos diferentes após sucesso ou falha. A composição do workflow determina como essas etapas se conectam.

SuportadoParcialmente suportadoNão suportado
Workflows: AWX e Semaphore UI
Critérios Semaphore UI AWX
Editor visual de workflows Sim Sim
Vários nós iniciais Não Sim
Junção de ramificações Sim Sim
Workflows como etapas Não Sim
Ramificações de sucesso/falha Sim Sim
Etapas de aprovação Sim Sim
Função separada de aprovador NãoAnunciada para a versão 2.21 Sim
Passagem de valores no workflow Sim Sim

Os workflows do AWX conectam modelos de job do Ansible, com outras ferramentas chamadas por playbooks. O Semaphore UI conecta diretamente modelos Ansible, Terraform/OpenTofu, Terragrunt, Bash, PowerShell e Python. Ambos oferecem ramificações de sucesso/falha e aprovações, permitindo pausar um processo de provisionamento antes de uma alteração em produção.

Ambos usam grafos sem ciclos e permitem condições que exigem todos ou qualquer um dos predecessores nas junções. O AWX permite vários nós iniciais. O Semaphore UI começa com um nó e oferece nós de tarefa, aprovação, espera temporizada e anotação.

O AWX pode reutilizar um workflow inteiro dentro de outro, mantendo um procedimento compartilhado de várias etapas em um só lugar. Ele impede execução recursiva e oferece etapas de atualização de repositório e inventário. O Semaphore UI reutiliza modelos de tarefas individuais entre workflows, mas não pode incorporar um workflow como etapa. Essa diferença importa quando várias implantações compartilham um procedimento, e não apenas um job.

Editor de workflows do Semaphore UI com etapa de plano, aprovação, implantação e ramificações separadas de sucesso e falha.
Semaphore UI. Um workflow de implantação com aprovação e caminhos separados de sucesso e falha.
Workflow Visualizer completo do AWX com plano, aprovação, implantação, verificação de release aninhada e ramificação de recuperação.
AWX. Aprovação antes da implantação, um workflow de verificação aninhado e uma ramificação de recuperação de falhas.

O AWX tem uma função de aprovador atribuível separadamente, e administradores também podem aprovar. No Semaphore UI 2.20, a aprovação acompanha a permissão de executar tarefas do projeto. Se a equipe precisa atribuir aprovação independentemente da execução, essa é uma diferença relevante. Uma função separada de aprovador do Semaphore UI está anunciada para a versão 2.21 e não faz parte desta comparação.

Ambos oferecem aprovações pela interface e por API autenticada, e o AWX também fornece um módulo Ansible. Aprovação interativa no Slack requer uma integração que chame a API, e não apenas uma notificação.

Ambos passam valores para jobs posteriores, como o endereço de um host recém-provisionado. O AWX disponibiliza os valores set_stats definidos no playbook como variáveis extras nas etapas seguintes, inclusive em nós de execução. Um playbook pode capturar o resultado de outra ferramenta dessa maneira. O Semaphore UI coleta set_stats do Ansible, saídas do Terraform/OpenTofu/Terragrunt e JSON de Bash, PowerShell ou Python, mapeando os valores para variáveis de formulário de destino por nomes correspondentes ou mapeamentos explícitos.

No Semaphore UI 2.20, a coleta de saídas funciona no servidor e nos runners remotos que usam o executor local. Os executores Docker e Kubernetes ainda não produzem saídas. Os valores são coletados após tarefas bem-sucedidas, portanto ramificações de falha não podem depender de saídas de uma tarefa que falhou. Eles ficam visíveis a quem pode consultar a tarefa e não devem conter segredos.

A passagem de valores não transfere arquivos em nenhum dos produtos. Se etapas separadas trocarem um plano Terraform salvo ou outro artefato, forneça armazenamento acessível a ambas. Reutilizar um runner não garante a persistência do diretório de trabalho entre tarefas.

Controle de acesso

A equipe de suporte pode precisar reiniciar um serviço aprovado sem receber um acesso genérico ao servidor. A delegação deve limitar tanto a operação quanto seus destinos.

SuportadoParcialmente suportadoNão suportado
Controle de acesso: AWX e Semaphore UI
Critérios Semaphore UI AWX
Controle de acesso baseado em funções SimFunções de projeto, funções personalizadas no Enterprise SimFunções de organização, equipe e recurso
Permissões independentes de inventário e credenciais NãoAcesso aos recursos segue as funções do projeto Sim
Permissões de execução por modelo SimEnterprise Sim
LDAP e OIDC SimPro Sim
Login único com SAML NãoOIDC disponível Sim
Autenticação de dois fatores SimProTOTP local SimPor meio de um provedor de identidade externo

O AWX concede permissões independentes a inventários, credenciais e modelos de job. O Semaphore UI organiza o acesso por projetos, com funções personalizadas e permissões de execução por modelo no Enterprise para uma delegação mais específica. Um modelo pré-configurado pode disponibilizar uma operação aprovada com o inventário, as credenciais e as configurações de execução definidos.

Por exemplo, o Semaphore UI Enterprise pode dar à equipe de suporte acesso a um modelo de reinicialização de serviço para servidores de produção designados. Uma função base Guest junto com uma função personalizada sem permissões gerais no projeto pode conceder execução nesse modelo. Restrinja substituições de inventário, limites de hosts, variáveis e outras opções de execução, e confira se funções adicionais não ampliam o acesso. O modelo, as permissões e a automação definem em conjunto a operação permitida. O formulário apenas coleta as entradas.

Isso delega operações específicas sem criar permissões independentes de inventário ou credenciais dentro de um projeto. O AWX é mais adequado quando operadores precisam combinar recursos com regras de acesso separadas. As permissões de modelos do Semaphore UI atendem a um conjunto definido de procedimentos aprovados.

Ambos oferecem LDAP e OIDC para autenticação. O AWX também oferece SAML e depende de um provedor de identidade externo para MFA. O Semaphore UI oferece autenticação local de dois fatores com TOTP. Um provedor de identidade com OIDC pode atender à autenticação centralizada no Semaphore UI, enquanto um requisito exclusivamente SAML exige outra abordagem de integração.

Logs e auditoria

A saída de um job ajuda a explicar falhas de execução. O histórico de auditoria registra quem iniciou uma operação ou alterou sua configuração, com requisitos distintos de visibilidade e retenção.

SuportadoParcialmente suportadoNão suportado
Logs e auditoria: AWX e Semaphore UI
Critérios Semaphore UI AWX
Histórico e logs de tarefas Sim Sim
Retenção do histórico de tarefas SimManter as tarefas mais recentes por modelo SimLimpeza agendada por antiguidade
Histórico de auditoria entre projetos SimLog de auditoria para administradores, gravação precisa ser ativada SimFluxo de atividades, visibilidade baseada em funções
Encaminhamento para SIEM SimProSyslog com TLS e Splunk HEC SimLogs externos, incluindo Splunk

Os dois produtos mantêm histórico e saída das tarefas para diagnóstico. A visibilidade da auditoria é diferente: o fluxo de atividades do AWX segue as permissões dos recursos e as funções de administrador ou auditor. A visão de auditoria entre projetos do Semaphore UI está disponível para administradores, com eventos armazenados no banco de dados quando a gravação de auditoria está ativada.

Para investigações centralizadas, os logs externos do AWX encaminham registros de atividade, jobs e servidor, inclusive ao Splunk. O Semaphore UI Pro acrescenta filtros de auditoria, exportação CSV ou JSONL e encaminhamento via Syslog com TLS ou Splunk HEC. Ambos podem fornecer eventos a uma plataforma de logs ou a um sistema de gestão de informações e eventos de segurança (SIEM).

A retenção local usa controles diferentes. O AWX oferece limpeza agendada com base na antiguidade dos registros para o histórico de execução e o fluxo de atividades. O Semaphore UI mantém uma quantidade configurada de tarefas recentes por modelo. Um sistema central de logs pode preservar registros além desses limites locais.

Integrações

Alterações no repositório e solicitações em portais de serviço podem acionar automações. APIs, webhooks e notificações conectam esses eventos aos jobs e seus resultados.

SuportadoParcialmente suportadoNão suportado
Integrações: AWX e Semaphore UI
Critérios Semaphore UI AWX
REST API Sim Sim
Webhooks de jobs SimEndpoints genéricos, regras de correspondência, extração de valores SimWebhooks do GitHub e GitLab
Notificações de jobs Sim Sim

O AWX oferece webhooks de jobs integrados para GitHub e GitLab, voltados à automação acionada por repositórios. O Semaphore UI oferece endpoints genéricos de webhook com identificação de solicitações por regras e extração das entradas da tarefa. Esses endpoints podem receber eventos de diferentes sistemas, enquanto as APIs REST dos dois produtos atendem a outros clientes.

Para notificações de saída, o AWX oferece email, Slack, Rocket.Chat, Mattermost, PagerDuty, AWS SNS, Grafana, IRC, Twilio e webhooks. O Semaphore UI oferece email (SMTP), Telegram, Slack, Microsoft Teams, Rocket.Chat, DingTalk e Gotify. Essas notificações informam pessoas ou serviços sobre eventos dos jobs, enquanto os webhooks de entrada iniciam a automação.

Um portal de serviços ou sistema ITSM pode usar qualquer uma das APIs REST para iniciar um job preparado e consultar seu resultado. Por exemplo, um portal interno pode enviar uma solicitação de renovação de certificado a um modelo salvo e informar a conclusão ao solicitante. Trata-se de uma integração via API configurada pela equipe, e não de um conector nativo específico.

Automação assistida por IA

As duas plataformas fornecem materiais úteis para assistentes de programação como Claude Code e Codex: documentação pública, código aberto e APIs documentadas. Um assistente pode consultar exemplos de configuração, examinar como uma opção é implementada e usar definições de API para elaborar rascunhos de código de integração. Com a configuração e a saída do job relevantes, também pode ajudar a investigar falhas. Isso permite usar IA na configuração e na solução de problemas sem que a plataforma tenha um recurso de IA dedicado integrado.

Há conectores MCP da comunidade para AWX e Semaphore UI. Dependendo do conector, eles permitem que assistentes acessem operações da plataforma, como localizar modelos, iniciar jobs e consultar resultados. Assim, a equipe pode usar automações preparadas por meio de um assistente, mantendo as definições dos jobs e sua execução na plataforma.

O Semaphore UI anunciou suporte oficial a MCP no Pro para a versão 2.21.0.

Licenciamento e suporte

AWX e Semaphore UI oferecem software gratuito e de código aberto. A principal diferença está em como as equipes podem obter recursos comerciais, suporte do fornecedor e compromissos contratuais à medida que a automação se torna mais importante para suas operações.

Opções de código aberto e comerciais

O AWX é licenciado sob Apache 2.0 e recebe suporte da comunidade. Também é um projeto upstream do componente automation controller do Red Hat Ansible Automation Platform (AAP). A Red Hat não vende uma assinatura de suporte para o próprio AWX. Sua oferta com suporte comercial é o AAP, uma plataforma empresarial separada que combina automation controller com componentes adicionais, conteúdo certificado e um ciclo de vida de produto definido.

O Semaphore UI segue um modelo open-core. A edição Community é gratuita e licenciada sob MIT, enquanto Pro e Enterprise acrescentam recursos comerciais e suporte do fornecedor dentro da mesma família de produtos. O Pro foi pensado para equipes de engenharia menores que incorporam a automação às operações diárias. O Enterprise atende a exigências mais rigorosas de acesso, execução, disponibilidade e suporte.

Assim, as ofertas comerciais atendem a necessidades de compra distintas. O AAP é um investimento mais amplo em uma plataforma empresarial. Os planos comerciais do Semaphore UI são voltados a equipes de engenharia e organizações de médio porte, com a opção Enterprise para ambientes complexos ou críticos ao negócio. As equipes podem obter controles avançados e suporte do fornecedor mantendo o investimento concentrado no serviço de automação de que precisam.

Suporte e compromissos contratuais

Usuários do AWX podem fazer perguntas, relatar bugs e contribuir com correções pelos canais da comunidade. Essa assistência não cria uma obrigação do fornecedor de responder em determinado prazo ou prestar suporte a incidentes. Uma assinatura AAP fornece suporte da Red Hat para o AAP, mas não acrescenta cobertura a uma instalação AWX existente.

O Semaphore UI Community também oferece assistência de melhor esforço, sem SLA de suporte. O Pro inclui suporte do fornecedor em horário comercial, enquanto o Enterprise oferece opções de SLA adaptadas e ajuda com implantação inicial, configuração, atualizações e migração. Os clientes comerciais, portanto, têm uma relação direta com o fornecedor, com obrigações de suporte definidas pelo plano e contrato aplicáveis.

Planejamento de versões e manutenção

Atualmente, o AWX informa que as releases estão pausadas durante uma refatoração de grande porte. O Semaphore UI continua publicando releases e mantém uma política de segurança que identifica as versões suportadas. Essas diferenças importam no planejamento de atualizações e manutenção contínua. Analise o histórico de releases, as políticas de segurança e as orientações de atualização da versão que pretende operar, junto com os compromissos contratuais de suporte.

Como escolher

As duas plataformas permitem compartilhar automações, agendar jobs e consultar resultados. Escolha com base em como você gerencia informações dos hosts, delega operações, hospeda o serviço e obtém suporte.

Quando escolher o AWX

O AWX é uma boa escolha quando o Ansible está no centro da automação e seu modelo de gestão de recursos corresponde às operações diárias da equipe.

  • Gerenciar inventários pela plataforma é um requisito central. Seus operadores dependem da plataforma para manter registros de hosts e grupos, atualizar inventários e preservar facts dos hosts no trabalho diário.
  • Inventários e credenciais precisam de regras de acesso próprias. A equipe precisa atribuir permissões a inventários e credenciais individuais independentemente dos modelos de job, permitindo que operadores combinem apenas os recursos que estão autorizados a usar.
  • O Kubernetes se encaixa na infraestrutura existente. Sua equipe já opera um cluster, portanto o modelo de implantação recomendado do AWX se alinha aos sistemas e às competências que vocês mantêm.
  • O Ansible já orquestra seus procedimentos. Seus playbooks abrangem as operações necessárias, inclusive chamadas a outras ferramentas, e os ambientes de execução do Ansible fornecem as dependências.
  • O suporte da comunidade atende às suas necessidades. A equipe tem conhecimento e capacidade para investigar incidentes, avaliar avisos de segurança e manter a instalação sem um SLA de resposta do fornecedor.

Quando escolher o Semaphore UI

O Semaphore UI é uma boa escolha quando você busca um serviço simples para executar e compartilhar automações com suas ferramentas e infraestrutura existentes.

  • Seus inventários já estão no Git ou em sistemas externos. Você quer reutilizar definições de inventário e plugins do Ansible que descobrem hosts no NetBox, em APIs de nuvem ou em outras fontes durante a execução dos jobs.
  • Colegas precisam acessar operações preparadas. Engenheiros definem tarefas como implantações, reinicializações de serviços ou renovações de certificados. Outros membros da equipe executam essas tarefas com as entradas necessárias, enquanto inventários e credenciais permanecem na configuração preparada.
  • Você quer implantar sem Kubernetes. Instalações com binário, pacotes nativos e Docker permitem usar um servidor existente, evitando criar um cluster apenas para o serviço de automação.
  • Sua automação abrange várias ferramentas. Modelos específicos executam diretamente Ansible, Terraform/OpenTofu, Terragrunt, Bash, PowerShell e Python, com workflows conectando suas operações.
  • Você quer um caminho direto para suporte comercial. As licenças comerciais acrescentam suporte do fornecedor e recursos avançados na mesma família de produtos, permitindo obter compromissos de suporte enquanto continua usando o Semaphore UI.

Perguntas frequentes

O Semaphore UI pode substituir o AWX?

Sim, quando seu modelo de inventário, permissões e workflows atende aos requisitos. Playbooks existentes frequentemente podem ser reutilizados, mas a configuração dos jobs e os controles de acesso precisam ser mapeados e testados. Verifique dependências de recursos específicos do AWX, principalmente workflows aninhados, permissões independentes de inventário ou credenciais e cache de facts gerenciado.

Posso reutilizar meus playbooks existentes do Ansible?

Comece pelo mesmo repositório e pelos mesmos playbooks. Configure no Semaphore UI o inventário, as credenciais, as variáveis, as collections e as dependências de execução necessários e depois teste execuções representativas. Reutilizar o código não significa importar automaticamente todas as configurações do AWX.

O que verificar ao migrar do AWX?

Comece com um workflow representativo. Reutilize seus playbooks quando possível e mapeie inventários, credenciais, variáveis, formulários, agendamentos e dependências de execução. Verifique separadamente permissões, aprovações, workflows aninhados e a transferência de valores ou arquivos. Uma importação pode reduzir o trabalho de configuração, mas não comprova que o job importado se comporta da mesma forma. Teste antes de habilitar agendamentos em produção.

Quais recursos do Semaphore UI exigem uma edição paga?

O Community abrange a interface principal de tarefas e os workflows. Recursos como runners de projeto, execução Docker e integrações com cofres externos estão disponíveis a partir do Pro. Funções personalizadas, permissões de modelos, execução de tarefas no Kubernetes e alta disponibilidade exigem Enterprise. Ao avaliar um plano, confira o recurso e a capacidade de que precisa.

Posso manter o login único com SAML após a migração?

O AWX oferece SAML diretamente. O Semaphore UI oferece LDAP e OIDC, mas não tem integração SAML nativa. Um provedor de identidade que também ofereça OIDC pode atender ao requisito de autenticação. Verifique separadamente o mapeamento de usuários e grupos, pois mudar o protocolo de autenticação não recria as permissões do AWX.

O Semaphore UI exige Kubernetes?

Não. Há instalações com binário, pacotes e Docker. O Kubernetes é uma opção de implantação. Ferramentas de automação e um banco de dados adequado continuam fazendo parte do ambiente.

O AWX pode executar Terraform ou usar HashiCorp Vault?

Sim. Playbooks podem executar comandos Terraform ou módulos de collections, e o AWX oferece consultas de credenciais ao HashiCorp Vault. O Semaphore UI adota outro modelo de configuração, com modelos específicos para Terraform/OpenTofu e um backend HTTP de state opcional no Pro.

As duas plataformas oferecem execução remota?

Ambas podem executar tarefas em servidores remotos. O AWX usa nós de execução agrupados para diferentes equipes e cargas de trabalho. O Semaphore UI usa agentes runners. Seus modelos de configuração e acesso são diferentes.

Este artigo foi útil?

Fontes

  1. ARA Records Ansible, “ARA Records Ansible”. URL: https://ara.recordsansible.org/ (acessado em: ).
  2. Semaphore UI, “Semaphore runner output capture and executor limits”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/services/runners/job_pool.go#L167-L192 (acessado em: ).
  3. Semaphore UI, “Semaphore task dispatch, runner routing, concurrency and remote workflow outputs”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/services/tasks/TaskPool.go (acessado em: ).
  4. Semaphore UI, “Semaphore workflow input mapping model”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/db/Workflow.go#L27-L44 (acessado em: ).
  5. Semaphore UI, “Semaphore task template options and survey field types”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/db/Template.go (acessado em: ).
  6. Semaphore UI, “Semaphore NetBox dynamic inventory example”. URL: https://semaphoreui.com/docs/user-guide/inventory/netbox-dynamic-inventory (acessado em: ).
  7. Semaphore UI, “Semaphore Consul inventory script”. URL: https://semaphoreui.com/docs/user-guide/inventory/consul-dynamic-inventory (acessado em: ).
  8. Ansible community, “NetBox Ansible inventory plugin”. URL: https://docs.ansible.com/projects/ansible/latest/collections/netbox/netbox/nb_inventory_inventory.html (acessado em: ).
  9. Ansible community, “AWS EC2 Ansible inventory plugin”. URL: https://docs.ansible.com/projects/ansible/latest/collections/amazon/aws/aws_ec2_inventory.html (acessado em: ).
  10. Ansible community, “Azure Ansible inventory plugin”. URL: https://docs.ansible.com/projects/ansible/latest/collections/azure/azcollection/azure_rm_inventory.html (acessado em: ).
  11. Ansible community, “Google Cloud Ansible inventory plugin”. URL: https://docs.ansible.com/projects/ansible/latest/collections/google/cloud/gcp_compute_inventory.html (acessado em: ).
  12. Semaphore UI, “Semaphore cloning of inventory repositories”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/services/tasks/local_executor_inventory.go (acessado em: ).
  13. Semaphore UI, “Semaphore local execution, workflow outputs, inventory paths, host limits and branch overrides”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/services/tasks/local_executor.go (acessado em: ).
  14. Semaphore UI, “Semaphore survey field types”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/web/src/components/SurveyVars.vue (acessado em: ).
  15. Semaphore UI, “Semaphore survey inputs and task launch form”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/web/src/components/TaskForm.vue (acessado em: ).
  16. Semaphore UI, “What is Semaphore UI?”. URL: https://semaphoreui.com/docs/introduction/what-is-semaphore (acessado em: ).
  17. AWX project, “AWX user guide”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/index.html (acessado em: ).
  18. Semaphore UI, “Semaphore source and MIT license”. URL: https://github.com/semaphoreui/semaphore (acessado em: ).
  19. AWX project, “AWX source and Apache 2.0 license”. URL: https://github.com/ansible/awx (acessado em: ).
  20. Semaphore UI, “Semaphore setup and first run”. URL: https://semaphoreui.com/docs/getting-started (acessado em: ).
  21. Semaphore UI, “Semaphore installation methods and dependencies”. URL: https://semaphoreui.com/docs/admin-guide/installation (acessado em: ).
  22. AWX project, “AWX installation paths”. URL: https://github.com/ansible/awx/blob/24.6.1/INSTALL.md (acessado em: ).
  23. AWX project, “AWX Operator installation”. URL: https://docs.ansible.com/projects/awx-operator/en/latest/installation/basic-install.html (acessado em: ).
  24. Semaphore UI, “Semaphore high availability prerequisites”. URL: https://semaphoreui.com/docs/admin-guide/ha#prerequisites (acessado em: ).
  25. AWX project, “AWX web and task replica scaling”. URL: https://docs.ansible.com/projects/awx-operator/en/latest/user-guide/advanced-configuration/scaling-the-web-and-task-pods-independently.html (acessado em: ).
  26. Semaphore UI, “Semaphore automation applications”. URL: https://semaphoreui.com/docs/user-guide/apps (acessado em: ).
  27. Semaphore UI, “Semaphore task templates”. URL: https://semaphoreui.com/docs/user-guide/task-templates (acessado em: ).
  28. AWX project, “AWX job templates and surveys”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/job_templates.html (acessado em: ).
  29. Semaphore UI, “Survey variables”. URL: https://semaphoreui.com/docs/user-guide/task-templates/survey-vars (acessado em: ).
  30. Semaphore UI, “Terraform and OpenTofu in Semaphore”. URL: https://semaphoreui.com/docs/user-guide/apps/terraform (acessado em: ).
  31. Ansible community, “Ansible Terraform module”. URL: https://docs.ansible.com/projects/ansible/latest/collections/community/general/terraform_module.html (acessado em: ).
  32. Semaphore UI, “Semaphore Terraform HTTP backend”. URL: https://semaphoreui.com/docs/user-guide/apps/terraform/states (acessado em: ).
  33. Semaphore UI, “Semaphore workflow nodes and approvals”. URL: https://semaphoreui.com/docs/user-guide/workflows (acessado em: ).
  34. Semaphore UI, “Semaphore inventory types and stored resources”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/db/Inventory.go (acessado em: ).
  35. AWX project, “AWX job slicing”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/job_slices.html (acessado em: ).
  36. Semaphore UI, “Semaphore workflow approval API routes”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/api/router.go (acessado em: ).
  37. AWX project, “AWX resource, workflow approval and activity-stream access control”. URL: https://github.com/ansible/awx/blob/24.6.1/awx/main/access.py (acessado em: ).
  38. AWX project, “AWX workflow approval Ansible module”. URL: https://github.com/ansible/awx/blob/24.6.1/awx_collection/plugins/modules/workflow_approval.py (acessado em: ).
  39. AWX project, “AWX workflow branch convergence”. URL: https://github.com/ansible/awx/blob/24.6.1/awx/main/scheduler/dag_workflow.py#L51-L112 (acessado em: ).
  40. AWX project, “AWX Terraform State inventory source”. URL: https://github.com/ansible/awx/blob/24.6.1/docs/docsite/rst/userguide/inventories.rst#L1092-L1121 (acessado em: ).
  41. AWX project, “AWX instance-group capacity limits”. URL: https://github.com/ansible/awx/blob/24.6.1/docs/docsite/rst/administration/containers_instance_groups.rst#L247-L263 (acessado em: ).
  42. AWX project, “AWX custom credential types”. URL: https://github.com/ansible/awx/blob/24.6.1/docs/credentials/custom_credential_types.md (acessado em: ).
  43. AWX project, “AWX workflows”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/workflow_templates.html (acessado em: ).
  44. AWX project, “AWX workflow branching and output variables”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/workflows.html (acessado em: ).
  45. AWX project, “AWX collection of Ansible workflow variables”. URL: https://github.com/ansible/awx/blob/24.6.1/awx/main/tasks/callback.py#L156-L160 (acessado em: ).
  46. AWX project, “AWX processing of execution-node events”. URL: https://github.com/ansible/awx/blob/24.6.1/awx/main/tasks/receptor.py#L544-L553 (acessado em: ).
  47. AWX project, “AWX inheritance of variables between workflow jobs”. URL: https://github.com/ansible/awx/blob/24.6.1/awx/main/models/workflow.py#L324-L354 (acessado em: ).
  48. Semaphore UI, “Semaphore global runners”. URL: https://semaphoreui.com/docs/admin-guide/runners/ (acessado em: ).
  49. Semaphore UI, “Semaphore project runners”. URL: https://semaphoreui.com/docs/user-guide/projects/runners (acessado em: ).
  50. AWX project, “AWX execution and hop nodes”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/administration/instances.html (acessado em: ).
  51. AWX project, “AWX execution environments”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/execution_environments.html (acessado em: ).
  52. AWX project, “AWX Kubernetes container groups”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/administration/containers_instance_groups.html (acessado em: ).
  53. Semaphore UI, “Semaphore inventories”. URL: https://semaphoreui.com/docs/user-guide/inventory (acessado em: ).
  54. AWX project, “AWX inventories”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/inventories.html (acessado em: ).
  55. Semaphore UI, “Semaphore project access”. URL: https://semaphoreui.com/docs/user-guide/projects (acessado em: ).
  56. Semaphore UI, “Semaphore team roles and template-level permissions”. URL: https://semaphoreui.com/docs/user-guide/team#extended-rbac (acessado em: ).
  57. AWX project, “AWX role-based access controls”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/rbac.html (acessado em: ).
  58. Semaphore UI, “Semaphore LDAP and OIDC authentication”. URL: https://semaphoreui.com/docs/admin-guide/authentication (acessado em: ).
  59. AWX project, “AWX LDAP, OIDC and SAML authentication”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/administration/ent_auth.html (acessado em: ).
  60. Semaphore UI, “Semaphore Key Store”. URL: https://semaphoreui.com/docs/user-guide/key-store (acessado em: ).
  61. AWX project, “AWX credentials and secret lookups”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/credentials.html (acessado em: ).
  62. AWX project, “AWX external secret management integrations”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/credential_plugins.html (acessado em: ).
  63. Semaphore UI, “Semaphore OpenBao secret storage”. URL: https://semaphoreui.com/docs/user-guide/key-store/openbao (acessado em: ).
  64. Semaphore UI, “Semaphore Devolutions Server secret storage”. URL: https://semaphoreui.com/docs/user-guide/key-store/devolutions-server (acessado em: ).
  65. Semaphore UI, “Semaphore webhook integrations”. URL: https://semaphoreui.com/docs/user-guide/integrations (acessado em: ).
  66. AWX project, “AWX webhooks”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/webhooks.html (acessado em: ).
  67. Semaphore UI, “Semaphore REST API”. URL: https://semaphoreui.com/api-docs (acessado em: ).
  68. Ansible community, “Ansible command execution”. URL: https://docs.ansible.com/projects/ansible/latest/collections/ansible/builtin/command_module.html (acessado em: ).
  69. Ansible community, “Ansible PowerShell module”. URL: https://docs.ansible.com/projects/ansible/latest/collections/ansible/windows/win_powershell_module.html (acessado em: ).
  70. Semaphore UI, “Semaphore notification channels”. URL: https://semaphoreui.com/docs/admin-guide/notifications (acessado em: ).
  71. AWX project, “AWX notifications”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/notifications.html (acessado em: ).
  72. Semaphore UI, “Semaphore task history and output”. URL: https://semaphoreui.com/docs/user-guide/tasks (acessado em: ).
  73. Semaphore UI, “Semaphore scheduled tasks”. URL: https://semaphoreui.com/docs/user-guide/schedules (acessado em: ).
  74. AWX project, “AWX activity stream”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/main_menu.html (acessado em: ).
  75. Semaphore UI, “Semaphore Community, Pro and Enterprise”. URL: https://semaphoreui.com/pricing (acessado em: ).
  76. Red Hat, “Red Hat: AWX and Ansible Automation Platform”. URL: https://www.redhat.com/en/technologies/management/ansible/compare-awx-vs-ansible-automation-platform (acessado em: ).
  77. Red Hat, “Red Hat automation controller, formerly Ansible Tower”. URL: https://www.redhat.com/en/technologies/management/ansible/automation-controller (acessado em: ).
  78. Semaphore UI, “Semaphore stable releases”. URL: https://github.com/semaphoreui/semaphore/releases (acessado em: ).
  79. AWX project, “AWX release history”. URL: https://github.com/ansible/awx/releases (acessado em: ).
  80. Semaphore MCP contributors, “Semaphore MCP connector”. URL: https://github.com/cloin/semaphore-mcp (acessado em: ).
  81. Semaphore MCP contributors, “Semaphore MCP task execution and output”. URL: https://github.com/cloin/semaphore-mcp/blob/72f5b7008f6d560c74e01da9884e6fddbbf68999/src/semaphore_mcp/tools/tasks.py (acessado em: ).
  82. LY Corporation, “AWX MCP connector and compatibility”. URL: https://github.com/lycorp-jp/awx-mcp/tree/fa4d25ffa9e04967e98dc66b219a0481d61ea814 (acessado em: ).
  83. LY Corporation, “AWX MCP job template execution”. URL: https://github.com/lycorp-jp/awx-mcp/blob/fa4d25ffa9e04967e98dc66b219a0481d61ea814/awx_mcp/tools/job_templates.py (acessado em: ).
  84. LY Corporation, “AWX MCP job output”. URL: https://github.com/lycorp-jp/awx-mcp/blob/fa4d25ffa9e04967e98dc66b219a0481d61ea814/awx_mcp/tools/jobs.py (acessado em: ).
  85. HashiCorp, “Terraform local state backend”. URL: https://developer.hashicorp.com/terraform/language/backend/local (acessado em: ).
  86. HashiCorp, “Terraform state locking”. URL: https://developer.hashicorp.com/terraform/language/state/locking (acessado em: ).
  87. Semaphore UI, “Semaphore variable groups”. URL: https://semaphoreui.com/docs/user-guide/environment (acessado em: ).
  88. Semaphore UI, “Semaphore runner selection and capacity”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/services/tasks/RemoteJob.go (acessado em: ).
  89. Semaphore UI, “Semaphore cron and one-time schedule execution”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/services/schedules/SchedulePool.go (acessado em: ).
  90. AWX project, “AWX schedules”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/scheduling.html (acessado em: ).
  91. Ansible community, “Ansible constructed inventory plugin”. URL: https://docs.ansible.com/projects/ansible/latest/collections/ansible/builtin/constructed_inventory.html (acessado em: ).
  92. Ansible community, “Ansible cache plugins”. URL: https://docs.ansible.com/projects/ansible/latest/plugins/cache.html (acessado em: ).
  93. Semaphore UI, “View and export the Semaphore audit log”. URL: https://semaphoreui.com/docs/admin-guide/audit-log/view (acessado em: ).
  94. Semaphore UI, “Semaphore administrator audit-log access”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/api/audit_log.go (acessado em: ).
  95. AWX project, “AWX logging and aggregation”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/administration/logging.html (acessado em: ).
  96. Semaphore UI, “Semaphore audit log”. URL: https://semaphoreui.com/docs/admin-guide/audit-log (acessado em: ).
  97. Semaphore UI, “Ansible role and collection installation”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/db_lib/AnsibleApp.go (acessado em: ).
  98. Semaphore UI, “Task-history cleanup”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/db/sql/task.go (acessado em: ).
  99. Semaphore UI, “Ansible inventory overrides”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/services/tasks/TaskRunner.go (acessado em: ).
  100. AWX project, “Projects, Ansible Galaxy and collections”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/userguide/projects.html#ansible-galaxy-support (acessado em: ).
  101. AWX project, “Management jobs”. URL: https://docs.ansible.com/projects/awx/en/24.6.1/administration/management_jobs.html (acessado em: ).
  102. Semaphore UI, “Terraform plan and apply execution”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/db_lib/TerraformApp.go (acessado em: ).
  103. Semaphore UI, “Repository working directories”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/db/Repository.go (acessado em: ).
  104. HashiCorp, “Terraform plan command”. URL: https://developer.hashicorp.com/terraform/cli/commands/plan (acessado em: ).
  105. HashiCorp, “Terraform apply command”. URL: https://developer.hashicorp.com/terraform/cli/commands/apply (acessado em: ).
  106. Semaphore UI, “Security policy”. URL: https://github.com/semaphoreui/semaphore/security/policy (acessado em: ).
  107. AWX project, “Security policy”. URL: https://github.com/ansible/awx/security/policy (acessado em: ).
  108. AWX project, “Release status and project overview”. URL: https://github.com/ansible/awx/blob/devel/README.md (acessado em: ).
  109. Semaphore UI, “Semaphore notification channel implementation”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/services/tasks/alert.go (acessado em: ).

Comparação preparada pela equipe do Semaphore UI com base na documentação, nos repositórios e nas páginas de preços listados acima. A data de acesso é registrada para cada fonte.

Links úteis

Coloque a comparação em prática com um dos seus jobs existentes.

Instalar o Semaphore UI

Escolha um método de instalação e avalie uma das suas operações existentes.

Comparar as edições do Semaphore UI

Confira quais controles de acesso, armazenamento de segredos e execução sua equipe precisa.