Zugangsplan
Ü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.
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.
Ü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.
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.
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.
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.
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.
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.
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.
Prüfen Sie Bestellstatus und Verbindungsdaten im Portal. Versuchen Sie vor abgeschlossener Bereitstellung nicht, sich über alte Adressen oder Angaben anderer Personen zu verbinden.
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.
Dokumentieren Sie Latenz, Paketverlust und Stabilität in kabelgebundenen und drahtlosen Netzwerken. Wenn die grafische Sitzung ruckelt, vergleichen Sie zuerst mit diesen Basiswerten.
Entwicklungskonten erhalten nur die für das Arbeitsverzeichnis erforderlichen Rechte. Runner-Konten greifen ausschließlich auf Build-Verzeichnisse, Caches und notwendige Signaturressourcen zu.
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.
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.
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.
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.
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.
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.
Wählen Sie zunächst die niedrigste Stufe, auf der die Toolfenster vollständig sichtbar sind, und beobachten Sie Eingabelatenz und Bildaktualisierung.
Reduzieren Sie bei Netzwerkschwankungen die visuellen Effekte und reservieren Sie Bandbreite vorrangig für Bedienungsfeedback und Dateisynchronisation.
Testen Sie häufige Tastenkürzel zunächst in einem risikofreien Textfenster, bevor Sie Signier-, Lösch- oder Veröffentlichungsvorgänge starten.
Prüfen Sie nach einer Unterbrechung zuerst den Status der alten Sitzung, damit Tools nicht doppelt gestartet und Arbeitsverzeichnisse nicht gleichzeitig verwendet werden.
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.
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.
Prüfen Sie Xcode, Kommandozeilentools, Paketmanager, Zertifikate und Bereitstellungsprofile. Führen Sie zuerst ein kleines Testziel aus, nicht direkt die vollständige Release-Pipeline.
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.
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.
xcodebuild -version
Version entspricht der Projektbasis
xcode-select -p
Pfad zeigt auf das Ziel-Xcode
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 ansehenDas Konto greift nur auf Repository-Arbeitsbereich, Abhängigkeitscache, Build-Verzeichnis und notwendige Signaturressourcen zu. Alltägliche Administratorrechte werden nicht vergeben.
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.
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.
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.
Dokumentieren Sie Artefaktname, erzeugenden Commit, Prüfsumme und Speicherort. Erweitern Sie erst nach erfolgreicher Übertragung auf die vollständige Pipeline.
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.
Ä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.
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.
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.
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.
Dokumentieren Sie Bestellkennung, Knotenstandort, Kontozweck, Toolversionen und den letzten erfolgreichen Build, damit der Support Probleme schnell eingrenzen kann.
Ü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.
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.