Trouvez le problème par tâche

Centre d’aide Mac dans le cloud : du dépannage de la connexion aux builds

Commencez par déterminer si le problème concerne la mise en service, la connexion, les outils, le pipeline, le stockage ou la location. Vérifiez ensuite le nœud, les identifiants, le port, le disque et les tâches système. Chaque parcours précise quoi vérifier, quoi faire et quelles informations joindre à un ticket.

6 catégories de tâches
Mise en service, connexion, outils, CI/CD, stockage, location
Diagnostic en 5 étapes
Du périmètre du nœud à la tâche précise
2 canaux d’assistance
Tickets dans la console et e-mail d’assistance
Tableau de diagnostic

Consignez d’abord les faits, puis modifiez la configuration

Vérification séquentielle
  1. 01
    Vérifier le nœud de la commande Noter le centre de données, le nom d’hôte et l’état de la commande
  2. 02
    Vérifier l’état des identifiants Contrôler les clés, leur validité et leur dernière rotation
  3. 03
    Vérifier le chemin réseau Distinguer les problèmes DNS, de port et de réseau local
  4. 04
    Vérifier les ressources disponibles Contrôler l’espace disque, la mémoire et les tâches en arrière-plan
  5. 05
    Conserver des éléments de preuve anonymisés Recueillir l’heure, les commandes, les codes de sortie et des extraits de journaux
À noter Nœud · Heure · Commande · Code de sortie
Accès aux tâches

Accédez au parcours correspondant au travail à effectuer

Inutile de lire toute la documentation. Choisissez d’abord la tâche la plus proche, puis suivez l’ordre de vérification indiqué sur sa fiche. Pour l’état de la commande, la date d’expiration et les identifiants, fiez-vous aux informations affichées dans la console.

Première mise en service

De la confirmation de commande à la première validation

Vérifiez le modèle choisi, le centre de données et la durée de location, puis attendez la préparation automatique et l’émission des identifiants. Lors de votre première connexion, notez les informations du nœud et validez séparément la ligne de commande, l’interface graphique et l’environnement Xcode.

  • Confirmer l’état de la commande et la date d’expiration
  • Vérifier l’empreinte de l’hôte avant d’ouvrir la première session
  • Enregistrer le résultat de validation sans conserver les identifiants en clair
Ouvrir la console
Connexion à distance

Établir une session SSH ou VNC

SSH convient à la ligne de commande, à l’automatisation et aux tunnels ; VNC convient aux opérations nécessitant l’interface graphique de macOS. Vérifiez d’abord le nœud et les identifiants, puis le réseau local et le port.

  • Vérifier impérativement l’empreinte de l’hôte lors de la première connexion
  • En cas de déconnexion, distinguer d’abord le réseau local de la session du nœud
  • Ne pas conserver de données de connexion sensibles sur un appareil partagé
Voir les opérations de connexion
Outils de développement

Vérifier Xcode et l’environnement de build

Utilisez les commandes pour consigner la version de Xcode, le répertoire des développeurs actif et l’état de la chaîne d’outils. Avant de changer de version, conservez la sortie actuelle afin de ne pas confondre problème du projet et changement d’environnement.

  • Consigner xcodebuild -version Sortie
  • Confirmer le disque contenant le projet, les dépendances et le cache
  • Conserver d’abord le résumé complet de l’erreur avant tout nettoyage
Voir le dépannage des builds
CI/CD

Vérifier le runner self-hosted

Vérifiez d’abord que le runner est en ligne, que ses étiquettes correspondent et que le répertoire de travail est accessible, puis lancez une tâche de test minimale. Ne relancez pas tout le pipeline d’emblée : il serait plus difficile d’isoler l’étape en échec.

  • Vérifier les étiquettes du runner et les conditions de la tâche
  • Vérifier les droits du répertoire de travail et du cache
  • Conserver le code de sortie et les journaux anonymisés de la tâche en échec
Voir le dépannage CI/CD
Gestion du stockage

Gérer l’espace, le cache et les extensions

Commencez par distinguer les fichiers du projet, le cache des dépendances, les artefacts de build et les journaux. Si l’espace augmente continuellement, choisissez selon la croissance réelle entre +1TB SSD, +2TB SSD ou une nouvelle stratégie de nettoyage.

  • Vérifier l’espace disponible et les répertoires les plus volumineux
  • Distinguer le cache recréable des données métier
  • Sauvegarder les données importantes avant toute extension
Voir la gestion des ressources
Gestion de la location

Vérifier le renouvellement, l’expiration et la migration

La date d’expiration de la commande affichée dans la console fait foi. Après un renouvellement, vérifiez de nouveau l’état ; avant de terminer la location, migrez le code, les clés, les certificats, les journaux et les données métier.

  • Noter la date d’expiration actuelle et la durée souhaitée
  • Revérifier l’état de la commande après le renouvellement
  • Sauvegarder, révoquer les clés et nettoyer avant le départ
Voir la durée de location
Diagnostic rapide

Sélectionnez le contrôle actuellement en échec

Vérifiez de l’extérieur vers l’intérieur. Cliquez sur le premier élément en échec : le tableau indique le parcours prioritaire. Si l’étape précédente n’est pas confirmée, évitez de passer directement aux suivantes et de modifier la configuration système.

Préparer le diagnostic
  • Noter l’heure du problème et le centre de données du nœud
  • Conserver les commandes originales, les codes de sortie et les journaux anonymisés
  • Ne modifier qu’une variable à la fois et noter le résultat
Ordre des vérifications 01–05
Parcours de résolution Commencer par l’étape 01

Vérifiez d’abord dans la console l’état de la commande, le modèle cible et le centre de données. Une fois les informations concordantes, poursuivez avec les identifiants, les ports, le disque et les tâches système.

À noter : nœud / heure / symptôme / dernière modification
Problèmes de build

Figez d’abord la chaîne d’outils, puis examinez l’état du projet

Un échec de build résulte rarement d’une seule variable. Consignez d’abord les versions des outils et l’environnement d’exécution, puis examinez la signature, le cache, les journaux d’automatisation et les conditions du runner afin de ne pas écraser les preuves de l’erreur par un nettoyage.

01

Confirmer la version de Xcode

Exécutez la vérification de version et notez le répertoire des développeurs actif. Si la version demandée par le projet diffère de l’environnement actuel, vérifiez d’abord la compatibilité avant de basculer.

xcodebuild -version
xcode-select -p
swift --version
Validation : version, chemin et exigences du projet concordants
02

Vérifier l’environnement de signature

Vérifiez que la tâche de build peut lire les certificats, profils et variables d’environnement nécessaires. Dans les tickets et journaux, ne conservez que les noms, l’heure et le résumé de l’erreur ; ne transmettez aucune clé valide.

security find-identity -v -p codesigning
env | sort
Validation : l’élément de signature cible est visible et les droits sont corrects
03

Nettoyer DerivedData avec discernement

Conservez d’abord la sortie du premier échec, puis nettoyez uniquement les répertoires liés au projet cible. N’effectuez pas un nettoyage complet du disque en première étape : cela allongerait le build suivant et supprimerait les éléments de comparaison.

du -sh ~/Library/Developer/Xcode/DerivedData
df -h
Validation : après libération d’espace, l’erreur se reproduit de façon stable ou disparaît
04

Identifier l’étape Fastlane en échec

Décomposez les journaux en trois niveaux : lane, action et commande sous-jacente. Notez la première erreur réelle, le code de sortie et le répertoire d’exécution, plutôt que la seule synthèse finale.

bundle exec fastlane lane_name --verbose
echo $?
Validation : l’action en échec et la première erreur sont identifiées
05

Vérifier les étiquettes et les droits du runner

Vérifiez que le runner self-hosted est en ligne, que les étiquettes de la tâche correspondent exactement aux siennes et que l’utilisateur d’exécution dispose des droits appropriés sur les répertoires de travail, de cache et de build.

whoami
pwd
ls -ld .
df -h
Validation : une tâche de test minimale peut être attribuée et s’exécuter jusqu’au bout
Location et ressources

Gérez séparément l’expiration, la croissance du stockage et les besoins de connexion parallèle

Le renouvellement prolonge la durée d’utilisation, l’extension augmente la capacité et la connexion parallèle Thunderbolt 5 répond à certains workflows multi-machines. Ce sont trois options indépendantes : notez séparément l’état actuel et le résultat attendu avant d’agir.

Renouvellement et date d’expiration

Consultez la date d’expiration actuelle dans les commandes de la console, choisissez une durée de renouvellement et finalisez le paiement. Après le renouvellement, rouvrez la commande pour vérifier son état et la nouvelle date d’expiration ; ne remplacez pas les informations de la commande par un rappel de calendrier local.

Emplacement de l’opération
Commandes et locations dans la console
Avant l’opération
Noter la date d’expiration actuelle et la durée souhaitée
Après l’opération
Vérifier l’état de la commande et la nouvelle date d’expiration

Extension du stockage

Évaluez d’abord le besoin selon l’occupation des répertoires et la vitesse de croissance. Nettoyez en priorité le cache recréable ; sauvegardez le code, les éléments de signature, les artefacts de build et les données métier avant de décider d’augmenter la capacité.

+1TB SSD
Dépendances, cache et artefacts de build en croissance continue
+2TB SSD
Plusieurs projets, ressources volumineuses ou conservation prolongée
Emplacement de l’opération
Options supplémentaires disponibles dans la commande de la console

Connexion parallèle Thunderbolt 5

Pour les workflows nécessitant clairement la collaboration de plusieurs appareils. Avant la commande, notez le nombre d’appareils, la cible de connexion, le chemin des données et la méthode de validation ; chaque option parallèle est facturée séparément.

Éléments à confirmer
Chaque nœud physique participant à la connexion parallèle
Conditions de validation
Appareils cibles détectables, liaison stable et tâches exécutables
Emplacement de l’opération
Sélectionner l’option correspondante lors de la configuration de la commande
Prix des options de ressources selon quatre durées de location
Option supplémentaire Par jour Par semaine Par mois Par trimestre
+1TB SSD $2.9 $7.9 $14.6 $39.7
+2TB SSD $5.8 $15.8 $29.2 $79.4
Connexion parallèle Thunderbolt 5 (par appareil) $1.1 $2.9 $5.3 $14.4
Petit glossaire

Huit termes courants expliqués par leurs limites opérationnelles

L’intérêt des termes est d’aider l’équipe à aligner le périmètre des opérations. Les définitions ci-dessous se concentrent sur l’usage réel et distinguent les noms de produits, les protocoles de connexion et les rôles d’automatisation.

Mac dans le cloud
Ressource Mac utilisée à distance via un réseau. Le Mac dans le cloud d’ArmCLI correspond à un nœud physique Apple Silicon accessible à distance pour le développement, les builds, les tests et l’expérimentation.
Nœud physique
Appareil matériel effectivement fourni. Les informations du nœud comprennent le centre de données, le nom d’hôte, les données de connexion et l’état de la commande ; commencez par confirmer l’objet concerné lors du dépannage.
Dédié
Une commande correspond à une machine physique dédiée ; les locataires ne partagent pas la même instance du système d’exploitation. Vous devez toutefois gérer vos propres processus, droits, clés et données métier.
Sans machine virtuelle
Les tâches de calcul s’exécutent directement sur le nœud physique loué, et non dans une même instance de système d’exploitation virtualisée partagée avec d’autres locataires.
VNC
Méthode de connexion permettant d’afficher et de contrôler à distance l’interface graphique de macOS. Elle convient aux tâches nécessitant des fenêtres, des simulateurs ou des outils graphiques ; les informations de connexion sont disponibles dans la commande de la console.
SSH
Protocole utilisé pour la connexion en ligne de commande, le transfert de fichiers, la redirection de ports et l’automatisation. Vérifiez l’empreinte de l’hôte lors de la première connexion et privilégiez l’authentification par clé.
runner self-hosted
Exécuteur de pipeline enregistré et géré par l’équipe, fonctionnant sur un Mac dans le cloud. L’attribution d’une tâche dépend de l’état en ligne, des étiquettes, des droits et de la configuration du répertoire de travail.
Cache de build
Données intermédiaires conservées pour réduire les téléchargements et compilations répétitifs. Le cache accélère les tâches récurrentes, mais nécessite une capacité prévue, une stratégie d’invalidation et des contrôles réguliers.
Identifiants et sécurité

Une fois la connexion rétablie, finalisez aussi la sécurisation des identifiants

Rétablir l’accès ne signifie pas que le dépannage est terminé. Vérifiez les sessions inhabituelles, renouvelez les clés potentiellement exposées, supprimez les fichiers temporaires et confirmez la migration des données et la révocation des droits avant le départ.

Voir les informations sur la fiabilité et la sécurité
  1. 01 Renouveler les clés En cas de changement de personnel, de perte d’appareil, de transmission accidentelle d’identifiants ou de signe de connexion inhabituelle, révoquez les anciennes clés et émettez-en de nouvelles.
  2. 02 Réduire les droits La tâche de build ne doit disposer que des droits nécessaires sur les répertoires, commandes et variables d’environnement requis. N’utilisez pas d’identifiants durablement privilégiés pour remplacer la configuration.
  3. 03 Fermer les sessions inhabituelles Vérifiez l’utilisateur actuel, les terminaux actifs et les processus en arrière-plan, fermez les sessions inexpliquées et notez l’heure ainsi que les tâches concernées.
  4. 04 Anonymiser les journaux Conservez les commandes, l’heure, les codes de sortie et le contexte de l’erreur ; supprimez les jetons d’accès, clés privées, contenus de certificats, données métier et adresses internes.
  5. 05 Terminer le nettoyage avant le départ Migrez le code et les données métier, révoquez les clés à distance, supprimez le cache temporaire et les fichiers sensibles, puis vérifiez l’état de la location dans la console.
Parcours d’assistance

Soumettre un problème reproductible et vérifiable en trois étapes

Plus les informations sont complètes, moins il faudra répéter les vérifications. Effectuez d’abord les contrôles minimaux de la documentation, puis envoyez le nœud, l’heure, les commandes et les journaux anonymisés.

  1. 01

    Commencer par la documentation de la tâche

    Déterminez si le problème concerne la connexion, la chaîne d’outils, la CI/CD, le stockage ou la location. Notez les étapes effectuées et leur résultat, sans modifier plusieurs variables dans le même test.

  2. 02

    Préparer le package minimal du problème

    Incluez le nœud et le centre de données, l’heure, les commandes exécutées, le code de sortie, la première erreur, les dernières modifications et les étapes tentées. Les journaux doivent être anonymisés au préalable.

  3. 03

    Soumettre un ticket via la console

    Si vous avez une commande active, utilisez de préférence le ticket de la console afin de relier le problème au nœud et aux dossiers du service. Pour une question avant achat ou si vous ne pouvez pas accéder à la console, contactez l’équipe de service.

Décrire un problème urgent

Indiquez dans l’objet « connexion impossible », « build bloqué » ou « état de commande anormal ». Dans le corps, précisez le nœud, l’heure de début, la tâche affectée et les éléments de preuve anonymisés. N’envoyez jamais d’identifiants valides sur un canal public.

Prêt à commencer

Choisissez la taille de votre tâche et configurez directement un Mac physique dédié

Trois modèles sont proposés dans cinq centres de données : Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong et côte Est des États-Unis. La disponibilité réelle est indiquée en temps réel dans la console.

3 modèles 5 centres de données Location à la journée, à la semaine, au mois ou au trimestre