Deploy em produção

npm run fleet:up                        # frota anônima, connectors synthetic
RUNNER_TENANT=<slug> npm run fleet:up   # frota de um tenant, connectors real

O fleet:up aplica docker-compose.fleet.yml como sobreposição do Compose de desenvolvimento. Cada diferença entre os dois existe por um motivo específico.

O que muda, e por quê

O túnel

wss://tunnel.rootpilot.sh:8443 é a porta do túnel dos runners. Outras portas e hostnames do control-plane não conectam runner.

Hostname certo ≠ porta aberta

O certificado do túnel tem SAN DNS:tunnel.rootpilot.sh. Conectar por outro hostname, mesmo que resolva para o mesmo IP, falha a verificação de hostname do TLS com is not in the cert's altnames. Quem manda é o SAN do certificado.

Nada de dev-certs

A sobreposição redefine os volumes com !override, e não por estética: o Compose mescla listas de volume, então redefinir sem !override manteria o dev-certs/ montado. E aí o entrypoint setaria RUNNER_CERT_PEM a partir da CA de desenvolvimento, o runner pegaria o atalho de certificado provisionado em vez de enrolar, e o mTLS falharia contra a CA de produção com um erro que não diz nada disso.

O ~/.aws permanece montado: é o que sustenta RUNNER_AWS_CRED_MODE=chain.

restart: "no"

Conectar na produção é ato deliberado. Um runner que se reergue sozinho depois de um docker compose down mal dado vira presença fantasma no Fleet de um tenant real.

O que RUNNER_TENANT faz: e o que não faz

Não escolhe o tenant. Quem crava isso é o bootstrap token, que é mintado por tenant e cujo enrollment devolve um certificado com o SPIFFE id do tenant dentro. Slug errado aqui não conecta você na organização errada.

Faz duas coisas: escolhe a pasta de credenciais no cofre (/rootpilot/edge/<slug>) e liga RUNNER_CONNECTORS=real. A segunda é de propósito: subir “a frota da organização X” com dados sintéticos é um no-op que parece ter funcionado, e essa é a classe de falha mais cara que este produto tem.

Nota de postura

Isto não é o caminho BYOC

O fleet:up sobe runners fora da infra-alvo. É útil para desenvolvimento e prova de conceito, mas é o oposto da premissa do produto, que é runner na infra do cliente, segredo que nunca sai de lá. Para valer, o runner roda onde as credenciais já moram.

Para o caminho BYOC de verdade, o que muda é onde o container roda e como ele prova identidade:

• Identidade sem humano: troque bootstrap-token por uma identidade de nuvem: RUNNER_ATTESTATION_MODE=aws-sts em EC2/EKS, gke-oidc em GKE. Veja Atestação.
• Segredos do seu cofre: RUNNER_SECRET_STORE_MODE=aws ou vault, em vez de env. Veja Secret stores.
• Credenciais de nuvem pela cadeia default: RUNNER_AWS_CRED_MODE=chain (IRSA, instance profile) em vez de chaves estáticas. Veja Credenciais de nuvem.

Renovação de certificado

O certificado de enrollment vale 1 hora. RUNNER_CERT_RENEWAL=on é o default e é o que mantém uma frota cattle viva sem intervenção humana. Sem ele, cada runner tem prazo de validade de uma hora e só um humano mintando bootstrap token o traz de volta.

A renovação exige um control-plane com o verificador. Contra um control-plane anterior a ele, a renovação falha, o runner degrada para o comportamento antigo (expira em 1h) e loga cert renewal failed em vez de morrer calado.

Quando a identidade morre de vez

Se o certificado passar do ponto de recuperação, o runner não volta sozinho, porque a atestação de renovação prova posse com o certificado que expirou. O processo então sai, para que o supervisor suba um runner novo que enrolla do zero.

Isso é deliberado: sem essa saída, o processo viraria zumbi: de pé, sem servir, e invisível para qualquer probe, já que o runner é cliente de saída e não tem endpoint de health.

Garanta que o seu supervisor (restart do Compose, ReplicaSet, serviço de ECS) esteja configurado para subir o substituto.