SSH- und VNC-Zugangsdaten sind bei der Bereitstellung enthalten. Bauen Sie über die Kommandozeile und prüfen Sie die Signierung per Remote-Desktop. Der dedizierte physische Mac gehört ganz Ihnen – keine virtuelle Maschine.
Sie haben bereits einen Knoten? Notieren Sie zuerst Adresse, SSH-Port, Benutzernamen und Desktop-Zugriff, bevor Sie die folgenden Schritte ausführen.
Erstellen Sie lokal einen Schlüssel, autorisieren Sie den öffentlichen Schlüssel für den Cloud-Benutzer und vergeben Sie einen festen Alias für den Knoten. Rsync, Fastlane und Runner verwenden anschließend dieselbe Verbindung.
Die folgenden 192.0.2.10 ist eine Beispieladresse aus der Dokumentation, macbuild ein Beispielbenutzername und 22 ein Beispiel-SSH-Port. Ersetzen Sie alle Werte durch die Angaben aus dem Kundenportal. Fügen Sie niemals private Schlüssel, Passwörter oder vollständige Zugangsdaten in ein Support-Ticket ein.
Führen Sie den Befehl lokal aus. Ein eigener Dateiname erleichtert den Widerruf der Berechtigung und überschreibt keinen vorhandenen Standardschlüssel. Legen Sie bei der Abfrage eine Passphrase fest. In automatisierten Umgebungen muss der Zugriff über eine kontrollierte Schlüsselverwaltung erfolgen – private Schlüssel gehören nicht ins Repository.
ssh-keygen -t ed25519 -f ~/.ssh/xcr_build -C "xcr-build"
ssh-add ~/.ssh/xcr_build
ls -l ~/.ssh/xcr_build.pubDateien mit der Endung .pub enthalten den öffentlichen Schlüssel und können auf dem Knoten installiert werden. Dateien ohne diese Endung enthalten den privaten Schlüssel und bleiben lokal oder in einem geschützten CI-Schlüsselspeicher.
Wenn lokal ssh-copy-id installiert ist, installieren Sie damit den öffentlichen Schlüssel unter Verwendung des bereitgestellten Benutzernamens und Ports. Beim ersten Verbindungsaufbau wird der Host-Fingerabdruck angezeigt. Vergleichen Sie ihn mit den Bereitstellungsdaten. Ist kein vertrauenswürdiger Fingerabdruck verfügbar, lassen Sie ihn über ein Support-Ticket im Kundenportal bestätigen – überspringen Sie die Prüfung nicht einfach.
ssh-copy-id -i ~/.ssh/xcr_build.pub -p 22 macbuild@192.0.2.10
ssh -i ~/.ssh/xcr_build -p 22 macbuild@192.0.2.10Auf macOS ist ssh-copy-id möglicherweise nicht vorinstalliert. Wenn laut Bereitstellungsangaben die Anmeldung per Passwort zulässig ist, können Sie stattdessen den folgenden Standard-SSH-Befehl verwenden. Ist ausschließlich die Schlüsselanmeldung erlaubt, autorisieren Sie den öffentlichen Schlüssel über den vorgesehenen Bereitstellungsprozess, statt wiederholt Passwörter auszuprobieren.
cat ~/.ssh/xcr_build.pub | ssh -p 22 macbuild@192.0.2.10 \
'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'Wird nach einer Neuinstallation des Knotens eine Änderung des Host-Schlüssels gemeldet, prüfen Sie zuerst den Neuinstallationsvermerk und den neuen Fingerabdruck und aktualisieren Sie anschließend den lokalen Eintrag. Deaktivieren Sie die Host-Prüfung nicht, um eine unerwartete Änderung zu kaschieren.
Fügen Sie die folgende Konfiguration in Ihre lokale Datei ~/.ssh/config ein. Mit einem Alias müssen Sie sich die Knotenadresse nicht merken. Ändert sich die Adresse, passen Sie nur diesen Eintrag an – Ihre Skripte verwenden weiterhin xcr-build.
Host xcr-build
HostName 192.0.2.10
User macbuild
Port 22
IdentityFile ~/.ssh/xcr_build
IdentitiesOnly yes
ServerAliveInterval 30
ServerAliveCountMax 3Prüfen Sie die Umgebung zunächst mit einem rein lesenden Test: Betriebssystemversion, ausgewähltes Xcode und verfügbarer Speicherplatz. Erst danach Abhängigkeiten installieren oder Runner registrieren – so gelangen keine falschen Versionen in die Pipeline.
ssh xcr-build
sw_vers
xcode-select -p
xcodebuild -version
df -h "$HOME"Beim erstmaligen Einrichten von Signierzertifikaten, Prüfen der Keychain-Berechtigungen oder Kontrollieren der Xcode-Einstellungen ist ein Remote-Desktop oft einfacher, als Befehle zu erraten. Übergeben Sie stabile Abläufe anschließend wieder an die Kommandozeile.
Öffnen Sie auf Ihrem lokalen Mac die App „Bildschirmfreigabe“ und geben Sie Desktop-Adresse und Port gemäß den Bereitstellungsangaben ein. Alternativ können Sie im Finder über „Gehe zu → Mit Server verbinden“ die bereitgestellte VNC-Adresse eingeben.
Desktop- und SSH-Zugangsdaten können unterschiedlich sein. Verwenden Sie die jeweiligen Angaben aus dem Kundenportal und nicht die SSH-Schlüsseldatei als VNC-Passwort.
Auf anderen Betriebssystemen können Sie einen VNC-Client verwenden, der die bereitgestellte Authentifizierung unterstützt. Geben Sie Host, Port und Zugangsdaten ein. Machen Sie den Desktop-Dienst nicht eigenständig über ein öffentliches Netzwerk zugänglich.
Wenn die Bereitstellungsangaben den Zugriff per SSH auf den lokalen VNC-Dienst des Knotens erlauben, können Sie einen Tunnel einrichten. Das folgende Beispiel gilt nur, wenn der Dienst auf dem Remote-System an 127.0.0.1:5900 lauscht. Maßgeblich ist der bereitgestellte Port.
ssh -N -o ExitOnForwardFailure=yes \
-L 127.0.0.1:5901:127.0.0.1:5900 xcr-buildLassen Sie diese Terminalsitzung geöffnet und verbinden Sie Ihren lokalen VNC-Client mit 127.0.0.1:5901. Der lokale Port ist nur an die Loopback-Adresse gebunden. Beenden Sie den Tunnel nach der Desktop-Sitzung mit Control-C.
Vergewissern Sie sich, dass Xcode startet und die erwartete Version ausgewählt ist, der Build-Benutzer auf das Signierzertifikat und dessen privaten Schlüssel zugreifen kann und Provisioning-Profil sowie Bundle Identifier, Team und Exportmethode des Projekts übereinstimmen. Passwörter für Zertifikate dürfen nicht auf Screenshots zu sehen sein.
Migrieren Sie in dieser Reihenfolge: Daten, Toolchain, CI-Anbindung. Erstellen Sie zuerst manuell ein Archiv mit demselben Quellcode-Commit und übergeben Sie den Ablauf erst danach an den Runner. Ändern Sie nicht gleichzeitig Xcode, Abhängigkeiten und Signierungsregeln.
Legen Sie Quellcode und Lockfiles in einem eigenen Arbeitsverzeichnis ab. Führen Sie zunächst einen rsync-Probelauf aus und prüfen Sie den Zielpfad. Synchronisieren Sie nicht das gesamte Benutzerverzeichnis und übertragen Sie Zertifikate, private Schlüssel oder lokale Umgebungsdateien nicht ungeprüft mit.
DerivedData ist ein wiederherstellbarer Cache. Verwenden Sie ihn nur weiter, wenn Xcode-Version, Abhängigkeiten und Quellumgebung kompatibel sind. Bei Problemen mit Pfaden oder Modul-Caches sollten Sie den Cache zuerst löschen und einen sauberen Build ausführen.
Prüfen Sie mit xcode-select -p und xcodebuild -version die Versionen. Verwenden Sie beim Wechsel einen Xcode-Pfad, der auf dem Knoten tatsächlich vorhanden ist, und prüfen Sie anschließend, welches SDK das Projekt benötigt.
Bewahren Sie Podfile.lock, Package.resolved und Gemfile.lock auf. Führen Sie CocoaPods, SPM und Fastlane mit der im Projekt festgelegten Umgebung aus. Importieren Sie Zertifikate und Provisioning-Profile separat und prüfen Sie die Zugriffsrechte für den privaten Schlüssel.
Erstellen Sie im GitHub- oder GitLab-Projekt die Registrierungsdaten für einen Self-Hosted Runner und installieren Sie ihn anschließend gemäß den macOS-Anweisungen der Plattform. Registrierungstoken sind nur für die kontrollierte Einrichtung bestimmt und gehören weder ins Repository noch in Build-Logs.
Kennzeichnen Sie den Runner nach Zweck und Toolchain, zum Beispiel mit macos, ios-build. Erlauben Sie Signierungsaufgaben zunächst nur auf vertrauenswürdigen Branches und begrenzen Sie die parallelen Jobs. Passen Sie die Auslastung anschließend anhand von Arbeitsspeicher, Speicherplatz und Job-Logs an.
rsync -avzn --exclude '.env' --exclude '.env.*' \
--exclude 'DerivedData/' ./MyApp/ xcr-build:~/builds/MyApp/
rsync -avz --exclude '.env' --exclude '.env.*' \
--exclude 'DerivedData/' ./MyApp/ xcr-build:~/builds/MyApp/Der erste Befehl enthält -n und zeigt nur die geplanten Änderungen an. Führen Sie den zweiten Befehl erst nach der Prüfung aus. Das Beispiel verwendet kein --delete, damit bei der ersten Migration keine Dateien auf dem Remote-System versehentlich gelöscht werden. Gibt es im Projekt weitere Verzeichnisse mit Schlüsseln, ergänzen Sie vorher entsprechende Ausschlussregeln.
Dokumentieren Sie Quellcode-Commit, Xcode-Version, Dependency-Lockfiles, Scheme, Exportkonfiguration, Runner-Tags und Artefaktpfad. Prüfen Sie zuerst getrennt einen sauberen und einen inkrementellen Build und entscheiden Sie erst danach, ob Caches übernommen werden. Die Beispielbefehle auf dieser Seite sind keine Leistungstests und garantieren keine feste Build-Dauer.
Unterscheiden Sie bei der Fehlersuche zwischen Verbindungsprotokoll, Ausführungsumgebung und Build-Cache. Wenn Sie die betroffene Ebene genau benennen, lässt sich das Problem leichter eingrenzen als mit der pauschalen Aussage „Der Rechner ist nicht erreichbar“.
Drei Mac-Tarife decken alle sechs Knoten ab. Bei interaktiver Desktop-Nutzung sollte der Knoten zunächst möglichst nahe am Hauptstandort der Benutzer liegen. Prüfen Sie anschließend den Zugriff auf Repository, Paketquellen und Artefaktziele. Team-Zeitzonen helfen bei der Vorauswahl, ersetzen aber keinen echten Netzwerktest.
SG · UTC+8
Geeignet für Teams, deren gemeinsame Arbeitszeit überwiegend auf Werktage in Südostasien fällt. Testen Sie zuerst die Desktop-Reaktionszeit vom eigenen Standort und prüfen Sie danach Downloads und Artefakt-Uploads.
JP · UTC+9
Geeignet für Teams, deren Zusammenarbeit sich überwiegend nach den japanischen Arbeitszeiten richtet. Lassen Sie zunächst die Personen mit Bedarf an grafischer Fehlerbehebung die Verbindung testen und planen Sie anschließend die Ausführungszeiten automatisierter Jobs.
KR · UTC+9
Geeignet für Entwicklungsteams mit Arbeitszeiten nach koreanischer Zeitzone. Prüfen Sie, ob das Unternehmensnetz den bereitgestellten Port erreicht und ob lange SSH-Sitzungen stabil bleiben.
HK · UTC+8
Geeignet für Teams, deren Zusammenarbeit überwiegend in die Arbeitszeiten Südchinas und der umliegenden Regionen fällt. Testen Sie Desktop-Reaktion, Codeabruf und Cache-Übertragung getrennt. Ein einzelner Ping reicht für eine vollständige Bewertung nicht aus.
US-E · UTC−5 / UTC−4
Geeignet für Arbeitszeiten an der US-Ostküste und als Option für standortübergreifende Zusammenarbeit. Wegen der Sommerzeit sollten Sie bei Übergaben immer die Zeitzone angeben, nicht nur die Uhrzeit.
US-W · UTC−8 / UTC−7
Geeignet für Arbeitszeiten an der US-Westküste. Bei verteilten Teams können nächtliche Archive auf Code-Commits der anderen Seite während deren Tageszeit folgen. Begrenzen Sie trotzdem die Parallelität von Signierungsaufgaben.
Die Knoten sind 365 Tage im Jahr in Betrieb. Den aktuellen Verfügbarkeitsstatus sehen Sie im Kundenportal. Geben Sie bei Verbindungsproblemen in einem Support-Ticket im Kundenportal Knoten, Modell, verwendetes Protokoll, den vollständigen Fehlertext und die Reproduktionsschritte an. Schwärzen Sie nur Zugangsdaten – hilfreiche Fehlerinformationen sollten erhalten bleiben.
Nutzen Sie fünf Minuten als Richtwert für die erste Verbindung: Host prüfen, SSH verifizieren und Desktop öffnen. Migrieren Sie die Build-Umgebung erst, nachdem Netzwerk und Authentifizierung geprüft sind. Die vollständige Abnahme der Pipeline sollte separat für jedes Projekt geplant werden.
Ab $21.7/Tag. Zahlungen sind ausschließlich mit USDT-TRC20 sowie Visa / Mastercard / Amex über Stripe möglich; abgerechnet wird in US-Dollar. Welche Zahlungswege verfügbar sind, richtet sich nach der Rückmeldung des Backend-Systems.