Verbindung, Migration und Fehlerbehebung

Den Cloud-Mac in Ihren bestehenden Workflow integrieren

Prüfen Sie zuerst Knoten und Verbindungsdaten in der Konsole und stellen Sie dann über SSH oder VNC die erste Sitzung her. Grenzen Sie Probleme bei Migration, Builds oder MLX anhand dieser Reihenfolge ein, statt Konfiguration, Netzwerk und Aufgabenprotokolle wiederholt auf Verdacht zu prüfen.

3 Phasen
Verbindung, Migration, Integration
2 Zugänge
SSH und VNC
365 Tage
Knoten durchgehend verfügbar
Cloud-Mac sofort mieten Konsole öffnen
Checkliste für die erste Einrichtung VMKeep / CONNECT
Zu prüfen
01
Konto und Bestellung

Prüfen Sie, ob Bestellstatus, Knotenregion, Rechnername und Mietdauer übereinstimmen.

Konsole
02
Verbindungsdaten

Kopieren Sie Hostadresse, Benutzernamen und temporäre Zugangsdaten und geben Sie sie nicht an unbeteiligte Personen weiter.

SSH / VNC
03
Zugangsdaten aktualisieren

Ändern Sie nach der ersten Verbindung das Passwort und fügen Sie den SSH-Public-Key des Teams hinzu.

Erforderlich
04
Baseline prüfen

Dokumentieren Sie macOS, Xcode, freien Speicher und das Ergebnis des Netzwerkzugriffs.

Empfohlen
Befehlsausgaben und Zeitpunkt vor dem Erstellen eines Tickets sichern RUNBOOK-04
Pfad zur ersten Verbindung

Zuerst eine reproduzierbare Verbindungs-Baseline schaffen

Migrieren Sie nicht sofort Repositorys oder zahlreiche Abhängigkeiten. Führen Sie zunächst vier grundlegende Prüfungen durch, damit Rechneridentität, Verbindungsart und Aktualisierung der Zugangsdaten zuverlässig funktionieren.

  1. 01 Kontobestätigung

    Konsolendaten prüfen

    Melden Sie sich an der Konsole an und prüfen Sie Bestellnummer, Knotenregion, Rechnername, Mietdauer und Verbindungsdaten. Stimmen Knoten und Bestellung nicht überein, stoppen Sie zunächst alle Vorgänge, damit Dateien nicht auf den falschen Rechner migriert werden.

    • Bestellnummer und Knotenregion dokumentieren
    • Rechnername und Mietdauer bestätigen
    • Verbindungsdaten ausschließlich aus der Konsole übernehmen
  2. 02 Sitzung herstellen

    SSH oder VNC auswählen

    Für Befehlszeilenkonfiguration, Automatisierung und Protokollprüfung bevorzugt SSH verwenden; für grafische Oberflächen, Xcode-Einstellungen oder Desktop-Aktionen VNC nutzen. Bei der ersten Verbindung empfiehlt sich jeweils eine separate Prüfung.

    • SSH: Hostschlüssel und Benutzernamen prüfen
    • VNC: Adresse und Bildschirmauflösung prüfen
    • Netzwerkumgebung der erfolgreichen Verbindung dokumentieren
  3. 03 Zugangsdaten aktualisieren

    Passwort ändern und Public-Key hinterlegen

    Ändern Sie nach dem Anmelden am Rechner sofort das temporäre Passwort und hinterlegen Sie anschließend den vom Team freigegebenen SSH-Public-Key in der Autorisierungsliste. Verwenden Sie pro Mitglied einen eigenen Schlüssel und widerrufen Sie ihn beim Ausscheiden aus dem Projekt separat.

    • Ein eigenes, ausreichend langes Passwort verwenden
    • Für jedes Mitglied einen eigenen Public-Key hinterlegen
    • Verteilung von Private Keys und Verbindungsdaten begrenzen
  4. 04 Baseline dokumentieren

    System- und Festplattenstatus prüfen

    Dokumentieren Sie vor der Installation von Tools die Systemversion, den Xcode-Pfad, den freien Speicher und die grundlegenden Netzwerkergebnisse. Spätere Fehler lassen sich direkt mit dieser Baseline vergleichen.

    • sw_vers Systemversion anzeigen
    • xcode-select -p Toolchain-Pfad anzeigen
    • df -h Festplattenspeicher anzeigen
Migrationspfad

Vom lokalen Mac zum Cloud-Mac: Migration in drei Schritten

Die Reihenfolge der Migration bestimmt den Aufwand für die Fehlerbehebung. Übertragen Sie zuerst prüfbare Daten, stellen Sie danach die Toolchain mit festen Versionen wieder her und binden Sie zuletzt CI oder den self-hosted runner an.

01
Datensynchronisierung

Nur notwendige Dateien migrieren

Laden Sie das Code-Repository bevorzugt über Git. Große Modelle, Build-Caches und Artefakte sollten separat synchronisiert werden. Prüfen Sie nach der Übertragung Dateigrößen oder Prüfsummen.

Eingaben
Repository, Modelldateien, Skripte, erforderliche Konfiguration
Prüfung
Verzeichnisberechtigungen, Ignore-Regeln, freier Speicher
Ergebnis
Eigenständig prüfbare Arbeitskopie des Projekts
02
Toolchain wiederherstellen

Xcode- und Abhängigkeitsversionen festlegen

Prüfen Sie die für das Projekt erforderlichen Versionen von Xcode, Command-Line-Tools, Ruby, Node.js und CocoaPods. Führen Sie zunächst einen Minimal-Build aus und stellen Sie erst danach den vollständigen Abhängigkeits-Cache wieder her.

Eingaben
Versionsliste, Lockfiles, Installationsskripte
Prüfung
Standard-Xcode, SDK, Laufzeitumgebung und PATH
Ergebnis
Reproduzierbar ausführbarer lokaler Build-Befehl
03
Automatisierung integrieren

Runner registrieren und ersten Lauf beobachten

Trennen Sie Arbeits-, Cache- und Protokollverzeichnis des Runners. Führen Sie den ersten Job nicht parallel aus, sondern beobachten Sie zunächst die Ausgaben von Abruf, Build, Tests und Archivierung.

Eingaben
Registrierungsdaten und Job-Tags des Runners
Prüfung
Ausführender Benutzer, Verzeichnisberechtigungen, Exit-Code bei Fehlern
Ergebnis
Reproduzierbar ausführbarer Job mit nachvollziehbaren Protokollen
Befehlsprotokoll

SSH, Build und Archivierung mit einer kurzen Kette prüfen

Die folgende Aufzeichnung zeigt die Prüfungsreihenfolge und enthält keine projektspezifischen Zugangsdaten. Prüfen Sie zuerst die Remote-Sitzung, führen Sie anschließend den Xcode-Build aus und kontrollieren Sie zuletzt, ob das Automatisierungstool einen erfolgreichen Status meldet.

VMKeep-Buildsitzung · zsh SESSION 01
09:14:02 $ ssh vmkeep@203.0.113.24
Host vmkeep-m4-plus Region JP Shell /bin/zsh
09:14:18 $ xcodebuild -workspace Client.xcworkspace -scheme Client -configuration Release build

[1/4] Paketabhängigkeiten auflösen

[2/4] Quellen und Ressourcen kompilieren

[3/4] Unit-Tests ausführen

[4/4] Build-Ausgabe archivieren

09:22:41 $ bundle exec fastlane ios build
Build erfolgreich
exit=0 · archive=Client.xcarchive · duration=08m23s

Wenn ein Schritt fehlschlägt, sichern Sie mindestens 30 Ausgabezeilen vor und nach dem fehlschlagenden Befehl sowie Exit-Code, Xcode-Version und Zeitpunkt. Entfernen Sie vor dem Erstellen eines Tickets Token, Private Keys und Signaturmaterial.

CI/CD-Integration

Runner, Arbeitsverzeichnisse und Caches getrennt verwalten

Probleme bei kontinuierlichen Builds entstehen häufig durch Ausführungsidentität, Verzeichnisberechtigungen, Versionsabweichungen oder verunreinigte Caches. Diese fünf Punkte sollten vor dem ersten regulären Pipeline-Lauf feststehen.

A1

Runner registrieren

Registrieren Sie den self-hosted runner mit einem eigenen Ausführungsbenutzer und vergeben Sie eindeutige Tags für die Build-Typen. Prüfen Sie, ob der Runner nach einem Dienstneustart automatisch wieder online geht.

Identität und Tags
A2

Arbeitsverzeichnisse planen

Legen Sie Quell-Checkout, temporäre Builds, Archivartefakte und Jobprotokolle in getrennten Verzeichnissen ab, damit Dateien fehlgeschlagener Jobs den nächsten Lauf nicht beeinflussen.

Berechtigungen und Bereinigung
A3

Cache-Grenzen festlegen

Der Cache-Key sollte mindestens Lockfile, Xcode-Version und Architektur enthalten. Bei unerklärlichen Kompilierungsfehlern zunächst einmal mit leerem Cache erneut ausführen.

Versionen und Treffer
A4

Signaturmaterial sicher verwahren

Signaturdateien, Passwörter und Token nur während der Job-Ausführung injizieren und weder im Repository, in normalen Protokollen noch in dauerhaft gemeinsam genutzten Verzeichnissen speichern. Temporäre Kopien nach Abschluss des Jobs löschen.

Minimale Offenlegung
A5

Fehler-Wiederholungen definieren

Unterscheiden Sie zunächst Fehler beim Netzwerkabruf, bei der Abhängigkeitsauflösung, Kompilierungsfehler und Testfehler. Wiederholen Sie einen Abschnitt automatisch nur, wenn die Idempotenz des Jobs bestätigt ist.

Exit-Codes und Protokolle
Typische CI/CD-Phasen und Prüfpunkte
Phase Zuerst prüfen Zu speicherndes Ergebnis Darf nicht ins Protokoll
Code abrufen Repositoryberechtigungen, Remote-Adresse, Namensauflösung Commit-Hash, Branch, fehlgeschlagener Befehl Access-Token im Klartext
Abhängigkeiten installieren Lockfile, Mirror-Konfiguration, Cache-Key Toolversionen, Ausgabe der Abhängigkeitsauflösung Private Zugangsdaten im Klartext
Xcode-Build Scheme, SDK, Build-Konfiguration, Zielplattform Vollständiger Befehl, Exit-Code, zentrale Fehlermeldung Signaturpasswort
Tests und Archivierung Testziel, Timeout, Artefaktverzeichnis Testbericht, Archivpfad, Jobdauer Originale Signaturdatei
MLX-Service prüfen

Vom lokalen Inferenztest zur Remote-API

Beweisen Sie zunächst, dass das Modell eine Anfrage lokal auf dem Rechner verarbeitet. Prüfen Sie anschließend Bindungsadresse und Portzugriff. Untersuchen Sie den Remote-Client nicht, solange das Modell noch nicht erfolgreich geladen wurde.

  1. 01

    Modellpfad bestätigen

    Prüfen Sie Modellverzeichnis, Gewichtedateien und Leseberechtigungen in der Konfiguration. Relative Pfade müssen auf das tatsächliche Arbeitsverzeichnis des Dienstes bezogen sein.

    test -r /srv/models/model && echo readable
  2. 02

    Speicherverbrauch beobachten

    Laden Sie das Modell zunächst mit einer einzelnen Anfrage und dokumentieren Sie die Speicheränderung davor und danach. Wenn der Prozess beendet wird, prüfen Sie Systemprotokoll und Exit-Code der Anwendung.

    ps -o pid,rss,command -p <PID>
  3. 03

    Lokales Listening prüfen

    Bestätigen Sie die vom Dienst gebundene Adresse und den Port. Wenn nur die Loopback-Adresse überwacht wird, kann ein Remote-Client keine direkte Verbindung herstellen.

    lsof -nP -iTCP:<PORT> -sTCP:LISTEN
  4. 04

    Lokale Anfrage ausführen

    Senden Sie innerhalb des Cloud-Mac eine Minimalanfrage und dokumentieren Sie Antwortstatus, Time-to-First-Token, Gesamtdauer und Modellantwort.

    curl -sS http://127.0.0.1:<PORT>/health
  5. 05

    Remote-API anschließend testen

    Prüfen Sie den Remotezugriff erst nach erfolgreicher lokaler Anfrage mit einem autorisierten Client. Vergleichen Sie Clientzeit, Dienstprotokoll und Anfragekennung.

    curl -sS https://<YOUR-ENDPOINT>/health
Modellkompatibilität

Ob ein bestimmtes Modell ausgeführt werden kann, hängt von Modellformat, Quantisierung, Abhängigkeitsversionen und gewählter Speicherkonfiguration ab.

Leistung bewerten

Time-to-First-Token und anhaltender Durchsatz sollten bei festem Modell, festen Parametern und fester Parallelität verglichen werden.

Nachweise für das Ticket

Übermitteln Sie die Struktur des Modellpfads, den Startbefehl, Prozessprotokolle, Listening-Ergebnis und eine bereinigte Minimalanfrage.

Begriffsglossar

Acht wichtige Begriffe für Integration und Fehlerbehebung

Einheitliche Begriffe verringern Missverständnisse im Team. Verwenden Sie beim Erstellen eines Tickets möglichst die folgenden Bezeichnungen für Rechner, Verbindungen und Aufgabenrollen.

Physischer Knoten
Ein tatsächliches Apple-Silicon-Gerät, auf dem macOS und Aufgaben ausgeführt werden – keine abstrakte Recheninstanz.
Exklusiv
Eine Bestellung entspricht einem eigenständigen physischen Rechner; die Ressourcen derselben Instanz werden nicht mit anderen Mietern geteilt.
Keine virtuelle Maschine
System und Aufgaben laufen direkt auf dem zugewiesenen physischen Gerät und werden nicht über eine gemeinsam genutzte virtuelle Instanz bereitgestellt.
VNC
Remoteverbindung für die grafische macOS-Oberfläche, geeignet für Xcode-Einstellungen und Desktop-Aktionen.
SSH
Verschlüsselte Remoteverbindung für Befehlszeilenverwaltung, Dateiübertragung, Protokollprüfung und Automatisierung.
self-hosted runner
Ein im CI-System des Teams registrierter, selbst verwalteter Runner, der Build-Aufgaben auf diesem Cloud-Mac ausführt.
MLX
Machine-Learning-Framework für Apple Silicon, geeignet für Modellkonvertierung, Quantisierung, Inferenz und Service-Verpackung.
Build-Cache
Gespeicherte Zwischendateien zur Reduzierung wiederholter Downloads und Kompilierungen. Ein unvollständiger Cache-Key kann alte Ergebnisse einbeziehen.
Häufige Verbindungsprobleme

Nach Symptomen prüfen und grundlegende Punkte nicht überspringen

Prüfen Sie bei jeder Problemart zunächst Bestellung und Knoten und anschließend Client, Netzwerk und Systemstatus des Rechners. Öffnen Sie den passenden Eintrag für empfohlene Reihenfolge und Ticketangaben.

SSH- oder VNC-Anmeldung nicht möglich

Prüfreihenfolge:Bestellung und Knotendaten bestätigen, Hostadresse und Benutzernamen erneut kopieren, Eingabemethode und Passwortzeichen prüfen, SSH-Hostschlüssel oder VNC-Adresse abgleichen und anschließend über ein bekanntermaßen funktionierendes Netzwerk erneut testen.

Angaben für das Ticket:Bestellnummer, Knotenregion, Zeitpunkt, Clientname, vollständiger Fehlertext sowie der Verbindungsbefehl mit ausgeblendeten sensiblen Hostdaten.

Verbindung bricht nach dem Aufbau häufig ab

Prüfreihenfolge:Zeitpunkt der Unterbrechung dokumentieren, Stabilität des lokalen Netzwerks testen, einen möglicherweise routenverändernden Proxy deaktivieren und erneut testen, SSH-Keepalive-Einstellungen prüfen und feststellen, ob der Abbruch gleichzeitig mit einer stark ausgelasteten Aufgabe auftritt.

Angaben für das Ticket:Zeitraum der Unterbrechungen, Netzwerkumgebung, Anzahl aufeinanderfolgender Tests, Clientprotokolle, Aufgabentyp sowie Systemauslastung vor und nach dem Abbruch.

VNC-Bild verzögert oder reagiert ruckelig

Prüfreihenfolge:Bildschirmauflösung und Farbqualität reduzieren, bandbreitenintensive Synchronisierungen pausieren, kabelgebundene und drahtlose Netzwerke vergleichen und prüfen, ob das Problem nur zu bestimmten Zeiten oder mit einem bestimmten Client auftritt.

Angaben für das Ticket:Knotenregion, Clientversion, Bildschirmauflösung, lokaler Netzwerktyp, Zeitpunkt des Auftretens und reproduzierbare Handlungsschritte.

Zu wenig Speicher oder wachsendes Build-Verzeichnis

Prüfreihenfolge:Ausführen: df -h Partitionen anzeigen und anschließend DerivedData, Archivartefakte, Abhängigkeits-Caches, Simulatordaten und Arbeitsbereiche nach Verzeichnisgröße auswerten. Vor dem Löschen bestätigen, dass die Artefakte exportiert wurden.

Angaben für das Ticket:Speichernutzung, am schnellsten wachsendes Verzeichnis, zuletzt ausgeführte Aufgaben, bereits verwendete Bereinigungsbefehle und die Frage, ob zusätzlicher Speicher geprüft werden soll.

Lokal erfolgreich gebaut, aber Runner-Job schlägt fehl

Prüfreihenfolge:Ausführungsbenutzer, Umgebungsvariablen, Arbeitsverzeichnis, Xcode-Version, Dependency-Lockfile und Cache-Key vergleichen. Den gleichen Build-Befehl manuell unter der Identität des Runners ausführen und die erste Abweichung ermitteln.

Angaben für das Ticket:Vollständiger Build-Befehl, Xcode-Version, Runner-Tag, Exit-Code des Fehlers, bereinigte Protokolle sowie Unterschiede zwischen manueller Ausführung und automatischem Job.

Support kontaktieren

Zuerst Nachweise sammeln, dann den Kontaktweg wählen

Bei Problemen mit bestehenden Bestellungen und laufenden Knoten bevorzugt über die Konsole ein Ticket erstellen. Fragen zur Lösung, zum Bereitstellungsumfang oder vor einer Bestellung können per E-Mail über die Kontaktseite gestellt werden.

Checkliste für Ticketangaben

Informationen, mit denen die Analyse direkt beginnen kann

5 ELEMENTE
Bestellnummer

Zur Zuordnung von Rechner und Mietdauer; kein Kontopasswort einreichen.

Knotenregion

Nennen Sie Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong oder die US-Ostküste.

Zeitpunkt

Geben Sie einen Zeitraum einschließlich Zeitzone an, damit Verbindungen und Jobs zugeordnet werden können.

Befehlsausgabe

Exit-Code und Kontext vor und nach dem Fehler sichern und Token sowie vertrauliche Zugangsdaten entfernen.

Reproduktionsschritte

Vom Ausgangszustand bis zum Auftreten des Problems dokumentieren und pro Schritt erwartetes und tatsächliches Ergebnis angeben.

Bestehende Bestellung

Ticket über die Konsole erstellen

Geeignet für Verbindungsfehler, Rechnerstatus, Build-Probleme sowie Fragen zu Abrechnung und Bestellzuordnung. Das Ticket bewahrt den Kontext und ermöglicht das Nachreichen bereinigter Protokolle.

Ticket über die Konsole erstellen
Vor dem Kauf und Bereitstellung

E-Mail über die Kontaktseite vorbereiten

Geeignet für Fragen zu Konfigurationswahl, Team-Bereitstellung, Zielknoten und Mietdauer. Die zentrale Kontaktadresse lautet support@vmkeep.com.

Support-Team kontaktieren
Nächster Schritt

Konfiguration auswählen und anschließend die Verbindungs-Baseline erstellen

Alle drei Apple-Silicon-Konfigurationen sind exklusive physische Rechner und keine virtuellen Maschinen. Sie können tage-, wochen-, monats- oder quartalsweise gemietet werden. Die aktuelle Verfügbarkeit der Knoten zeigt die Konsole an.

Konfiguration auswählen und mieten Drei Mietmodelle ansehen