Connexion, migration et dépannage

Intégrez un Mac dans le cloud à votre workflow

Vérifiez d’abord le nœud et les informations de connexion dans la console, puis établissez une première session via SSH ou VNC. En cas de problème de migration, de build ou de service MLX, suivez l’ordre indiqué pour isoler la cause sans multiplier les suppositions.

3 étapes
Connexion, migration, intégration
2 accès
SSH et VNC
365 jours
Nœud opérationnel
Louer un Mac dans le cloud Se connecter à la console
Guide de première connexion VMKeep / CONNECT
À vérifier
01
Compte et commande

Vérifiez que l’état de la commande, la région du nœud, le nom de la machine et la durée de location correspondent.

Console
02
Informations de connexion

Copiez l’adresse de l’hôte, le nom d’utilisateur et les identifiants temporaires. Ne les transmettez pas à des personnes non concernées.

SSH / VNC
03
Mise à jour des identifiants

Après la première connexion, modifiez le mot de passe et ajoutez la clé publique SSH de l’équipe.

Requis
04
Vérification de référence

Notez la version de macOS, Xcode, l’espace disque disponible et les résultats de l’accès réseau.

Recommandé
Conservez la sortie des commandes et l’heure de l’incident avant d’ouvrir un ticket RUNBOOK-04
Parcours de première connexion

Établissez d’abord une référence de connexion reproductible

Ne commencez pas par migrer le dépôt ou installer de nombreuses dépendances. Effectuez d’abord les quatre vérifications de base afin de confirmer l’identité de la machine, le mode de connexion et la mise à jour des identifiants.

  1. 01 Vérification du compte

    Vérifiez les informations de la console

    Connectez-vous à la console et vérifiez le numéro de commande, la région du nœud, le nom de la machine, la durée de location et les informations de connexion. Si le nœud et la commande ne correspondent pas, arrêtez-vous pour éviter de migrer les fichiers vers la mauvaise machine.

    • Notez le numéro de commande et la région du nœud
    • Confirmez le nom de la machine et la durée de location
    • Lisez les informations de connexion uniquement dans la console
  2. 02 Établissement de la session

    Choisissez SSH ou VNC

    Privilégiez SSH pour la configuration en ligne de commande, l’automatisation et l’analyse des journaux ; utilisez VNC pour l’interface graphique, les réglages Xcode ou les opérations sur le bureau. Lors de la première connexion, validez les deux méthodes séparément.

    • Vérifiez l’empreinte de l’hôte et le nom d’utilisateur SSH
    • Vérifiez l’adresse VNC et la résolution d’affichage
    • Notez l’environnement réseau utilisé pour la connexion réussie
  3. 03 Mise à jour des identifiants

    Remplacez le mot de passe et ajoutez la clé publique

    Après avoir accédé à la machine, remplacez immédiatement le mot de passe temporaire, puis ajoutez la clé publique SSH approuvée par l’équipe à la liste autorisée. Attribuez une clé distincte à chaque membre et révoquez-la séparément à son départ du projet.

    • Utilisez un mot de passe distinct et suffisamment long
    • Conservez une clé publique distincte pour chaque membre
    • Limitez la diffusion des clés privées et des informations de connexion
  4. 04 Enregistrement de la référence

    Vérifiez l’état du système et du disque

    Avant d’installer des outils, notez la version du système, le chemin Xcode, l’espace disque disponible et les résultats réseau de base. Vous pourrez comparer directement les incidents ultérieurs à cette référence.

    • sw_vers Afficher la version du système
    • xcode-select -p Afficher le chemin de la chaîne d’outils
    • df -h Afficher l’espace disque
Parcours de migration

Du Mac local au Mac dans le cloud en trois migrations

L’ordre de migration détermine le coût du dépannage. Transférez d’abord les données vérifiables, restaurez ensuite une chaîne d’outils aux versions fixes, puis intégrez la CI ou le self-hosted runner.

01
Synchronisation des données

Ne migrez que les fichiers nécessaires

Récupérez en priorité le dépôt via Git. Synchronisez séparément les grands modèles, caches de build et artefacts, puis vérifiez leur taille ou leur somme de contrôle après le transfert.

Entrées
Dépôt, fichiers de modèles, scripts, configuration nécessaire
Vérifications
Droits des répertoires, règles d’exclusion, espace disque restant
Résultat
Copie de travail du projet, vérifiable indépendamment
02
Restauration de la chaîne d’outils

Figez les versions de Xcode et des dépendances

Confirmez les versions requises de Xcode, des outils en ligne de commande, de Ruby, Node.js et CocoaPods. Lancez d’abord un build minimal, puis restaurez le cache complet des dépendances.

Entrées
Liste des versions, fichiers de verrouillage, scripts d’installation
Vérifications
Xcode par défaut, SDK, runtime et PATH
Résultat
Commande de build locale reproductible
03
Intégration de l’automatisation

Enregistrez le runner et observez la première tâche

Séparez les répertoires de travail, de cache et de journaux du runner. N’exécutez pas la première tâche en parallèle : observez d’abord les sorties de récupération, de build, de test et d’archivage.

Entrées
Informations d’enregistrement du runner et étiquettes de tâche
Vérifications
Utilisateur d’exécution, droits des répertoires, code de sortie en cas d’échec
Résultat
Tâche reproductible avec journaux traçables
Journal d’exécution des commandes

Validez SSH, le build et l’archivage avec le parcours le plus court

Les exemples ci-dessous montrent l’ordre du diagnostic et ne contiennent aucun identifiant propre au projet. Validez d’abord la session distante, exécutez ensuite le build Xcode, puis vérifiez que l’outil d’automatisation renvoie un état de réussite.

Session de build VMKeep · zsh SESSION 01
09:14:02 $ ssh vmkeep@203.0.113.24
hôte vmkeep-m4-plus région JP shell /bin/zsh
09:14:18 $ xcodebuild -workspace Client.xcworkspace -scheme Client -configuration Release build

[1/4] Résolution des dépendances du package

[2/4] Compilation des sources et des ressources

[3/4] Exécution des tests unitaires

[4/4] Archivage de la sortie du build

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

En cas d’échec, conservez au moins 30 lignes de sortie avant et après la commande concernée, le code de sortie, la version de Xcode et l’heure de l’incident. Avant d’ouvrir un ticket, supprimez les jetons, clés privées et données de signature.

Intégration CI/CD

Gérez séparément le runner, le répertoire de travail et le cache

Les problèmes de build continu proviennent souvent de l’identité d’exécution, des droits de répertoire, de dérives de version ou d’un cache contaminé. Définissez ces cinq points avant la première pipeline officielle.

A1

Enregistrer le runner

Enregistrez le self-hosted runner avec un utilisateur d’exécution dédié et définissez des étiquettes claires par type de build. Vérifiez qu’il revient automatiquement en ligne après le redémarrage du service.

Identité et étiquettes
A2

Planifier les répertoires de travail

Placez l’extraction du code, les builds temporaires, les artefacts archivés et les journaux dans des répertoires distincts afin que les fichiers d’une tâche échouée n’affectent pas la suivante.

Droits et nettoyage
A3

Définir les limites du cache

La clé de cache doit au minimum inclure le fichier de verrouillage des dépendances, la version de Xcode et l’architecture. En cas d’erreur de compilation inexpliquée, relancez d’abord avec un cache vide.

Versions et correspondances
A4

Protéger les éléments de signature

Injectez les fichiers de signature, mots de passe et jetons uniquement pendant l’exécution de la tâche. Ne les écrivez ni dans le dépôt, ni dans les journaux courants, ni dans un répertoire partagé durable. Supprimez les copies temporaires à la fin de la tâche.

Exposition minimale
A5

Définir les nouvelles tentatives

Distinguez d’abord les échecs de récupération réseau, de résolution des dépendances, de compilation et de test. Ne réessayez automatiquement une étape qu’après avoir confirmé que la tâche est idempotente.

Codes de sortie et journaux
Étapes CI/CD et éléments à vérifier
Étape Vérification prioritaire Résultat à conserver À exclure des journaux
Récupération du code Droits du dépôt, adresse distante, résolution réseau Hash du commit, branche, commande en échec Jeton d’accès en clair
Installation des dépendances Fichier de verrouillage, configuration du miroir, clé de cache Versions des outils, sortie de résolution des dépendances Identifiants privés en clair
Build Xcode scheme, SDK, configuration de build, plateforme cible Commande complète, code de sortie, erreur clé Mot de passe de signature
Tests et archivage Cible de test, délai d’expiration, répertoire des artefacts Rapport de test, chemin d’archive, durée de la tâche Fichier source des éléments de signature
Dépannage du service MLX

Du résultat d’inférence local à l’API distante

Prouvez d’abord que le modèle traite une requête localement sur la machine, puis vérifiez l’adresse d’écoute et le port. Ne diagnostiquez pas le client distant avant le chargement réussi du modèle.

  1. 01

    Confirmer le chemin du modèle

    Vérifiez le répertoire du modèle, les fichiers de poids et les droits de lecture dans la configuration. Les chemins relatifs doivent être interprétés depuis le répertoire de travail réel du service.

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

    Surveiller l’utilisation de la mémoire

    Chargez le modèle avec une seule requête et notez l’évolution de la mémoire avant et après. Si le processus se termine, consultez les journaux système et son code de sortie.

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

    Vérifier l’écoute locale

    Confirmez l’adresse et le port auxquels le service est lié. S’il écoute uniquement sur l’adresse de bouclage, le client distant ne peut pas se connecter directement.

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

    Envoyer une requête locale

    Depuis le Mac dans le cloud, envoyez une requête minimale et notez le statut de réponse, la latence du premier token, la durée totale et le contenu renvoyé par le modèle.

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

    Tester ensuite l’API distante

    Une fois la requête locale réussie, vérifiez l’accès distant depuis un client autorisé. Comparez l’heure côté client, les journaux du service et l’identifiant de requête.

    curl -sS https://<YOUR-ENDPOINT>/health
Compatibilité du modèle

La possibilité d’exécuter un modèle donné dépend de son format, de sa méthode de quantification, des versions de dépendances et de la configuration mémoire choisie.

Évaluation des performances

Comparez la latence du premier token et le débit soutenu avec un modèle, des paramètres et un niveau de concurrence constants.

Éléments à joindre au ticket

Indiquez la structure du chemin du modèle, la commande de démarrage, les journaux du processus, le résultat de l’écoute et une requête minimale désensibilisée.

Petit glossaire

Huit termes courants pour l’accès et le dépannage

Une terminologie uniforme réduit les malentendus au sein de l’équipe. Dans vos tickets, utilisez autant que possible les appellations ci-dessous pour décrire la machine, le mode de connexion et le rôle de la tâche.

Nœud physique
Appareil Apple Silicon exécutant réellement macOS et les tâches, et non une instance de calcul abstraite.
Dédié
Une commande correspond à une machine physique indépendante ; ses ressources ne sont pas partagées avec d’autres locataires sur la même instance.
Sans virtualisation
Le système et les tâches s’exécutent directement sur l’appareil physique attribué, sans instance virtualisée partagée.
VNC
Mode de connexion distante permettant d’accéder à l’interface graphique de macOS, adapté aux réglages Xcode et aux opérations sur le bureau.
SSH
Connexion distante chiffrée destinée à l’administration en ligne de commande, au transfert de fichiers, à l’analyse des journaux et à l’automatisation.
self-hosted runner
Exécuteur autogéré enregistré dans le système CI de l’équipe, qui réalise les builds sur ce Mac dans le cloud.
MLX
Framework de machine learning pour Apple Silicon, utilisable pour la conversion, la quantification, l’inférence et l’encapsulation de modèles en service.
Cache de build
Fichiers intermédiaires conservés pour éviter les téléchargements et compilations répétitifs ; une clé de cache incomplète peut réintroduire d’anciens résultats.
Problèmes de connexion courants

Vérifiez selon les symptômes, sans ignorer les bases

Pour chaque problème, vérifiez d’abord la commande et le nœud, puis l’état du client, du réseau et de la machine. Ouvrez la rubrique correspondante pour consulter l’ordre recommandé et les informations à fournir.

Impossible de se connecter en SSH ou VNC

Ordre des vérifications :Confirmez la commande et les informations du nœud, recopiez l’adresse de l’hôte et le nom d’utilisateur, vérifiez la disposition du clavier et les caractères du mot de passe, contrôlez l’empreinte SSH ou l’adresse VNC, puis réessayez depuis un réseau connu comme fiable.

Informations à fournir :Numéro de commande, région du nœud, heure de l’incident, nom du client, texte complet de l’erreur et commande de connexion dont les éléments sensibles de l’hôte ont été masqués.

Déconnexions fréquentes après l’établissement de la connexion

Ordre des vérifications :Notez l’heure des coupures, testez la stabilité du réseau local, désactivez les proxys susceptibles de modifier le routage, vérifiez le réglage SSH keepalive et déterminez si les coupures coïncident avec une tâche fortement chargée.

Informations à fournir :Plage horaire des coupures, environnement réseau, nombre de tests consécutifs, journaux client, type de tâche et charge système avant et après la coupure.

Latence ou saccades de l’affichage VNC

Ordre des vérifications :Réduisez la résolution et la qualité des couleurs, interrompez les synchronisations gourmandes en bande passante, comparez les réseaux filaire et sans fil, puis vérifiez si le problème apparaît uniquement à certaines heures ou avec un client précis.

Informations à fournir :Région du nœud, version du client, résolution d’affichage, type de réseau local, heure d’apparition de la latence et étapes reproductibles.

Espace disque insuffisant ou répertoire de build en croissance continue

Ordre des vérifications :Exécutez df -h pour afficher les partitions, puis mesurez par répertoire DerivedData, les artefacts archivés, le cache des dépendances, les données des simulateurs et l’espace de travail des tâches. Vérifiez l’export des artefacts avant toute suppression.

Informations à fournir :Résultat de l’utilisation disque, répertoire à la croissance la plus rapide, tâches récentes, commandes de nettoyage exécutées et nécessité éventuelle d’évaluer une extension de stockage.

Le build local réussit, mais la tâche du runner échoue

Ordre des vérifications :Comparez l’utilisateur d’exécution, les variables d’environnement, le répertoire de travail, la version de Xcode, le fichier de verrouillage des dépendances et les clés de cache. Exécutez manuellement la même commande avec l’identité du runner afin d’identifier le premier écart.

Informations à fournir :Commande de build complète, version de Xcode, étiquettes du runner, code de sortie, journaux désensibilisés et différences entre l’exécution manuelle et la tâche automatisée.

Accès à l’assistance

Rassemblez d’abord les éléments, puis choisissez le canal de contact

Pour un problème lié à une commande existante ou à un nœud en cours d’exécution, ouvrez en priorité un ticket depuis la console ; pour le choix de la solution, le périmètre de déploiement ou une demande avant commande, contactez-nous par e-mail depuis la page de contact.

Liste des informations du ticket

Les éléments qui permettent de lancer directement le diagnostic

5 ÉLÉMENTS
Numéro de commande

Il sert à retrouver la machine et la durée de location correspondantes. Ne transmettez pas le mot de passe du compte.

Région du nœud

Indiquez Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong ou côte Est des États-Unis.

Heure de l’incident

Fournissez une plage horaire avec le fuseau pour faire correspondre les connexions et les tâches.

Sortie des commandes

Conservez le code de sortie et le contexte autour de l’erreur, en supprimant les jetons et identifiants sensibles.

Étapes de reproduction

Décrivez le parcours depuis l’état initial jusqu’à l’apparition du problème, avec le résultat attendu et le résultat réel à chaque étape.

Commande existante

Ouvrir un ticket depuis la console

Convient aux problèmes de connexion, à l’état de la machine, aux builds, à la facturation et aux problèmes liés à une commande. Le ticket conserve le contexte pour faciliter l’ajout de journaux désensibilisés.

Ouvrir un ticket dans la console
Avant-vente et déploiement

Préparez un e-mail depuis la page de contact

Convient aux questions sur le choix de configuration, le périmètre de déploiement de l’équipe, le nœud cible et la durée de location. L’adresse de contact est support@vmkeep.com.

Contacter l’équipe de service
Étape suivante

Choisissez d’abord la configuration, puis établissez la référence de connexion

Les trois configurations de machines physiques Apple Silicon dédiées sont sans virtualisation et disponibles à la location à la journée, à la semaine, au mois ou au trimestre. La disponibilité en temps réel des nœuds est indiquée par la console.

Choisir une configuration et louer Voir les trois formules de location