Execute trabalhos entre redes por uma interface

Runners globais são registrados para uso na instância inteira, enquanto runners de projeto pertencem a um projeto específico. Execução distribuída global está disponível em todos os planos; escopo de projeto e roteamento relacionado estão incluídos no Pro e Enterprise, conforme os preços. Escolha o escopo segundo a responsabilidade operacional e o acesso ao ambiente. Um runner específico de projeto ajuda a definir deliberadamente o local, mas sua configuração de runtime continua determinando o que o processo pode acessar.

O runner inicia a comunicação conectando ao Semaphore e consultando trabalhos. Isso permite localização atrás de NAT ou em rede privada sem conexão de entrada iniciada pelo servidor. Ainda precisa alcançar o endpoint Semaphore e os repositórios, pacotes, serviços externos e destinos usados. Confira cada caminho: consultas de saída não eliminam outros requisitos de rede.

Use tags compatíveis, requisito do modelo e padrões de runner para escolher o ambiente apropriado. Nomeie tags por capacidade ou local significativo e deixe disponibilidade e capacidade visíveis. Sem runner adequado pronto, a tarefa pode aguardar. Teste a rota com operação inofensiva e confirme o runner nos detalhes antes de usar o caminho para mudanças de produção.

Não por si só. Um executor local usa o contexto de processo do host runner e os acessos desse ambiente. Docker ou Kubernetes introduzem outro limite, mas montagens, privilégios, rede e conteúdo das imagens continuam importantes. Decida localização e modo de execução separadamente. Prepare dependências e revise o acesso ao host, sem tratar runner ou contêiner como garantia completa de segurança.

Prepare o runtime exigido por cada trabalho no caminho selecionado. Imagens de executor compatíveis ajudam a explicitar um conjunto específico de Ansible, Terraform, Python ou outras dependências sem alterar todos os trabalhos do host compartilhado. Confira versão e edição instaladas para as opções relevantes. Teste acesso ao repositório, pacotes e conectividade aos destinos dentro do ambiente real, não apenas na sessão interativa de um administrador.

Adicionar runners amplia ou muda o local de execução das tarefas; isso não cria um plano de controle da aplicação com alta disponibilidade. A HA da aplicação usa vários nós Semaphore coordenados, com a arquitetura documentada de banco de dados compartilhado, Redis e balanceamento de carga. Essas capacidades podem se complementar, mas resolvem problemas diferentes. Determine se o gargalo é capacidade de execução, alcance de rede ou acesso à UI e à API antes de escolher qual parte ampliar.

A tarefa aguarda até um runner disponível corresponder aos requisitos de roteamento do modelo. Confira tag, habilitação e conexão recente do runner e depois a capacidade. Uma tag é uma regra de seleção; um runner sem tag ou com outra não assume automaticamente o trabalho.

Sim. Um modelo pode substituir a imagem padrão quando o runner usa executor Docker no Pro ou Kubernetes no Enterprise. Assim, trabalhos usam as ferramentas necessárias. Prepare aplicações e dependências na imagem; o campo não muda o executor local. Veja configurações de execução do modelo.