Self-hosted Runner
Die Informatikdienste (ID) betreiben Self-hosted Runner für GitHub Actions, die sowohl für GitHub Enterprise Server (GHES) als auch für GitHub Enterprise Cloud (GHEC) zur Verfügung stehen. Sie laufen auf einer von der ID verwalteten Infrastruktur auf Azure und ermöglichen Workflows mit Zugriff auf die Ressourcen der Universität Bern.
Technische Grundlage
Die Self-hosted Runner basieren auf dem GitHub Actions Runner Controller (ARC), einem Kubernetes-Operator, der Runner als skalierbare Scale Sets auf einem Azure Kubernetes Service (AKS) Cluster bereitstellt.
Eigenschaften der bereitgestellten Runner:
- Jeder Job läuft in einem frischen, isolierten Container (Docker-in-Docker-Modus).
- Automatische Skalierung: Der Cluster startet bei Bedarf zusätzliche Runner und beendet sie nach Abschluss des Jobs.
- Internet- und Azure-Konnektivität ist vorhanden.
- Unterstützt Docker-basierte Jobs und Services nativ.
Verfügbarkeit
| Plattform | Runner-Label | Anmerkung |
|---|---|---|
GHES (github.unibe.ch) |
uni-runner |
Für alle GHES-Organisationen verfügbar |
GHEC (github.com) |
Organisationsspezifisch | Abhängig von der jeweiligen Organisation; bei der ID erfragen |
Für GHEC wird für jede Organisation ein eigener Runner Scale Set betrieben. Der genaue Runner-Name für die jeweilige Organisation ist über das ServicePortal erhältlich.
Verwendung im Workflow
GHES
jobs:
build:
runs-on: uni-runner
steps:
- uses: actions/checkout@v4
- name: Build
run: make build
GHEC (Beispiel)
jobs:
deploy:
runs-on: ub-runner # Runnerbezeichnung der Organisation
steps:
- uses: actions/checkout@v4
- name: Deploy
run: ./deploy.sh
Runner-Image
Das Standard-Image für die Runner wird im Repository cloud-azure-ghrunner-image gepflegt und ist öffentlich zugänglich. Es basiert auf dem offiziellen ghcr.io/actions/actions-runner-Image und enthält folgende vorinstallierte Werkzeuge:
| Werkzeug | Beschreibung |
|---|---|
| Build Essentials | gcc, make und weitere GNU-Basiswerkzeuge |
wget, zstd |
Download- und Archivierungswerkzeuge |
Azure CLI (az) |
Für Deployments auf Microsoft Azure |
| Docker Compose | Zum Starten von Multi-Container-Setups in Jobs |
Das Image wird bei jedem Merge in den main-Branch automatisch neu gebaut und veröffentlicht.
Image erweitern
Falls Workflows zusätzliche Werkzeuge benötigen, die im Standard-Image fehlen, gibt es zwei Möglichkeiten:
Option 1 – Pull Request (empfohlen für allgemeinen Bedarf):
Ein Pull Request kann im Repository cloud-azure-ghrunner-image geöffnet werden, um die benötigten Pakete oder Konfigurationen zum Dockerfile hinzuzufügen. Nach Prüfung und Merge durch die ID steht das Werkzeug allen Organisationen zur Verfügung.
Option 2 – Eigenes Image:
Es kann ein eigenes Docker-Image bereitgestellt werden, das auf dem Standard-Image basiert oder vollständig eigenständig ist. Dafür ist über das ServicePortal Kontakt mit der ID aufzunehmen, um die technische Einbindung zu klären.
Dedizierter Runner mit lokalem Netzwerkzugang
Standardmässig haben die Self-hosted Runner keinen Zugriff auf das lokale Netz der Universität Bern. Benötigt eine Organisation Workflows, die auf interne Ressourcen zugreifen müssen (z. B. interne Datenbanken, Netzlaufwerke, interne APIs), kann ein dedizierter Runner mit einer festen IP-Adresse und Anbindung an das Uninetz beantragt werden.
Dieser Runner:
- ist ausschliesslich für die anfragende Organisation reserviert,
- verfügt über eine dedizierte IP-Adresse, die ins lokale Netz der Universität eingebunden ist,
- wird von der ID konfiguriert und betrieben.
Beantragung: Über das ServicePortal ist ein Ticket zu eröffnen, in dem der Anwendungsfall sowie die benötigten Netzwerkzugriffe beschrieben werden.