Giteas act_runner: Startprobleme

2 Minuten Lesezeit

Das Problem

Seitdem ich diese Seite in Eigenregie betreibe, habe ich nach Neustart des Gitea-Containers das Problem, dass der aktivierte act_runner manchmal nicht mit hochfährt. Er bricht dann unter Angabe von Status Code -1 ab und meine Workflows werden nicht abgearbeitet, sodass ich z.B. keine Artikel bauen oder veröffentlichen kann.

Die Fehlermeldung ist immer dieselbe:

[...]
runner-1  | time="2024-08-26T10:09:46Z" level=info msg="Starting runner daemon"
runner-1  | time="2024-08-26T10:09:46Z" level=error msg="fail to invoke Declare" error="unavailable: 502 Bad Gateway"
runner-1  | Error: unavailable: 502 Bad Gateway
runner-1 exited with code 1
gitea     | 2024/08/26 10:09:46 cmd/web.go:242:runWeb() [I] Starting Gitea on PID: 16

Der Runner kann sich also nicht bei Gitea einklinken. Wenn ich alle Services über Docker per docker restart erneut starte, meint der Container für act_runner, ihm fehle dafür ein Netzwerk mit ID <ellenlanger Hexcode hier>.

Die kurzfristige Lösung

Ich hatte die letzten Monate keine Zeit dem nachzugehen. Daher half ich mir stets damit, folgendes doppelt auszuführen:

# schallbert server-console
docker compose -f /path/to/giteas/composefile up -d

Beim zweiten Anlauf dann lief der Runner wiederholbar erfolgreich an (Gitea war ja schon betriebsbereit):

gitea     | 2024/08/26 10:38:17 routers/init.go:116:InitWebInstalled() [I] Git version: 2.45.2 (home: /data/gitea/home)
runner-1  | time="2024-08-26T10:38:22Z" level=info msg="Starting runner daemon"
runner-1  | time="2024-08-26T10:38:22Z" level=info msg="runner: action-runner, with version: v0.2.10, with labels: [ubuntu-latest], declare successfully"
runner-1 exited with code 0
runner-1  | time="2024-08-26T10:40:32Z" level=info msg="Started runner daemon"

Dies ist natürlich nicht so schön und muss händisch von mir gemacht werden. Doch was ist die Ursache?

Ursachenforschung

Zuerst hatte ich den Reverse Proxy von Caddy im Verdacht, da er Gitea an das Internet anbindet. Doch tatsächlich ist Gitea selbst das Problem: Es ist zum Zeitpunkt, zu dem Docker den runner Container startet, noch gar nicht fertig hochgefahren. Also lese ich nach, wie ich Abhängigkeiten in Docker besser darstellen kann.

Lösung: Abhängigkeiten abbilden

Zuerst versuche ich es mit dem Einbinden der Änderung in docker compose.

depends_on

# gitea/docker-compose.yml
  ## service: runner
  ## [...]
    depends_on:
      gitea:
        condition: service_started

Doch noch immer startet der act_runner wohl zu früh. Docker stellt hier nämlich lediglich sicher, dass Gitea gestartet wurde, nicht aber, dass es hochgefahren ist und stabil läuft.

Healthcheck

Ich muss folglich sicherstellen, dass Gitea betriebsbereit ist. Dies geht prima mit der Bedingung service_healthy. Ich passe also die Instruktionen für den Runner wie folgt an:

# gitea/docker-compose.yml
  ## service: runner
  ## [...]
    depends_on:
        gitea:
            condition: service_healthy # required so runner can attach to gitea
            restart: true

Der service_healthy Qualifier ist ein Rückgabewert der healthcheck Funktion. Diese besteht aus einem sogenannten test und ein paar Begleitparametern, in welchem Intervall wie oft und nach welcher Zeit geprüft werden soll, ob der Dienst nun betriebsbereit ist.

Ich habe als Test ein einfaches Kommando gewählt mit der Annahme, dass Gitea (und damit implizit auch Caddy) fertig hochgefahren ist, sobald curl seine Webseite aufrufen kann.

# gitea/docker-compose.yml
## service: gitea
## [...]
    healthcheck:
        test: ["CMD", "curl", "-f", "https://git.schallbert.de/"] # checks if gitea is available
        interval: 10s
        retries: 3
        start_period: 30s
        timeout: 10s

Mit diesen Zeilen prüft Docker, ob Gitea “healthy” ist und startet den act_runner entsprechend später. Das oben dargestellte Problem ist auf meinem Server seitdem komplett behoben und Gitea sowie runner verhalten sich zuverlässig und stabil.

You May Also Enjoy