Wähle zunächst Region, Modell und Laufzeit. Richte danach Zugangsdaten, SSH, grafischen Desktop und den ersten Xcode-Build ein. Halte jeden Status nachvollziehbar fest.
Bei der Auswahl zählt nicht nur der Chip. Region, Zugriffsart, Toolchain-Versionen und Verantwortlichkeiten beeinflussen die erste Stunde nach der Bereitstellung.
Wähle zwischen Singapur, Japan (Tokio), Südkorea (Seoul) und Hongkong die Region mit der passenden Nähe zu Entwicklerinnen und Entwicklern oder dem Artefaktspeicher. Berücksichtige auch die Netzwerkwege zu Repository und Abhängigkeiten.
SG · JP · KR · HKFür leichte Builds ist Orb M4 16 ein guter Einstieg. Größere Abhängigkeitsgraphen und parallele Aufgaben eignen sich für Orb M4 24; für speicherintensive Builds oder lokale KI-Experimente wählst du Orb M4 Pro.
3 KonfigurationenFür kurzfristige Tests eignen sich Tag oder Woche, für stabile Pipelines Monat oder Quartal. Notiere zuerst den internen Abnahmetermin und entscheide danach über eine Verlängerung.
Tag · Woche · Monat · QuartalErstelle einen Ed25519-Public-Key ausschließlich für diesen Knoten. Der Private Key darf nur auf autorisierten Geräten oder in einem kontrollierten Schlüsselsystem liegen. Verwende keinen persönlichen Alltagsschlüssel als Teamzugang.
Ed25519 empfohlenLege Knotenverantwortliche, CI-Administratoren und Störungs-Kontakte fest. Jede Person verwendet einen eigenen Schlüssel; halte Hinzufügungen, Änderungen und Widerrufe fest.
Ein Zugang pro PersonFixiere macOS-, Xcode-, Command-Line-Tools-, Ruby-, Node-, CocoaPods- und Paketmanager-Versionen. Dokumentiere die Anforderungen im Repository und prüfe sie bei der Initialisierung.
Reproduzierbare VersionenDie Konsole zeigt verfügbare Regionen je Modell. Die im Katalog angezeigten Kombinationen sind in der Regel bestellbar; maßgeblich ist der aktuelle Status in der Konsole.
Orb M4 16: M4, 16 GB Arbeitsspeicher, 256 GB Speicher. Orb M4 24: M4, 24 GB Arbeitsspeicher, 512 GB Speicher. Orb M4 Pro: M4 Pro, 64 GB Arbeitsspeicher, 2 TB Speicher.
Verfügbar sind Singapur, Japan (Tokio), Südkorea (Seoul) und Hongkong; bei der Laufzeit stehen Tag, Woche, Monat und Quartal zur Auswahl. Trage Regionscode und Verlängerungstermin in die internen Asset-Daten ein.
Prüfe Modell, Region, Laufzeit und Zusatzoptionen und schließe die Bestellung ab. Knotenadresse, erste Zugangsdaten und Servicestatus werden in der Konsole bereitgestellt.
Die ersten Zugangsdaten dienen ausschließlich dem Aufbau der ersten kontrollierten Verbindung. Importiere keine Produktions-Repositories oder Signaturmaterialien, bevor Schlüssel, Zugriffe und Wiederherstellung geprüft sind.
Entwicklerschlüssel dienen der interaktiven Fehleranalyse; Runner-Schlüssel erhalten nur die für die Pipeline nötigen Rechte. Widerrufe beim Ausscheiden eines Mitglieds dessen Public Key.
Bewahre vor Änderungen an Netzwerk, SSH oder grafischer Sitzung die aktuelle funktionierende Sitzung auf und lasse die Wiederherstellungsdaten in der Konsole von einer zweiten verantwortlichen Person prüfen.
Überspringe die Prüfung des Host-Fingerabdrucks nicht. Adresse und Port stammen aus der Konsole; vergleiche den vertrauenswürdigen Fingerabdruck mit dem bestätigten Bereitstellungsprotokoll.
# Variable erst nach Erhalt der Konsolenadresse setzen
export NODE_HOST="KNOTENADRESSE"
export NODE_PORT="22"
# Berechtigungen des dedizierten Private Keys korrigieren
chmod 600 ~/.ssh/orbvps_node
# Host-Fingerabdruck auslesen und anzeigen, anschließend mit dem Bereitstellungsprotokoll vergleichen
ssh-keyscan -p "$NODE_PORT" "$NODE_HOST" \
| ssh-keygen -lf -
# Erste Verbindung herstellen
ssh -p "$NODE_PORT" \
-i ~/.ssh/orbvps_node \
nodeadmin@"$NODE_HOST"
# Nach der Anmeldung Hardware-, System- und Festplattenstatus prüfen
$ uname -m
arm64
$ sw_vers
$ sysctl -n machdep.cpu.brand_string
$ df -h /
$ uptimeDer grafische Desktop eignet sich für Anzeige-, Systemeinstellungs- und erste Xcode-Interaktionen. Verbindungsdaten werden nicht öffentlich bereitgestellt; Adresse und Zugangsdaten sind nach der Aktivierung in der Konsole einsehbar.
Beende die Sitzung nach jeder Änderung und verbinde dich erneut, um die Konfiguration in einer neuen Sitzung zu prüfen.
Wähle zunächst eine Auflösung, die zu Netzwerk und Bildschirm passt. Bei sehr kleiner Darstellung oder deutlicher Verzögerung reduziere zuerst die Auflösung und prüfe anschließend den Netzwerkpfad.
Vereinheitliche Systemsprache, regionale Formate und Zeitzone nach der Teamvorgabe, damit Build-Logs, Datumsangaben und Automatisierungsskripte konsistent bleiben.
Stelle sicher, dass die Bildschirmsperre laufende Aufgaben nicht unterbricht und unbefugten Zugriff dennoch begrenzt. Interaktive Sitzungen und CI-Aufgaben sind getrennt zu prüfen.
Trenne eine grafische Sitzung absichtlich und verbinde dich erneut. Prüfe Desktopstatus, Auflösung und laufende Prozesse.
Die Migration erfolgt in drei Phasen: erst prüfbare Daten übertragen, dann die Toolchain fixieren und zuletzt CI anbinden. Repository, Abhängigkeiten und Automatisierung nicht ungeprüft auf einmal kopieren.
Migriere nur benötigte Repositories, Lockfiles, Build-Skripte und Testdaten. Schließe temporäre Caches, alte Artefakte und herrenlose Dateien aus und prüfe danach Repositorystatus und wichtige Dateisummen.
Installiere Xcode, Command-Line-Tools und Paketmanager gemäß den Repository-Anforderungen. Speichere die tatsächlichen Versionsausgaben in der Baseline; ersetze konkrete Versionsnummern nicht durch „neueste Version“.
Führe nach der Registrierung des self-hosted Runners zunächst einen kontrollierten Testjob aus. Prüfe Fehlerprotokolle, Cache-Bereinigung und Wiederherstellung, bevor du produktive Branches schrittweise freigibst.
Kriterium für abgeschlossene Migration:Derselbe Commit wird lokal und auf dem Cloud-Mac mit der dokumentierten Toolchain gebaut, die wichtigsten Testergebnisse stimmen überein und die Bereitstellung lässt sich anhand der Dokumentation wiederholen.
Der erste Build soll nicht die kürzeste Laufzeit beweisen, sondern reproduzierbare Toolchain, Abhängigkeiten, Berechtigungen und Ausgabepfade.
Prüfe, ob aktives Entwicklerverzeichnis, Xcode-Version und verfügbares SDK den Projektanforderungen entsprechen.
Bestätige die Xcode-Lizenz und installiere Ruby, Node, CocoaPods sowie weitere Projektabhängigkeiten strikt anhand der Lockfiles.
Gib Workspace, Scheme und Configuration eindeutig an und speichere die vollständige Standardausgabe in einer separaten Logdatei.
Halte Commit-ID, Toolchain-Versionen, Start- und Endzeit, Exit-Code sowie Artefaktpfad als Vergleichsbasis für spätere Änderungen fest.
$ xcode-select -p
/Applications/Xcode.app/Contents/Developer
$ xcodebuild -version
Xcode <PROJEKTVERSION>
$ sudo xcodebuild -license accept
$ bundle install
$ bundle exec pod install
$ mkdir -p build-logs
$ set -o pipefail
$ xcodebuild \
-workspace App.xcworkspace \
-scheme App \
-configuration Release \
clean build \
| tee build-logs/first-success.log
** BUILD SUCCEEDED **Begrenze den self-hosted Runner zunächst mit dediziertem Label und Test-Branch, bevor du produktive Builds schrittweise freigibst.
Der Job gibt die Umgebung aus, stellt Abhängigkeiten wieder her, führt Unit-Tests aus und erstellt einen Build ohne Veröffentlichung. Prüfe Label-Routing, vollständige Logs, Cache-Bereinigung und das Stoppen bei Fehlern, bevor du produktive Branches anbindest.
Übertrage die Prüfergebnisse in das Team-Runbook. Der Knoten kann 365 Tage im Jahr betrieben werden, doch Build-Prozesse benötigen weiterhin klare Zuständigkeiten für Daten, Monitoring und Reaktion.
Repository, Build-Konfiguration, Wiederherstellungsdaten der Schlüssel und erforderliche Artefakte liegen zusätzlich außerhalb des Knotens vor; eine Wiederherstellung wurde erfolgreich geprüft.
Wiederherstellung geprüftErfasse mindestens freien Speicher, Build-Exit-Code, Wartezeit von Aufgaben und Online-Status des Runners und definiere Schwellenwerte für Auffälligkeiten.
Metriken haben VerantwortlicheHaupt- und Ersatzverantwortliche können auf Knotendaten, Build-Logs und Konsolen-Tickets zugreifen; der Übergabepfad ist dokumentiert.
Haupt- und Ersatzkontakte vorhandenBestelllaufzeit und interner Bestätigungstermin sind dokumentiert und hängen nicht vom Gedächtnis einzelner Personen ab. Bewerte vor Konfigurationsänderungen das Zeitfenster laufender Aufgaben.
Laufzeit dokumentiertPersonen- und Runner-Schlüssel sowie die zugehörigen Berechtigungen sind erfasst und können einzeln widerrufen werden, ohne andere Mitglieder zu beeinträchtigen.
Ein Eintrag pro ElementKnotennummer, Zeitraum des Vorfalls, Reproduktionsschritte und anonymisierte Logs lassen sich jederzeit zusammenstellen; autorisierte Mitglieder können damit über die Konsole ein Ticket erstellen.
Material direkt einreichbarWähle Modell, Region und Laufzeit und schließe nach der Aktivierung sicheren Zugriff, ersten Build und CI-Abnahme anhand dieses Leitfadens ab.