Runner do Gitea (act_runner)

Runner que executa a esteira build-api-image.yml. Sobe em um servidor separado do Gitea — o Gitea fica em 192.168.0.41:3001 e este compose roda na máquina que vai construir as imagens.

Instalação

cp .env.example .env

Pegue o token de registro no Gitea e cole em GITEA_RUNNER_REGISTRATION_TOKEN:

Escopo do runner	Onde pegar o token
Só o repositório conectasus	Repo › Settings › Actions › Runners › Create new runner
Toda a organização `rkm`	Org › Settings › Actions › Runners
Instância inteira	Site Administration › Actions › Runners

Depois:

docker compose up -d
docker compose logs -f

O runner aparece como online em Settings › Actions › Runners do Gitea. O token de registro é usado uma única vez; a credencial permanente fica em ./data/.runner.

O que o compose faz

Item	Motivo
`/var/run/docker.sock` montado	O `act_runner` usa o daemon do host para criar os containers de job e repassa o socket para dentro deles. É isso que faz o `docker build` da esteira funcionar.
`./data`	Guarda o registro do runner. Apagar essa pasta força novo registro.
Label `ubuntu-latest:docker://gitea/runner-images:ubuntu-latest`	Casa com o `runs-on: ubuntu-latest` do workflow. Essa imagem (0,57 GB) já traz `docker`, `git`, `node`, `bash` e `curl` — tudo que a esteira usa. A variante `-full` tem 17,6 GB e não é necessária.

Como o Gitea está em outro servidor, tudo que aponta para ele é configuração: GITEA_INSTANCE_URL e o token vêm do .env, nada fixo no compose. Se as variáveis obrigatórias faltarem, o docker compose up falha na hora com a mensagem em vez de subir um runner quebrado.

Pré-requisitos no servidor do runner

1. Alcançar o Gitea. O runner e os containers de job precisam falar com 192.168.0.41:3001 (API do Actions e registry de imagens):

curl -s http://192.168.0.41:3001/api/v1/version

2. Confiar no registry via HTTP. O registry não tem TLS, e o docker push da esteira roda no daemon do host (por causa do socket montado). Então a configuração é do host, não do compose — em /etc/docker/daemon.json:

{ "insecure-registries": ["192.168.0.41:3001"] }

Se o arquivo já existir, acrescente ao array em vez de sobrescrever. Depois:

systemctl reload docker
docker info | grep -A5 'Insecure Registries'

Use reload, não restart. insecure-registries é recarregável por SIGHUP, e restart derruba todos os containers do host quando live-restore está desligado (confira com docker info --format '{{.LiveRestoreEnabled}}').

Sem isso o push falha com http: server gave HTTP response to HTTPS client.

3. Espaço em disco. Cada build gera uma imagem da API com o vendor/ completo. Convém uma limpeza periódica:

docker image prune -af --filter "until=168h"

Mudando o runner de máquina

O compose não tem nada preso à máquina: o Gitea é alcançado por GITEA_INSTANCE_URL, que vem do .env. Para mover o runner basta subir o compose no servidor novo e registrar de novo.

Na fase inicial de desenvolvimento é natural rodar na própria máquina de dev. Duas ressalvas quando esse host também roda outros containers:

Um restart do daemon Docker (necessário se você usar restart em vez de reload para o insecure-registries) derruba tudo que estiver no host.
Os builds competem por disco e CPU com os containers já existentes.

Ao migrar para o servidor do Gitea, o registro anterior deve ser removido em Settings › Actions › Runners, e a pasta ./data do host antigo descartada. GITEA_INSTANCE_URL pode continuar apontando para o IP — não precisa virar localhost.

Notas

Se o Gitea for acessado por hostname em vez de IP e o servidor do runner não resolver esse nome, acrescente extra_hosts ao serviço no compose.
Por padrão o runner executa um job por vez. Para paralelismo, monte um config.yaml com runner.capacity e aponte CONFIG_FILE para ele.
O socket do Docker montado dá ao runner controle total sobre o daemon do host. Use um servidor dedicado a CI, não um que rode containers de produção.

4.2 KiB Raw Blame History Unescape Escape