Runners do Semaphore UI explicados: implantações mais rápidas, melhor isolamento, menores custos na nuvem

O que e um runner? #

Um runner do Semaphore UI e uma instancia independente do Semaphore sem interface grafica. Ele se conecta ao seu servidor principal do Semaphore, recebe tarefas e as executa. Os runners podem ser hospedados em servidores separados, em qualquer regiao ou rede, totalmente independentes de onde sua interface do Semaphore estiver.

Que problema ele resolve? #

Sem runners, todas as suas tarefas de automacao rodam em um unico servidor. Isso funciona bem no comeco, mas, a medida que sua equipe, ou o numero de equipes, cresce, tres problemas costumam aparecer:

• Carga. Uma fila grande de tarefas competindo pelos recursos de um unico servidor deixa tudo mais lento.
• Isolamento. Quando varias equipes compartilham o mesmo ambiente de execucao, um pipeline com problema pode afetar todo mundo.
• Geografia. O Ansible se conecta aos seus servidores por SSH. Se sua infraestrutura estiver em Sydney, mas sua instancia do Semaphore estiver em Frankfurt, cada deploy passa por uma conexao intercontinental. Os runners resolvem os tres problemas.

Runners globais vs. runners de projeto #

O Semaphore oferece dois tipos de runners, e a diferenca importa se voce estiver avaliando o plano Pro.

Recurso	Runners globais (OSS)	Runners de projeto (Pro)
Disponivel em	OSS (gratuito)	Pro
Distribuicao de carga	✅	✅
Isolamento de rede	❌	✅
Roteamento por tags	❌	✅
Controle por projeto	❌	✅

Os runners globais sao atribuídos aleatoriamente entre todos os projetos. Sao otimos para distribuir carga, mas voce nao consegue controlar qual runner vai executar qual tarefa. Os runners de projeto permitem anexar uma tag a qualquer template ou inventario e, depois, encaminhar tarefas especificas para runners especificos. E isso que viabiliza o isolamento e o roteamento geografico.

3 casos reais de uso para runners #

1. Varios times, zero interferencia Seu time de plataforma e seu time de produto usam o Semaphore. Eles trabalham de forma independente - projetos diferentes, servidores diferentes, tolerancias a risco diferentes. Com runners de projeto, cada time ganha seu proprio runner. Se o runner de um time cair, o outro nem percebe.

2. Infraestrutura distribuida em varias regioes Seu site roda em um data center em Nova York. Um servico de backend roda na Australia. Com um unico runner centralizado na Europa, cada deploy atravessa o planeta via SSH - lento e desnecessario.

   Configure um runner em Nova York e outro na Australia. Marque seus inventarios com as tags correspondentes. Agora cada tarefa se conecta localmente, dentro da mesma rede, na velocidade maxima. Deploys mais rapidos e uma superficie de ataque menor como bonus.

3. Reduzindo custos na nuvem com webhooks + AWS Lambda Vale a pena ir com calma aqui, porque esta e uma otimizacao de custos relevante. Os runners oferecem suporte a webhooks em dois eventos: inicio da tarefa e fim da tarefa. Voce pode usar isso para ligar e desligar recursos na nuvem automaticamente.

   A configuracao e a seguinte: seu runner roda em uma instancia AWS EC2. Quando esta ligado, custa dinheiro. Quando esta desligado, nao custa nada.

   • No inicio da tarefa -> um webhook aciona uma funcao Lambda -> a Lambda inicia a instancia EC2 -> o runner fica online, conecta ao Semaphore e executa a tarefa
   • No fim da tarefa -> outro webhook aciona outra Lambda -> a Lambda desliga a instancia EC2

   Seu runner so fica ligado quando esta realmente trabalhando. Para equipes com cargas esporadicas, so isso ja pode justificar o plano Pro.

Como configurar um runner de projeto #

1. Va ate as configuracoes do projeto e abra a aba Runners. Voce vera todos os runners existentes ali.

2. Clique em New Runner. Dê um nome e uma tag - por exemplo, new-york.

3. Depois de salvar, o Semaphore gera duas credenciais: um token, armazenado nos dois lados e usado para identificacao, e uma chave privada, armazenada apenas no runner e usada para criptografar os dados em transito. Baixe a chave privada - voce vai precisar dela no proximo passo.

4. Implante o runner no servidor de destino. A forma mais facil e usar Docker:

   docker run \
   -e SEMAPHORE_WEB_ROOT=https://semaphore.example.com \
   -e SEMAPHORE_RUNNER_TOKEN=/ADwjSWmWV8FZB4pwQaaEOWgqIdOR+oDOeOXe2a3JD0= \
   -e SEMAPHORE_RUNNER_PRIVATE_KEY_FILE=/config.runner.key \
   -v "/path/to/private/key:/config.runner.key" \
   -d semaphoreui/runner:v2.17.28
   

   Como alternativa, use o comando de configuracao interativa:

   semaphore runner setup
   

5. De volta ao Semaphore, abra qualquer Template ou Inventory e atribua a ele a tag do runner new-york. Essa tarefa passara a ser executada sempre no seu runner de Nova York.

Marcando inventarios, nao apenas templates #

Existe uma maneira mais inteligente de encaminhar tarefas quando voce tem servidores agrupados por regiao ou rede. Em vez de marcar cada template individualmente, voce pode atribuir uma tag de runner diretamente a um inventario.

Um inventario no Semaphore e uma lista de enderecos IP que o Ansible usa para se conectar aos seus servidores. Se voce sabe que um determinado grupo de servidores esta em Nova York, marque esse inventario com new-york. A partir desse momento, qualquer template que usar esse inventario sera executado automaticamente no runner de Nova York, sem precisar de configuracao por template.

Isso e especialmente util quando voce esta adicionando novos templates. Voce escolhe o inventario certo e o roteamento do runner simplesmente funciona.

Mais uma coisa: limites de concorrencia #

Se quiser limitar a concorrencia, defina um numero maximo de tarefas paralelas por runner. O padrao e ilimitado (0). Se voce definir 5 e esse runner ja estiver ocupado, o Semaphore enviara a tarefa para outro runner com a mesma tag.

Pronto para testar? #

Os runners de projeto estao disponiveis no plano Semaphore Pro. Se sua equipe estiver enfrentando algum dos cenarios acima - filas de tarefas crescendo, varios times ou infraestrutura distribuida - vale a pena explorar.