Docker Compose für CI Runner: GitHub Actions/GitLab Runner self-hosted

Selbstgehostete CI-Runner, wie GitHub Actions Runner oder GitLab Runner, lassen sich effizient in Docker-Containern betreiben. Docker Compose erleichtert das Management, die Konfiguration und Skalierung dieser Runner erheblich. In diesem Tutorial erfahren Sie, wie Sie CI-Runner sicher, performant und wartbar mit Docker Compose aufsetzen.

Vorteile von Docker Compose für CI-Runner

Die Nutzung von Docker Compose bietet klare Vorteile gegenüber einzelnen Container-Starts:

• Versionierte Konfiguration in docker-compose.yml
• Einfaches Hoch- und Runterskalieren von Runner-Instanzen
• Netzwerk-Isolation zwischen Build-Umgebungen
• Persistenz von Logs und Konfigurationen über Volumes

Grundstruktur eines Compose-Files für Runner

Ein typisches docker-compose.yml für einen GitLab Runner könnte folgendermaßen aussehen:

version: "3.9"

services:
  gitlab-runner:
    image: gitlab/gitlab-runner:latest
    container_name: gitlab-runner
    restart: always
    volumes:
      - ./config:/etc/gitlab-runner
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - ci-net

networks:
  ci-net:
    driver: bridge

Erklärung der wichtigsten Punkte

• volumes: Persistente Runner-Konfiguration und Zugriff auf Docker-Socket
• restart: always: Automatischer Neustart bei Fehlern
• networks: Eigenes Netzwerk für isolierte Runner-Umgebung

GitHub Actions Runner im Compose-Setup

Auch GitHub Actions Runners können in Docker Compose betrieben werden. Beispiel:

version: "3.9"

services:
  actions-runner:
    image: myoung34/github-runner:latest
    container_name: gh-runner
    environment:
      - REPO_URL=https://github.com/IhrBenutzer/IhrRepo
      - RUNNER_NAME=runner1
      - RUNNER_TOKEN=ghp_XXXXXXXXXXXXXXXXXXXX
      - RUNNER_WORKDIR=/tmp/github-runner
    restart: always
    volumes:
      - ./runner-workdir:/tmp/github-runner
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - ci-net

networks:
  ci-net:
    driver: bridge

Wichtige Hinweise

• RUNNER_TOKEN regelmäßig erneuern und sicher aufbewahren
• Volumes für Arbeitsverzeichnisse persistent halten, um Cache und Logs zu sichern
• Docker-Socket nur für vertrauenswürdige Runner freigeben

Netzwerk-Isolation und Sicherheit

Runner sollten nur die notwendigen Services sehen können, um Builds zu erstellen, aber nicht das gesamte Host-System:

networks:
  ci-net:
    driver: bridge
    internal: true

• Option internal: true verhindert den direkten Internetzugang aus dem Netzwerk, außer über explizit definierte Gateways
• Separate Netzwerke für unterschiedliche Projekte erhöhen die Sicherheit

Persistenz von Konfigurationen und Workspaces

CI-Runner erzeugen Logs, Caches und temporäre Artefakte. Diese sollten nicht im Container selbst verbleiben:

volumes:
  - ./config:/etc/gitlab-runner
  - ./runner-workdir:/tmp/github-runner

• So bleiben Konfigurationen nach einem Update erhalten
• Artefakte können gesichert oder zwischen mehreren Runnern geteilt werden
• Bei Docker-in-Docker Builds ist der Zugriff auf den Host-Docker-Socket nötig

Healthchecks und Restart Policies

Runner sollten überwacht werden, um fehlerhafte Container automatisch neu zu starten:

healthcheck:
  test: ["CMD", "gitlab-runner", "status"]
  interval: 30s
  retries: 3
restart: always

• Markiert Container als unhealthy, wenn Healthcheck fehlschlägt
• Docker-Compose startet den Container automatisch neu

Logging und Monitoring

Persistente Logs erleichtern Debugging und Monitoring:

docker logs -f gitlab-runner

• Integration in zentrale Logging-Systeme wie Loki oder ELK ist möglich
• Wichtig für Analyse von Build-Fehlern oder Crashloops

Scaling von Runnern

Mit Docker Compose können Sie mehrere Runner einfach hochskalieren:

docker-compose up -d --scale gitlab-runner=3

• Erhöht die parallele Verarbeitung von Jobs
• Jeder Runner hat eigene Workspaces und Logs, isoliert im selben Netzwerk

Best Practices zusammengefasst

• Persistente Volumes für Konfigurationen und Workspaces
• Netzwerk-Isolation für sichere Build-Umgebungen
• Healthchecks und Restart Policies aktivieren
• Docker-Socket nur für vertrauenswürdige Runner freigeben
• Regelmäßige Updates der Runner-Images
• Logging zentralisieren und überwachen
• Skalierung über Compose --scale nutzen

Docker Compose bietet eine solide Grundlage für den Betrieb von selbstgehosteten CI-Runnern. Durch persistente Speicherung, isolierte Netzwerke, Healthchecks und Monitoring lässt sich eine sichere, stabile und skalierbare CI-Infrastruktur aufbauen, die GitHub Actions oder GitLab Runner zuverlässig ausführt.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.