runner serve
Inicia o servidor de triggers para receber webhooks e/ou executar o canary scheduler.
Sintaxe
runner serve [OPTIONS]Opcoes
| Opcao | Tipo | Default | Descricao |
|---|---|---|---|
--service |
flag | false |
(v2.2.0) Service mode: le service.yml, inicia API HTTP + scheduler generico |
--mode |
string | auto |
Modo de operacao legacy: auto, webhook, cron, both |
--port |
integer | 8080 |
Porta do webhook server (legacy) |
--path |
string | /webhook |
Path do endpoint webhook |
--secret |
string | - | Secret para verificacao HMAC (ou env WEBHOOK_SECRET) |
--tick-interval |
integer | 60 |
Intervalo em segundos do canary scheduler |
Nota v2.2.0: em service mode (
--service), port/mode/secret vem doservice.ymle nao dos argumentos CLI.
Modos de Operacao
| Modo | Comportamento |
|---|---|
auto |
Inicia webhook se secret configurado, senao apenas cron |
webhook |
Apenas webhook server |
cron |
Apenas canary scheduler |
both |
Webhook e cron simultaneamente |
Exemplos
Auto-detectar Modo
runner serveSe WEBHOOK_SECRET estiver definido, inicia webhook + cron. Senao, apenas cron.
Apenas Webhook Server
runner serve --mode webhook --port 9000Apenas Canary Scheduler
runner serve --mode cron --tick-interval 30Ambos
runner serve --mode both --port 8080 --tick-interval 60Com Secret via Argumento
runner serve --secret "meu_secret_aqui"Com Secret via Variavel de Ambiente
export WEBHOOK_SECRET="meu_secret_aqui"
runner serveWebhook Server
O webhook server escuta eventos de push do GitHub/GitLab/Bitbucket.
Endpoints
| Endpoint | Metodo | Descricao |
|---|---|---|
/health |
GET | Health check do servidor |
/webhook |
POST | Recebe eventos webhook |
Eventos Suportados
| Evento | Acao |
|---|---|
push |
Verifica se e para branch dist, aciona deploy |
ping |
Responde OK (teste de conexao) |
Headers Esperados
| Header | Descricao |
|---|---|
X-Hub-Signature-256 |
Assinatura HMAC-SHA256 (GitHub) |
X-GitHub-Event |
Tipo de evento (push, ping, etc) |
Payload GitHub
{
"ref": "refs/heads/dist",
"repository": {
"full_name": "usuario/repo",
"name": "repo"
},
"pusher": {
"name": "usuario"
},
"after": "abc123..."
}Verificacao de Assinatura
Se secret estiver configurado, o servidor verifica a assinatura HMAC-SHA256:
- Calcula HMAC-SHA256 do body com o secret
- Compara com o header
X-Hub-Signature-256 - Rejeita se nao corresponder (401 Unauthorized)
Canary Scheduler
O canary scheduler executa periodicamente (a cada tick-interval segundos) e:
- Le estado dos canary deployments ativos
- Verifica health checks
- Incrementa peso se configurado para auto-promote
- Executa rollback se condicoes de abort forem atingidas
Estado do Scheduler
O estado e persistido em /opt/runner/state/canary/:
# /opt/runner/state/canary/meu-app_production.yml
project: meu-app
instance: production
stable_version: v1.2.3
canary_version: v1.2.4
current_weight: 30
state: running
started_at: "2026-02-16T14:00:00Z"
last_step_at: "2026-02-16T14:10:00Z"
next_step_at: "2026-02-16T14:15:00Z"Logs do Scheduler
# Ver logs em tempo real
tail -f /opt/runner/logs/canary-scheduler.log
# Ou via journalctl se rodando como servico
journalctl -u runner-serve -fConfiguracao via config.yml
O comando serve le configuracoes do config.yml:
# /opt/runner/config.yml
triggers:
mode: auto
webhook:
enabled: true
port: 8080
path: /webhook
secret: "${WEBHOOK_SECRET}"
cron:
enabled: true
canary_tick_interval: 60Argumentos da CLI sobrescrevem o config.yml.
Service Mode (v2.2.0+)
A forma recomendada de rodar o serve em producao e via service mode:
runner service init --port 9090 # Gera service.yml + systemd unit
runner service start # Inicia
runner service status # VerificaO service mode le /opt/runner/service.yml e inicia:
- API HTTP com auth via X-API-Key (endpoints: /health, /api/v1/status, signal, deploy, apps)
- Scheduler generico com jobs configuraveais (canary, ttl_cleanup, signal_check)
- mTLS opcional (v2.3.0) com hot-reload de CA cert
Ver service.yml reference para configuracao completa.
API Endpoints (v2.2.0)
| Endpoint | Metodo | Auth | Descricao |
|---|---|---|---|
/health |
GET | Nenhuma | Health check |
/api/v1/status |
GET | X-API-Key | Scheduler jobs + status |
/api/v1/signal/{app} |
POST | X-API-Key | Signal externo (CI/CD) |
/api/v1/deploy/{app} |
POST | X-API-Key | Trigger deploy |
/api/v1/apps |
GET | X-API-Key | Listar apps |
mTLS (v2.3.0)
Quando habilitado, conexoes sem client certificate valido sao rejeitadas no TLS handshake. O CA cert e recarregado automaticamente do disco quando o arquivo muda (hot-reload via mtime).
runner service config --ca-cert /path/to/ca.pem
runner service restartModo Legacy (compatibilidade)
O modo legacy (sem --service) continua funcionando como antes:
Systemd (legacy)
# /etc/systemd/system/runner-serve.service
[Unit]
Description=Runner Webhook/Cron Server
After=network.target docker.service
[Service]
Type=simple
ExecStart=/opt/runner/runner serve
WorkingDirectory=/opt/runner
Environment=WEBHOOK_SECRET=seu_secret_aqui
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.targetConfigurando GitHub Webhook
- Acesse Settings → Webhooks no repositorio
- Clique em "Add webhook"
- Configure:
- Payload URL:
https://seu.servidor.com:8080/webhook - Content type:
application/json - Secret: Mesmo valor do
WEBHOOK_SECRET - Events: Just the push event
- Payload URL:
- Clique em "Add webhook"
Testando
Health Check
curl http://localhost:8080/healthResposta esperada:
{"status": "healthy", "version": "1.2.0"}Simular Webhook
# Gerar assinatura
PAYLOAD='{"ref":"refs/heads/dist","repository":{"full_name":"user/repo"}}'
SIGNATURE=$(echo -n "$PAYLOAD" | openssl dgst -sha256 -hmac "seu_secret" | cut -d' ' -f2)
# Enviar
curl -X POST http://localhost:8080/webhook \
-H "Content-Type: application/json" \
-H "X-Hub-Signature-256: sha256=$SIGNATURE" \
-H "X-GitHub-Event: push" \
-d "$PAYLOAD"Exit Codes
| Codigo | Significado |
|---|---|
| 0 | Encerrado normalmente (Ctrl+C) |
| 1 | Erro de configuracao |
| 2 | Porta ja em uso |