Erst verbinden, dann migrieren

In drei Minuten mit dem Mac in der Cloud verbinden

Führen Sie Befehle per SSH aus und bedienen Sie die macOS-Oberfläche per VNC. Sie erhalten einen exklusiv genutzten physischen Mac, keine virtuelle Maschine. Übertragen Sie Quellcode, Toolchain und CI schrittweise, statt lokale Probleme gleich mit umzuziehen.

Wenn Sie die Zugangsdaten und Ihren SSH-Schlüssel bereits haben, können Sie direkt mit den folgenden Schritten beginnen. Die erstmalige Einrichtung der Toolchain dauert zusätzlich und gehört nicht zu den Verbindungsschritten.

Zuerst SSH verbinden – alle weiteren Schritte laufen über diesen Zugang

Bereiten Sie ein lokales Terminal, Ihren SSH-Schlüssel und die Hostdaten aus der Konsole vor. Ersetzen Sie im Beispiel HOST undPORT sowieUSER durch den bereitgestellten Hostnamen, SSH-Port und Benutzernamen. Übernehmen Sie die Platzhalter nicht unverändert.

01 · Lokal vorbereiten

Öffentlichen Schlüssel hinzufügen, privaten behalten

Sie können einen bereits vorhandenen dedizierten Schlüssel verwenden. Andernfalls erzeugen Sie auf Ihrem Computer ein Ed25519-Schlüsselpaar, legen eine Passphrase fest und fügen den Inhalt der Datei .pub in der passenden SSH-Schlüsselkonfiguration der Konsole hinzu.

ssh-keygen -t ed25519 \
  -f ~/.ssh/osxbuild_ed25519

cat ~/.ssh/osxbuild_ed25519.pub

Der private Schlüssel bleibt auf Ihrem Computer. Fügen Sie ihn weder einem Ticket noch einer E-Mail oder einem Repository hinzu. Prüfen Sie nach dem Hochladen anhand der Konsolenhinweise, ob der öffentliche Schlüssel für die richtige Instanz aktiviert wurde.

02 · Zugangsdaten prüfen

Einmal direkt mit dem bereitgestellten Port verbinden

Rufen Sie die Verbindungsdaten in den Instanzdetails der Konsole auf. Vergleichen Sie den Host-Fingerprint bei der ersten Abfrage mit den verifizierbaren Übergabedaten. Ist keine Prüfung möglich, erstellen Sie ein Support-Ticket. Deaktivieren Sie die Hostprüfung nicht, um die Abfrage zu umgehen.

ssh -i ~/.ssh/osxbuild_ed25519 \
  -p PORT USER@HOST

sw_vers
uname -m
xcodebuild -version

Prüfen Sie zuerst System, Architektur und Xcode-Version. Meldet der letzte Befehl, dass die Toolchain noch nicht eingerichtet ist, installieren Sie sie und wählen Sie den passenden Pfad aus, bevor Sie Build-Aufgaben einrichten.

03 · Fester Zugang

Der Maschine einen lokalen Alias geben

Schreiben Sie den folgenden Inhalt in Ihre lokale Datei ~/.ssh/config. Der Beispielalias lautet bake. Verwenden Sie ihn auch für die folgenden Synchronisierungs-, Tunnel- und Diagnosebefehle, damit Host und Port nicht jedes Mal neu eingegeben werden müssen.

Host bake
  HostName HOST
  Port SSH_PORT
  User SSH_USER
  IdentityFile ~/.ssh/osxbuild_ed25519
  IdentitiesOnly yes
  ServerAliveInterval 30
  ServerAliveCountMax 3

Speichern Sie die Datei und führen Sie anschließend ssh bakeaus. Die Keepalive-Einstellungen helfen, eine unterbrochene Verbindung zu erkennen. Sie stellen weder die Netzwerkverbindung wieder her noch setzen sie Terminal-Aufgaben automatisch fort.

Der grafische Desktop läuft über VNC – der Zugang erfolgt durch einen SSH-Tunnel

Öffnen Sie den Desktop, wenn Sie Xcode konfigurieren, den Schlüsselbund prüfen oder den Simulator ansehen möchten. Prüfen Sie zuerst die in der Konsole angegebenen VNC-Verbindungsdaten. Verwenden Sie den Standardport nicht ungeprüft als Verbindungsparameter für jede Maschine.

Wählen Sie einen vertrauten Client

Unter macOS können Sie die integrierte Bildschirmfreigabe verwenden. Unter Windows und Linux eignen sich VNC-Clients wie TigerVNC. Falls eine Installation nötig ist, beziehen Sie den Client aus der offiziellen Bezugsquelle und prüfen Sie, ob er das Authentifizierungsverfahren des bereitgestellten Dienstes unterstützt.

Zuerst die Datenmenge reduzieren, dann die Bildqualität anpassen

Beginnen Sie mit einer Desktopauflösung von 1440 × 900 oder 1600 × 1000 . Sie müssen nicht gleich die gesamte Fläche eines hochauflösenden Displays nutzen. Wenn die Option verfügbar ist, wählen Sie zunächst 24 Bit Farbtiefe; bei eingeschränkter Netzwerkverbindung können Sie 16 Bit testen. Maßgeblich sind die Optionen, die Client und Server tatsächlich unterstützen.

Terminal-Builds und Remote-Desktop sind zwei getrennte Arbeitsweisen. Wenn die Desktopbedienung stockt, können Sie Builds weiterhin per SSH ausführen und anschließend Logs und IPA-Dateien abrufen. So hängt nicht die gesamte Pipeline von der Bildschirmaktualisierung ab.

Nur den Desktop-Port an den lokalen Rechner weiterleiten

Führen Sie den folgenden Befehl lokal aus und lassen Sie dieses Terminal geöffnet. Ersetzen SieVNC_PORT durch den bereitgestellten Serverport. Im Beispiel ist 15900 der lokale Port. Sie können einen anderen freien Port verwenden.

ssh -N \
  -L 127.0.0.1:15900:127.0.0.1:VNC_PORT \
  -o ExitOnForwardFailure=yes \
  bake

Tragen Sie anschließend im VNC-Client als Adresse 127.0.0.1und als Port 15900ein. Wenn der Client nur ein einziges Adressfeld hat, verwenden Sie das in der Dokumentation angegebene Format.

Für VNC benötigen Sie weiterhin die bereitgestellten Desktop-Zugangsdaten. Der SSH-Schlüssel ersetzt das Desktoppasswort nicht. Beenden Sie nach der Sitzung den Client und schließen Sie den Tunnel mit Ctrl + C .

Desktopverbindung fehlgeschlagen? Prüfen Sie die Verbindung Schritt für Schritt
Symptom Zuerst prüfen Nächster Schritt
Lokaler Port lässt sich nicht öffnen Ist SSH verbunden? Ist der lokale Port bereits belegt? Verwenden Sie einen anderen lokalen Port und sichern Sie die Fehlermeldung aus dem Tunnel-Terminal.
Tunnel steht, aber der Desktop lehnt die Verbindung ab Bereitgestellter VNC-Port und Status des lauschenden Dienstes Prüfen Sie die Instanzdetails. Öffnen Sie den Desktop-Port nicht zusätzlich für das öffentliche Internet.
Verbindung scheitert nach Beginn der Anmeldung Desktop-Benutzername und -Passwort sowie die Authentifizierungskompatibilität des Clients Prüfen Sie die bereitgestellten Zugangsdaten erneut. Der SSH-Schlüssel ist nicht das VNC-Passwort.
Anmeldung erfolgreich, aber das Bild wird langsam aktualisiert Auflösung, Farbtiefe, lokales Netzwerk und Entfernung zum Standort Reduzieren Sie die übertragene Bildmenge und führen Sie Builds ohne grafische Oberfläche weiter per SSH aus.

Migrieren Sie in drei Etappen, statt das gesamte Laufwerk zu kopieren

Übertragen Sie zuerst die Daten, gleichen Sie dann die Toolchain ab und richten Sie zuletzt CI ein. Halten Sie für jeden Schritt ein Prüfergebnis fest. Führen Sie zunächst einen sauberen Archive-Build aus, bevor Sie Caches und Automatisierung wiederherstellen.

Erste Etappe · Daten

Quellcode synchronisieren, temporäre Artefakte neu erstellen

Klonen Sie das Projekt mit Git oder synchronisieren Sie Ihr lokales Arbeitsverzeichnis und externe Ressourcen mit rsync. Schließen Sie beim ersten Durchlauf DerivedData und alte Build-Verzeichnisse aus. Synchronisieren Sie private Signaturschlüssel nicht zusammen mit gewöhnlichen Dateien.

rsync -az --progress \
  --exclude='DerivedData/' \
  --exclude='build/' \
  --exclude='*.p12' \
  --exclude='*.mobileprovision' \
  ./ bake:~/project/

Prüfen Sie, ob Zielverzeichnis, Commit-Version und erforderliche Ressourcen übereinstimmen. Das Beispiel enthält keinen Löschparameter, damit beim ersten Abgleich nicht versehentlich Dateien auf dem Remote-System entfernt werden. Eine erfolgreiche Synchronisierung ist kein Ersatz für ein Backup.

Zweite Etappe · Toolchain

Versionen abgleichen, dann Abhängigkeiten wiederherstellen

Installieren oder wählen Sie Xcode passend zum Projekt und konfigurieren Sie Homebrew. Stellen Sie CocoaPods anhand der Lockdatei wieder her und lösen Sie SPM-Abhängigkeiten zunächst neu auf. Caches müssen zur Toolchain und den Abhängigkeitsversionen passen. Verwenden Sie keine Verzeichnisse unbekannter Herkunft weiter.

xcode-select -p
xcodebuild -version
brew --version

bundle install
bundle exec pod install

Prüfen Sie, ob die Versionen der lokalen Referenz entsprechen und sich die Abhängigkeiten auflösen lassen. Die letzten beiden Befehle sind nur für CocoaPods-Projekte gedacht. Importieren Sie Signaturzertifikate separat über einen kontrollierten Weg in den Schlüsselbund und prüfen Sie Gültigkeit sowie Zuordnung zum Provisioning-Profil.

Dritte Etappe · CI einrichten

Runner registrieren, Verteilung zuletzt einrichten

Registrieren Sie einen dedizierten Runner in GitHub Actions oder GitLab Runner. Prüfen Sie zunächst die Versionen und führen Sie dann die Fastlane-Lane des Projekts aus. Testen Sie zuerst Archive und Export und fügen Sie den Upload-Schritt erst danach hinzu.

xcodebuild -list \
  -workspace App.xcworkspace

bundle exec fastlane ios build

Prüfen Sie, ob sich Commit-Version, Scheme und Artefaktpfad aus den Logs nachvollziehen lassen. Passen Sie Arbeitsbereich und Lane im Beispiel an die tatsächlichen Projektnamen an. Autorisieren Sie Zugangsdaten für Releases separat und verteilen Sie sie nicht mit dem Quellcode.

CI einrichten und Aufgaben gezielt auf dieser Maschine ausführen

Der Self-Hosted-Runner nutzt den von Ihnen gemieteten physischen Knoten. Labels steuern die Zuordnung, Zugangsdaten die Berechtigung – verwenden Sie sie nicht für denselben Zweck. Bringen Sie zunächst einen einzelnen Job zum Laufen und prüfen Sie anschließend Parallelität und Speicherplatzbedarf.

GitHub Actions: Build-Maschine mit einem dedizierten Label auswählen

Registrieren Sie den Self-Hosted-Runner anhand der Anleitung in den Repository- oder Organisationseinstellungen und fügen Sie das benutzerdefinierte Label osxbuildhinzu. Der folgende Workflow prüft die Toolchain und erstellt ein Archiv. Das Einbringen von Signaturmaterial, der IPA-Export und die Verteilung sind nicht enthalten.

name: iOS archive
on:
  workflow_dispatch:

permissions:
  contents: read

concurrency:
  group: ios-${{ github.ref }}
  cancel-in-progress: false

jobs:
  archive:
    runs-on: [self-hosted, macOS, ARM64, osxbuild]
    steps:
      - uses: actions/checkout@v4
      - name: Check Xcode
        run: xcodebuild -version
      - name: Archive
        run: |
          xcodebuild \
            -workspace App.xcworkspace \
            -scheme App \
            -configuration Release \
            -archivePath "$RUNNER_TEMP/App.xcarchive" \
            archive

Passen Sie Arbeitsbereich und Scheme an und prüfen Sie, ob das Scheme freigegeben ist. Verwenden Sie Runner mit Signaturmaterial nur für vertrauenswürdige Repositories und Jobs. Verschiedene Branches bilden unterschiedliche Concurrency-Gruppen; Konflikte durch gemeinsam genutzte Build-Verzeichnisse müssen dennoch vermieden werden.

Jenkins: eigenständigen Agent per SSH starten

Fügen Sie in Jenkins einen festen Knoten hinzu, verwenden Sie ein eigenes Build-Verzeichnis als Remote-Arbeitsverzeichnis und setzen Sie das Label auf osxbuild-mac. Wählen Sie den Start des Agents per SSH, tragen Sie den bereitgestellten Host und Port ein und verwalten Sie den privaten Schlüssel im Jenkins-Credentials-Speicher.

pipeline {
  agent { label 'osxbuild-mac' }

  stages {
    stage('Checkout') {
      steps {
        checkout scm
      }
    }
    stage('Toolchain') {
      steps {
        sh 'xcodebuild -version'
      }
    }
    stage('Build') {
      steps {
        sh 'bundle exec fastlane ios build'
      }
    }
  }
}

Prüfen Sie, ob das benötigte Java für den Agent verfügbar, das SSH-Zugangsdatenobjekt gültig und der Host-Fingerprint verifiziert ist. Eine nicht interaktive SSH-Sitzung lädt möglicherweise keine lokale Shell-Konfiguration. Konfigurieren Sie daher die Pfade für Homebrew, Ruby und Fastlane explizit.

Richten Sie GitLab Runner in derselben Reihenfolge ein: Runner registrieren, vertrauenswürdige Projekte einschränken, Projekt-Labels festlegen und die Umgebung mit einem Versionsprüfungsjob abnehmen. Testen Sie die Voraussetzungen für Tests mit grafischer Sitzung separat.

Beginnen Sie mit einem Ausführungsslot. Prüfen Sie vor einer Erhöhung der Parallelität die Speicherspitzen, die Anzahl der Simulatoren und die DerivedData-Pfade. Lassen Sie nicht mehrere Jobs gleichzeitig in dasselbe Archivverzeichnis schreiben.

Sechs Standorte – wählen Sie danach, wer die Maschine bedient

Wenn Sie häufig den grafischen Desktop nutzen, vergleichen Sie zuerst die Verbindung zwischen Ihrem Team und dem Standort. Für CI sind die Wege von Quellcode, Abhängigkeiten und Artefakt-Uploads entscheidend. Die geografische Entfernung ist nur ein Anhaltspunkt: Auch Provider, Routing und lokales Netzwerk beeinflussen die tatsächliche Leistung.

Singapur

SG · UTC+8

Für Teams mit Zusammenarbeit in südostasiatischen Zeitzonen. Wenn Sie Xcode tagsüber häufig remote bedienen, vergleichen Sie zuerst die Verbindung von Ihrem Standort zu diesem Knoten.

Singapur-Standort wählen

Tokio

JP · UTC+9

Für Teams mit Zusammenarbeit in ostasiatischen Zeitzonen. Geeignet, wenn interaktive Entwicklung tagsüber und Archiv-Builds nachts auf derselben Maschine laufen sollen – das vereinfacht die Übergabe der Umgebung.

Tokio-Standort wählen

Seoul

KR · UTC+9

Für Teams mit Zusammenarbeit in nordostasiatischen Zeitzonen. Wenn Sie den Remote-Desktop oft nutzen, vergleichen Sie zunächst Bildaktualisierung und Eingabereaktion, bevor Sie einen festen Teamzugang einrichten.

Seoul-Standort wählen

Hongkong

HK · UTC+8

Für Teams mit Zusammenarbeit in Südchina und Südostasien. Achten Sie neben der Remote-Bedienung auch auf Downloads von Abhängigkeiten und Artefakt-Uploads. Verlassen Sie sich nicht nur auf einen einzelnen erfolgreichen Verbindungstest.

Hongkong-Standort wählen

US-Ostküste

US-E · UTC−5 / −4

Für Teams im Osten Nordamerikas und in Westeuropa. Legen Sie für Nightly-Builds eine klare Zeitzone fest und beachten Sie die Verschiebung durch die Sommerzeit.

US-Ostküstenstandort wählen

US-Westküste

US-W · UTC−8 / −7

Für Teams an der nordamerikanischen Westküste. Build-Zeitfenster lassen sich gut auf die lokalen Arbeitstage abstimmen. Bei Übergaben über Zeitzonen hinweg sollten Logs eindeutige Zeitangaben enthalten.

US-Westküstenstandort wählen

Beide Maschinenkonfigurationen sind an allen sechs Standorten verfügbar. Maßgeblich ist die aktuelle Verfügbarkeit in der Konsole. Die Knoten laufen ganzjährig rund um die Uhr. Unterbrechungen des lokalen Netzwerks oder der SSH-Sitzung sind getrennt vom Betriebsstatus der Maschine zu beurteilen.

Nach dem Verbinden Zugänge und Signaturmaterial absichern

Behalten Sie zunächst eine nachweislich funktionierende Verbindung bei und passen Sie dann die Zugriffsregeln an. Nehmen Sie pro Schritt nur eine Änderung vor. Schließen Sie die alte Sitzung erst, nachdem die neue Verbindung erfolgreich getestet wurde – so sperren Sie sich nicht selbst aus.

  1. 01

    Schlüssel prüfen, dann Passwortanmeldung deaktivieren

    Öffnen Sie ein zweites Terminal und prüfen Sie, ob Sie sich mit dem dedizierten Schlüssel anmelden können. Deaktivieren Sie erst danach die Passwortauthentifizierung gemäß der SSH-Konfiguration des Systems. Prüfen Sie vor der Änderung die Syntax und stellen Sie sicher, dass ein Wiederherstellungsweg besteht. Wenn Sie mit den Systemeinstellungen nicht vertraut sind, klären Sie das Vorgehen zuerst über ein Support-Ticket ab.

  2. 02

    Nur benötigte Ports offen lassen

    Beschränken Sie Remote-Anmeldungen und Dienste auf das tatsächlich Erforderliche. Leiten Sie VNC vorzugsweise durch einen SSH-Tunnel. Vermeiden Sie es, Debugging-Dienste, Build-Steuerungszugänge oder temporäre Dateidienste direkt dem öffentlichen Internet auszusetzen. Prüfen Sie die Bindung an lokale Adressen und die Zugriffskontrollen gemeinsam.

  3. 03

    Schlüssel nach Person und Zweck trennen

    Verwenden Sie für menschliche Anmeldungen und CI unterschiedliche Schlüssel. Widerrufen Sie alte Berechtigungen sofort, wenn Mitarbeitende wechseln oder ein Zugang kompromittiert sein könnte. Fügen Sie beim Schlüsselwechsel zuerst den neuen öffentlichen Schlüssel hinzu und testen Sie ihn. Entfernen Sie danach den alten Schlüssel und aktualisieren Sie Runner und Teamdokumentation.

  4. 04

    Signaturmaterial gehört nicht in gewöhnliche Logs

    Entsperren Sie den Schlüsselbund nur, wenn der Build es erfordert, und beschränken Sie den Zugriff anschließend wieder. Stellen Sie API-Keys, Zertifikat-Passphrasen und Zugangsdaten zur Entschlüsselung von match über ein Zugangsdaten-System bereit. Prüfen Sie, ob Skripte vertrauliche Variablen ausgeben, und speichern Sie keine privaten Schlüsseldateien im Repository.

  5. 05

    Artefakte und Konfiguration vor Ablauf sichern

    Übertragen Sie benötigten Quellcode, IPA-Dateien, Archive und Pipeline-Konfigurationen in einen teaminternen Speicher und prüfen Sie, ob die Dateien lesbar sind. Nach Ende der Mietzeit werden Datenträger gelöscht und Systeme neu installiert. Verwenden Sie lokale Verzeichnisse auf der Maschine daher nicht als einzige Kopie.

Für die Fehlersuche reichen die nötigen Übergabeinformationen aus.Fügen Sie dem Ticket Bestellnummer, Knoten, Fehlerzeitpunkt mit Zeitzone und die letzten 50 Zeilen bereinigter Logs hinzu. Senden Sie keine privaten Schlüssel, Zertifikat-Passphrasen oder Kontopasswörter. Bei Verbindungsproblemen erreichen Sie uns über ein Konsolen-Ticket oder unter support@osxbuild.com .

Verbindung einrichten und den nächsten Archive-Build übergeben

Sie haben bereits eine Maschine? Prüfen Sie zuerst die bereitgestellten Zugangsdaten in der Konsole. Suchen Sie noch die passende Konfiguration, wählen Sie aus zwei Modellen eines exklusiv genutzten Macs in der Cloud – nach Build-Volumen und Teamstandort.