forgejo-runner: give CI jobs a Docker daemon of their own

jar-lid-archive's CI needs `docker build` and `docker compose`, and job
containers had no Docker at all: config.yml carried the stock
`container.docker_host: "-"`, which is precisely "find a daemon for the
runner and do not let jobs near it".

A docker:dind sidecar now runs on forgejo-runner-box, published on
127.0.0.1 only, and jobs build against that instead of the host daemon.
Following Forgejo's own admin docs, which make the point that this is
THREE settings and not one:

  forgejo-dind.service        a privileged docker:dind on the host daemon
  container.docker_host       tcp://127.0.0.1:2376 - where the runner
                              CREATES job containers
  runner.envs.DOCKER_HOST +   tcp://forgejo-dind.docker.internal:2375 -
  container.options           how a job, from INSIDE dind, reaches it

The third is the one that is easy to miss and fails identically to
having done nothing: for a tcp:// docker_host the runner mounts nothing
into the job container, so the job still finds no daemon. The two
addresses differ because they are used from different places - the
runner is a process on the host; a job container is inside dind, where
127.0.0.1 is itself. `host-gateway` is expanded by the daemon creating
the container, which is dind, so it lands on dind's own bridge gateway.

Verified on the box, along the exact path a job takes - a container on a
user-defined network, with the same --add-host and DOCKER_HOST the
runner will set: the name resolves to 172.20.0.1, `docker version`
returns the dind server, and `docker build` succeeds. The host daemon
runs forgejo-dind and nothing else.

config.yml had to become a template to do any of this. It was previously
`generate-config` run once on first deploy and never touched again, so
the repo had no say in its contents. Every value was transcribed from
the live file and diffed against it key by key: with dind disabled, 30
of 30 identical. Two deliberate differences - runner.envs drops
A_TEST_ENV_NAME_1/2, upstream's placeholders, which were being injected
into every job here; and the upstream comment blob is gone. Because the
file is managed now it also gets a restart handler, the absence of which
has bitten this repo before.

Things deliberately chosen rather than defaulted into:

- the flag lives in the playbook, not the role defaults, so the role's
  default stays the configuration this host has always run and turning
  it off is one line. Disabling it also tears the units down rather than
  just skipping them.
- dind is a hard Requires= of forgejo-runner, and its unit stays in
  "activating" until the daemon answers. A dead dind is then one red
  unit instead of a green runner failing every job it claims.
- the healthcheck and monitored_services learned about dind for the same
  reason: runner up + dind down is the interesting failure and it was
  previously invisible.
- /var/lib/docker is a named volume, or every image is re-pulled on each
  container recreation; a weekly prune keeps that from growing forever.
- dind's network pool is pinned to 172.20.0.0/14. Docker's stock pool
  reaches into 192.168.x, and act_runner creates a network per job, so a
  job could eventually allocate this LAN's subnet and lose the route to
  every box on it.

Note this runner is SHARED - arbret, arbret-biz, arbretdos and
arbret-ops build here too, far more often, and docker_host is per-runner
not per-repo. Their workflows are unchanged but their next run pulls
images into a cold cache. Job images still need a docker client of their
own: node:{20,22}-bookworm ship none.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-27 22:32:08 +02:00

2.1 KiB

Raw Blame History

Forgejo Runner Setup

Obtaining the Registration Token

Log in to the Forgejo instance at https://forgejo.contrapeso.xyz
Go to Site Administration > Actions > Runners
Click Create new runner
Copy the registration token

Configuring the Token

Paste the token into ansible/infra_secrets.yml:

forgejo_runner_registration_token: "YOUR_TOKEN_HERE"

Running the Playbook

ansible-playbook ansible/services/forgejo-runner/deploy_forgejo_runner_playbook.yml

Verifying

On the VM: systemctl status forgejo-runner should show active
In Forgejo: Site Administration > Actions > Runners should show the runner as online
~~In Uptime Kuma: the forgejo-runner-healthcheck push monitor should be receiving pings~~ (Uptime Kuma was decommissioned 2026-09-11 — this check no longer applies. The healthcheck timer still runs on the host but pushes nowhere. See archive/uptime_kuma/.)

Docker in CI jobs

Jobs get their own Docker daemon (a docker:dind sidecar), not this host's. Enabled by forgejo_runner_dind_enabled in the deploy playbook; the mechanism, the trade-offs and how to turn it off are in ansible/roles/forgejo_runner/README.md.

A workflow needs no special configuration — DOCKER_HOST is already set in every job container:

jobs:
  build:
    runs-on: docker
    steps:
      - uses: actions/checkout@v7
      - run: docker build -t my-app .
      - run: docker compose up -d --wait

Verifying after a deploy:

systemctl status forgejo-dind — active, and docker -H tcp://127.0.0.1:2376 version answers from the box.
docker ps on the host shows forgejo-dind and, during a run, no job containers: they are inside dind now. docker exec forgejo-dind docker ps shows those.
A workflow step running docker version reports the dind daemon.

One caveat worth knowing before writing an end-to-end job: a docker compose bind mount resolves on the dind filesystem, not in the job container, so a compose file that mounts the checked-out repo will not see it. Named volumes and build: contexts work normally.

2.1 KiB Raw Blame History