Leitfaden für Fernzugriff

Sicher vom lokalen Gerät mit einem Cloud Mac verbinden

Prüfen Sie zuerst, ob Ihre Aufgabe die Kommandozeile, eine grafische Oberfläche oder eine unbeaufsichtigte Ausführung erfordert. Validieren Sie dann Zugangsdaten, Toolchain und Berechtigungen. VMRunner stellt dedizierte Apple-Silicon-Physikknoten bereit, keine virtuellen Maschinen. Maßgeblich sind die Verbindungsdaten der im Portal bereitgestellten Bestellung.

Zugangswege
3 Arten
Bereitstellungsform
Dedizierter Physikknoten
Betriebszeit
365 Tage im Jahr
CONNECTION RUN SHEET

Zugangsplan

Nach Bereitstellung des Knotens
01
SSH-Verwaltung Repositories, Builds, Logs
Bevorzugt
02
Grafischer Desktop Xcode, Assets, interaktives Debugging
Nach Bedarf
03
CI-Runner Tests, Signierung, Artefaktübertragung
Kontinuierlich
Zugangsdaten trennen Durch
Host-Fingerabdruck Lokal prüfen
Erster Build Mit kleiner Aufgabe starten

Übergeben Sie dieselben Zugangsdaten niemals gleichzeitig an persönliche Sitzungen und Automatisierungsaufgaben. Richten Sie zuerst ein widerrufbares dediziertes Konto ein und binden Sie anschließend den Runner an.

Zugangsweg wählen

Nach Vorgang aufteilen, nicht standardmäßig den grafischen Desktop öffnen

Die Kommandozeile eignet sich für häufige, skriptfähige Vorgänge; grafische Sitzungen bleiben interaktiven Tools vorbehalten, und dauerhafte Aufgaben laufen über einen eigenen Runner. So werden Berechtigungsgrenzen klarer und Verbindungsprobleme leichter lokalisierbar.

Kommandozeilenverwaltung

Geeignet für Git-Vorgänge, die Installation von Abhängigkeiten, Log-Prüfungen, Skriptausführung und Build-Aufgaben. Der Bandbreitenbedarf ist gering, und nach Unterbrechungen lässt sich die Verbindung leichter wiederherstellen.

  • Typischer ZugangSSH
  • Geeignet fürBuilds und Betrieb
  • BerechtigungsempfehlungAnmeldung per Schlüssel

Arbeiten mit dem grafischen Desktop

Geeignet für Xcode-Debugging, Simulatorprüfungen, die Bearbeitung von Audio- und Videoprojekten sowie Aufgaben, bei denen der Fensterstatus beobachtet werden muss. Je höher die Auflösung, desto höher die Anforderungen an das lokale Netzwerk.

  • Typischer ZugangRemote-Desktop
  • Geeignet fürInteraktive Tools
  • BerechtigungsempfehlungEigenes Sitzungskonto

CI-Ausführung

Geeignet für Tests, Archivierung, Signierung und die Übertragung von Artefakten. Der Runner läuft mit einem eigenen Konto; Umgebungsvariablen werden aufgabenbezogen injiziert. Zugangsdaten der persönlichen Desktop-Sitzung werden nicht gemeinsam verwendet.

  • Typischer ZugangSelf-hosted Runner
  • Geeignet fürKontinuierliche Pipelines
  • BerechtigungsempfehlungMinimale Berechtigungen
Vor der Verbindung prüfen

Bereitstellungsdaten und lokale Basiswerte dokumentieren

Bei der Analyse von Remote-Verbindungen kostet meist nicht ein komplexer Fehler Zeit, sondern ein unklarer Knoten, Verwendungszweck des Kontos oder lokaler Netzwerkstatus. Dokumentieren Sie vor der ersten Verbindung die folgenden Punkte, damit sich später feststellen lässt, auf welcher Ebene eine Änderung aufgetreten ist.

Bereitzustellende Informationen

Bestellkennung, Knotenstandort, Knotenadresse, Kontozweck, Ergebnis der Host-Fingerabdruckprüfung und Zeitpunkt der ersten erfolgreichen Verbindung. Private Schlüssel werden ausschließlich auf kontrollierten Geräten gespeichert, nicht in Tickets, Chatverläufen oder Code-Repositories.

  1. 01

    Bereitstellung der Bestellung bestätigen

    Prüfen Sie Bestellstatus und Verbindungsdaten im Portal. Versuchen Sie vor abgeschlossener Bereitstellung nicht, sich über alte Adressen oder Angaben anderer Personen zu verbinden.

  2. 02

    Knotenadresse und separate Zugangsdaten speichern

    Für persönliche Vorgänge, Automatisierungsaufgaben und die vorübergehende Zusammenarbeit werden jeweils widerrufbare Konten oder Schlüssel verwendet. Ein gemeinsamer dauerhafter Zugang wird nicht genutzt.

  3. 03

    Lokale Netzwerkbasis messen

    Dokumentieren Sie Latenz, Paketverlust und Stabilität in kabelgebundenen und drahtlosen Netzwerken. Wenn die grafische Sitzung ruckelt, vergleichen Sie zuerst mit diesen Basiswerten.

  4. 04

    Kontoberechtigungen planen

    Entwicklungskonten erhalten nur die für das Arbeitsverzeichnis erforderlichen Rechte. Runner-Konten greifen ausschließlich auf Build-Verzeichnisse, Caches und notwendige Signaturressourcen zu.

SSH-Pfad

Zuerst die Host-Identität prüfen, dann Schlüssel für den täglichen Zugriff verwenden

Ziel der ersten Verbindung ist nicht, Warnungen möglichst schnell zu überspringen, sondern zu bestätigen, dass die aktuelle Adresse tatsächlich zum bereitgestellten Knoten gehört. Nach der Fingerabdruckprüfung richten Sie Alias, Keepalive-Einstellungen und Konten mit minimalen Berechtigungen ein.

SCHRITT 01

Host-Fingerabdruck prüfen

ssh-keyscan -t ed25519 NODE_ADDRESS
ssh USER@NODE_ADDRESS

Vergleichen Sie den erstmals ausgelesenen Fingerabdruck mit den Bereitstellungsdaten im Portal. Ändert sich der Fingerabdruck nach einem Adresswechsel oder einer Systeminstallation, klären Sie zuerst die Ursache. Löschen Sie nicht einfach die lokalen Einträge und verbinden Sie sich weiter.

SCHRITT 02

Eigenen Schlüssel erzeugen und bereitstellen

ssh-keygen -t ed25519 -a 64
ssh-copy-id USER@NODE_ADDRESS

Erzeugen Sie für den VMRunner-Knoten einen separaten Schlüssel. Schützen Sie den privaten Schlüssel mit einer lokalen Passphrase, committen Sie ihn nicht in ein Repository und verwenden Sie ihn nicht gemeinsam mit dem Bereitstellungsschlüssel des Runners.

SCHRITT 03

Alias und Verbindungsaufrechterhaltung konfigurieren

Host vmrunner-build
  HostName NODE_ADDRESS
  User ACCOUNT_NAME
  IdentityFile ~/.ssh/vmrunner_ed25519
  ServerAliveInterval 30
  ServerAliveCountMax 3

Ein Alias reduziert Fehler beim Abtippen von Adressen. Keepalive-Parameter erkennen lediglich eine verlorene Verbindung; bereits unterbrochene Prozesse werden dadurch nicht automatisch fortgesetzt. Lange Aufgaben gehören in einen Aufgabenmanager oder CI-Runner.

Grenzen minimaler Berechtigungen

Verwenden Sie Administratorrechte nicht standardmäßig im Alltag. Abhängigkeitsinstallation, Systemkonfiguration und Pipelineausführung sollten getrennten Konten zugeordnet werden. Nach einer vorübergehenden Rechteerhöhung kehren Sie sofort zu normalen Berechtigungen zurück und dokumentieren Sie die Änderungen.

Grafische Sitzung

Bildqualität nur so hoch einstellen wie für die Aufgabe erforderlich

Remote-Desktop eignet sich für Vorgänge, bei denen Xcode, der Simulator oder eine Timeline sichtbar sein müssen, nicht jedoch als Ersatz für alle Hintergrundaufgaben. Starten Sie mit einer niedrigeren Auflösung eine stabile Sitzung und erhöhen Sie die Bildqualität schrittweise.

  • Bestätigen Sie auf dem bereitgestellten Knoten, dass der grafische Remote-Dienst aktiviert ist, und beschränken Sie die zulässigen Konten.
  • Testen Sie zunächst mit einem Bildschirm und niedriger Auflösung. Erhöhen Sie die Konfiguration erst, wenn Eingaben und Bild stabil sind.
  • Prüfen Sie Command, Option, Control und das lokale Tastaturlayout, um Fehlbedienungen durch Tastenkürzel zu vermeiden.
  • Übertragen Sie über die Zwischenablage nur notwendige Texte. Kopieren Sie keine privaten Schlüssel, vollständigen Tokens oder Zertifikatspasswörter.
  • Sperren Sie die Sitzung beim Verlassen. Trennen Sie die Verbindung nach Abschluss der Aufgabe aktiv, damit ungenutzte Desktops nicht dauerhaft geöffnet bleiben.

Reihenfolge für die Grafikeinstellungen

Mit Stabilität beginnen
01 Auflösung

Wählen Sie zunächst die niedrigste Stufe, auf der die Toolfenster vollständig sichtbar sind, und beobachten Sie Eingabelatenz und Bildaktualisierung.

02 Farben und Animationen

Reduzieren Sie bei Netzwerkschwankungen die visuellen Effekte und reservieren Sie Bandbreite vorrangig für Bedienungsfeedback und Dateisynchronisation.

03 Tastaturbelegung

Testen Sie häufige Tastenkürzel zunächst in einem risikofreien Textfenster, bevor Sie Signier-, Lösch- oder Veröffentlichungsvorgänge starten.

04 Sitzung sperren

Prüfen Sie nach einer Unterbrechung zuerst den Status der alten Sitzung, damit Tools nicht doppelt gestartet und Arbeitsverzeichnisse nicht gleichzeitig verwendet werden.

Migrationspfad

Vom lokalen Mac zum Cloud Mac: in drei Schritten prüfen

Verschieben Sie nicht auf einmal den gesamten Code, Zertifikate, Caches und Pipelines. Bewahren Sie für jeden Schritt überprüfbare Ergebnisse auf und beginnen Sie den nächsten erst nach erfolgreichem Abschluss des vorherigen.

01 · DATEN

Datensynchronisation

Synchronisieren Sie zunächst Repository, Sperrdateien, notwendige Assets und Build-Skripte. Große Caches und erneut herunterladbare Abhängigkeiten gehören nicht zur ersten Migrationsrunde.

  • Standard-Branch und Commit-Hash prüfen
  • Versionen der Abhängigkeitssperrdateien dokumentieren
  • Prüfsummen wichtiger Assets vergleichen
Ausgabe: Im Cloud Mac reproduzierbare Codebasis
02 · TOOLCHAIN

Toolchain installieren

Prüfen Sie Xcode, Kommandozeilentools, Paketmanager, Zertifikate und Bereitstellungsprofile. Führen Sie zuerst ein kleines Testziel aus, nicht direkt die vollständige Release-Pipeline.

  • Xcode- und SDK-Versionen festlegen
  • Auswahlpfad der Kommandozeilentools bestätigen
  • Abhängigkeitscache und Build-Verzeichnis trennen
Ausgabe: Umgebungsübersicht mit bestandenem Test-Build
03 · RUNNER

CI-Anbindung

Erstellen Sie ein eigenes Runner-Konto, begrenzen Sie den Zugriff auf Umgebungsvariablen, führen Sie eine rücksetzbare Testaufgabe aus und übertragen Sie das Artefakt.

  • Eigenes Arbeitsverzeichnis für den Runner einrichten
  • Nur für die aktuelle Aufgabe erforderliche Variablen injizieren
  • Logs, Exit-Code und Artefakt-Hash prüfen
Ausgabe: Erste auditierbare Cloud-Pipeline
Umgebung prüfen

Die Entwicklungsumgebung als Liste dokumentieren statt aus dem Gedächtnis zu rekonstruieren

Wenn derselbe Code auf zwei Macs unterschiedlich läuft, liegt das meist an abweichenden Toolversionen, Pfaden, Caches oder Berechtigungen. Die folgenden Punkte sollten vor dem ersten produktiven Build einzeln dokumentiert werden.

Prüfpunkt Prüfmethode Erfolgskriterium
Xcode und SDK xcodebuild -version Version entspricht der Projektbasis
Kommandozeilentools xcode-select -p Pfad zeigt auf das Ziel-Xcode
Zertifikate und Bereitstellungsprofile Signaturprüfung mit bereinigten Daten ausführen Zielname und Gültigkeitsbereich stimmen überein
Paketmanager Version und Status der Sperrdatei dokumentieren Abhängigkeiten lassen sich reproduzierbar installieren
Cache-Verzeichnisse Eigentümer, Größe und Bereinigungsregeln prüfen Persönliche Aufgaben und CI sind getrennt
Build-Verzeichnis Nach einer Bereinigung einen Test-Build ausführen Artefaktpfad und Berechtigungen sind eindeutig
CI-Anbindung

Automatisierte Aufgaben mit eigener Identität und eigenem Arbeitsverzeichnis ausstatten

Der Runner sollte nicht das Desktop-Konto des Entwicklers wiederverwenden. Eine eigene Identität erleichtert den Widerruf von Berechtigungen, die Cache-Bereinigung und die Zuordnung von Dateieigentümern. Außerdem werden persönliche Sitzungen weniger durch Pipelines beeinflusst.

CI-Fehlerbehebung ansehen
  1. 01

    Eigenes Konto erstellen

    Das Konto greift nur auf Repository-Arbeitsbereich, Abhängigkeitscache, Build-Verzeichnis und notwendige Signaturressourcen zu. Alltägliche Administratorrechte werden nicht vergeben.

  2. 02

    Runner registrieren

    Verwenden Sie den vom Pipeline-System bereitgestellten Registrierungsprozess, um den aktuellen Knoten zu binden. Vergeben Sie Runner-Tags, die Chip, System und Aufgabentyp erkennen lassen.

  3. 03

    Kontrollierte Variablen injizieren

    Konfigurieren Sie Variablen nach Repository, Umgebung und Aufgabenbereich. Verbergen Sie sensible Werte in Logs und geben Sie keine vollständigen Konfigurationsdateien in Build-Protokollen aus.

  4. 04

    Test-Build ausführen

    Beginnen Sie mit einem Ziel mit wenigen Abhängigkeiten und kurzer Laufzeit. Prüfen Sie Exit-Code, Testergebnisse, Cache-Treffer und die Bereinigung des Arbeitsverzeichnisses.

  5. 05

    Artefakte übertragen und prüfen

    Dokumentieren Sie Artefaktname, erzeugenden Commit, Prüfsumme und Speicherort. Erweitern Sie erst nach erfolgreicher Übertragung auf die vollständige Pipeline.

Sicherer Abschluss

Eine erfolgreiche Verbindung bedeutet noch keine abgeschlossene Migration

Prüfen Sie vor dem produktiven Einsatz nochmals Zugangsdaten, Freigabebereiche, Sicherungen und Wiederherstellungsinformationen. Ziel ist, jedes Konto, jede Sitzung und jede Automatisierungsaufgabe einzeln widerrufen zu können.

A

Initiale Zugangsdaten wechseln

Ändern Sie nach der ersten Validierung das initiale Passwort oder den Schlüssel, entfernen Sie nicht mehr benötigte temporäre Berechtigungen und dokumentieren Sie Verwendungszweck sowie Verantwortliche der Zugangsdaten.

B

Gemeinsam genutzte Konten begrenzen

Jede Person und jeder Runner verwendet eine eigene Identität. Bei Berechtigungsänderungen widerrufen Sie nur das betreffende Konto, ohne andere Workloads zu beeinträchtigen.

C

Wichtige Daten sichern

Code wird primär in einem Remote-Repository gespeichert. Signaturmaterial, Projekt-Assets und wichtige Artefakte werden nach Teamrichtlinie gesichert; der Wiederherstellungsprozess wird regelmäßig geprüft.

D

Inaktive Sitzungen trennen

Sperren und schließen Sie nicht mehr benötigte grafische Sitzungen, beenden Sie temporäre Dienste und prüfen Sie, ob Hintergrundaufgaben noch einen klaren Eigentümer haben.

E

Wiederherstellungsinformationen speichern

Dokumentieren Sie Bestellkennung, Knotenstandort, Kontozweck, Toolversionen und den letzten erfolgreichen Build, damit der Support Probleme schnell eingrenzen kann.

Für Supportanfragen reproduzierbare Informationen vorbereiten

Übermitteln Sie Bestellkennung, Knotenstandort, Zeitpunkt, Reproduktionsschritte, bereinigte Logs und erwartetes Ergebnis. Senden Sie keine privaten Schlüssel, vollständigen Zugriffstokens, Zertifikatspasswörter oder unbereinigten Konfigurationsdateien.

Startklar

Nach Auswahl des Knotens die gesamte Verbindungskette mit einem kleinen Build prüfen

Prüfen Sie zunächst Zugangsdaten, Toolversionen und die Übertragung eines Testartefakts. Migrieren Sie das produktive Projekt erst danach auf einen dedizierten Apple-Silicon-Physikknoten.