Runner-Maschinen

Windows-, macOS- und self-hosted-Jobs auf Maschinen, die Sie registrieren.

Manche Jobs können nicht im Cluster laufen. Ein Windows-Container braucht den NT-Kernel und existiert auf einem Linux-Host überhaupt nicht, und macOS lässt sich nicht containerisieren — für windows-latest und macos-latest gibt es also nirgends einen Pod. Sie registrieren die Maschine, und die Plattform erreicht sie per SSH.

Wann Sie eine brauchen#

Ein Job, dessen Labels zu keiner Maschine passen, scheitert sofort, statt am falschen Ort zu laufen, und seine Annotation nennt, was fehlt: keine Maschine für dieses OS, eine Maschine im Draining oder ein Label, das keine hat. Der Run scheitert, statt Erfolg für Arbeit zu melden, die nie gebaut wurde.

Eine Maschine registrieren#

Gehen Sie zu Einstellungen → Plattform → Runner-Maschinen und klicken Sie auf Maschine registrieren. Sie geben an, was die Maschine ist: Adresse, das Konto, unter dem die CI läuft, Betriebssystem, Architektur und wie viele Jobs sie gleichzeitig annimmt.

Nach einem Private Key werden Sie nie gefragt. Die Plattform erzeugt ein ed25519-Paar, verschlüsselt die private Hälfte im Ruhezustand mit derselben Chiffre wie die Secrets und zeigt Ihnen nur die öffentliche.

Den Key installieren#

Der Bildschirm liefert den Befehl für das Betriebssystem genau dieser Maschine, denn das Ziel unterscheidet sich wirklich.

Unter Linux und macOS die übliche Stelle:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo 'ssh-ed25519 AAAA… eqs-mac-mini-1' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Unter Windows nicht diese Stelle. Für jedes Konto in der Gruppe Administrators liest OpenSSH eine maschinenweite Datei und ignoriert ~/.ssh/authorized_keys vollständig:

Add-Content -Path "$env:ProgramData\ssh\administrators_authorized_keys" -Value 'ssh-ed25519 AAAA… eqs-win-runner-1'
icacls "$env:ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F"

Die Verbindung testen#

Testen öffnet eine Sitzung und fragt die Maschine, was sie ist. Ein Roundtrip beantwortet drei Fragen: SSH funktioniert, eine POSIX-Shell ist vorhanden, und welche Maschine das wirklich ist.

Eine unter dem falschen Betriebssystem registrierte Maschine besteht den Test nicht und sagt warum. Das ist kein Verbindungsproblem und schlimmer als eines: das Routing schickte windows-latest-Jobs auf eine Linux-Kiste, und jeder scheiterte an einem Befehl, den es dort nicht gibt — ohne dass irgendetwas auf die Registrierung zurückwiese.

Schlägt ein Test fehl, bekommen Sie den Grund im Wortlaut — ssh: connect to host 10.0.0.42 port 22: Operation timed out — statt eines allgemeinen Fehlers. Eine nie erreichte Maschine sagt genau das, und das ist etwas anderes als unerreichbar.

Was die Maschine braucht#

• Einen SSH-Server und ein Konto ohne Privilegien, unter dem die CI läuft.
• Eine POSIX-Shell. Unter Windows ist das Git for Windows, dessen bash.exe als DefaultShell von OpenSSH gesetzt ist — jeder Step läuft darüber.
• git und tar, die Git for Windows bereits mitbringt.

Sonst nichts. Die Node-Runtime, die JavaScript-Actions brauchen, legt die Plattform selbst ab — gebaut für Betriebssystem und Architektur genau dieser Maschine — beim ersten Job, der dort läuft.

Entleeren und entfernen#

Entleeren beendet die laufenden Jobs und nimmt keine neuen an: der Zustand für einen Neustart oder ein Update der Maschine. Entfernen lässt die Plattform sie vergessen.

Die Isolation ist schwächer als ein Container#

Das sei deutlich gesagt. Ein Job auf einer registrierten Maschine sieht, was der vorige Job außerhalb seines Workspace hinterlassen hat: das Home-Verzeichnis, /tmp, installierte Pakete, den Zustand jedes Daemons. Ein Container gibt jedes Mal ein frisches Root, das hier nicht.

Was abgemildert ist: das Konto hat keine Privilegien, der Workspace gehört einem einzelnen Job, und das Aufräumen verweigert jeden Pfad außerhalb des Arbeitsverzeichnisses. Nutzen Sie eine registrierte Maschine für Arbeit, die Sie auch auf einer geteilten Build-Box unbesorgt laufen ließen.