Connectez-vous, puis compilez

De votre première commande ssh
à votre première archive

Pour les développeurs qui viennent de recevoir un nœud : vérifiez d’abord la connexion et la chaîne d’outils, puis intégrez votre pipeline. Les commandes ci-dessous sont des exemples, pas l’état en temps réel de votre nœud.

Louer un Mac dans le cloud Voir mes nœuds dans la console

Si vous avez déjà un nœud, commencez à l’étape 1. Les identifiants, la date d’expiration et la disponibilité réelle sont ceux indiqués en temps réel dans la console.

01 / Connexion

Vérifiez que vous vous connectez à votre nœud physique

Ouvrez l’instance correspondante dans la console et vérifiez le nœud, l’adresse IP, le port SSH et le nom d’utilisateur. Ne récupérez pas vos identifiants dans un ancien ticket et n’enregistrez pas votre mot de passe dans le dépôt.

  1. 01

    Vérifier les informations de l’instance

    Dans la console, ouvrez les détails de l’instance et notez l’adresse IP, le port et les identifiants actuels. Dans la suite, NODE_IP,SSH_PORT et NODE_USER désignent ces valeurs. Attribuez-les dans votre terminal local avant l’exécution ; ne saisissez pas les noms des variables comme s’il s’agissait d’adresses.

  2. 02

    Vérifier l’empreinte de l’hôte

    Lors de la première connexion, SSH vous demande si vous faites confiance à l’hôte. Comparez l’empreinte affichée aux informations obtenues par un canal fiable avant de confirmer. Si vous ne pouvez pas la vérifier, ouvrez un ticket. Ne contournez pas l’avertissement en désactivant la vérification de l’hôte.

  3. 03

    Changer le mot de passe et configurer une clé publique

    Après la première connexion, exécutez passwd pour changer le mot de passe de l’utilisateur actuel. Vous pouvez transférer la clé publique vers le nœud, mais la clé privée doit rester sur votre machine. Gardez la connexion actuelle ouverte et vérifiez la connexion par clé publique depuis un second terminal avant de modifier la stratégie d’authentification.

Regrouper les informations de connexion sous un alias

Dans le fichier local ~/.ssh/config ajoutez la configuration ci-dessous et remplacez les trois champs en majuscules par les valeurs réelles indiquées dans les détails de l’instance.IdentityFile doit pointer vers un fichier de clé privée déjà présent sur votre machine. Si vous n’avez pas encore créé de clé, exécutez d’abord la commande de génération à droite.

Host armshell-dev
  HostName NODE_IP
  User NODE_USER
  Port SSH_PORT
  IdentityFile ~/.ssh/armshell_ed25519
  IdentitiesOnly yes
  ServerAliveInterval 30
  ServerAliveCountMax 3

Une fois le fichier enregistré, utilisez ssh armshell-dev pour vous connecter. Si l’empreinte de l’hôte a changé, vérifiez d’abord si l’instance a été réattribuée. Ne supprimez pas simplement l’entrée pour vous connecter de nouveau.

Transférez la clé publique, jamais la clé privée

Exécutez la commande ci-dessous sur votre machine pour ajouter la clé publique. L’alias doit être configuré et l’authentification par mot de passe doit fonctionner. Protégez votre clé par une phrase secrète et conservez-en une sauvegarde sécurisée sur votre machine.

ssh-keygen -t ed25519 -f ~/.ssh/armshell_ed25519
cat ~/.ssh/armshell_ed25519.pub | ssh armshell-dev \
'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'
ssh -o PreferredAuthentications=publickey armshell-dev

Après la connexion, exécutez whoami,sw_vers et df -hpour vérifier l’utilisateur, la version du système et l’espace disque disponible. Si les autorisations ne sont pas celles attendues, corrigez-les avant d’installer les outils de développement.

02 / Chaîne d’outils

Validez d’abord un build interactif, puis passez à la CI

Vérifiez que la version de Xcode souhaitée est installée et que sa configuration initiale est terminée. Les commandes et sorties ci-dessous illustrent le format ; les versions, SDK et noms de certificats dépendent de votre nœud et de votre projet, et ne constituent pas une liste de logiciels préinstallés.

dev@armshell-tokyo 
$ sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
$ xcode-select -p
/Applications/Xcode.app/Contents/Developer

$ sudo xcodebuild -runFirstLaunch
$ xcodebuild -showsdks
iOS SDKs:
    iOS 18.0                       -sdk iphoneos18.0
iOS Simulator SDKs:
    Simulator - iOS 18.0           -sdk iphonesimulator18.0

$ bundle exec fastlane match development --readonly
[09:12:01]: Successfully decrypted certificates repo
[09:12:03]: Installing certificate...
[09:12:05]: Installing provisioning profile...
[09:12:06]: All required keys, certificates and provisioning profiles are installed

$ xcodebuild -workspace App.xcworkspace -scheme App \
    -configuration Release -destination 'generic/platform=iOS' \
    -archivePath "$HOME/build/App.xcarchive" archive
** ARCHIVE SUCCEEDED **

Le choix de la version se fait au niveau du nœud

xcode-select modifie le répertoire de développement par défaut et peut affecter les autres tâches sur la même machine. Si plusieurs versions sont utilisées en parallèle, définissez plutôt DEVELOPER_DIRpour chaque tâche et affichez xcodebuild -versionau début des journaux afin d’éviter d’utiliser la mauvaise chaîne d’outils lors d’une reprise.

La signature doit pouvoir être déverrouillée pendant la session

Cet exemple suppose que le projet est configuré avec fastlane et un Gemfile, et que l’accès au dépôt de certificats est disponible. Commencez par synchroniser les certificats existants en mode lecture seule. Le compte de build doit pouvoir lire et déverrouiller son trousseau. En cas d’échec de signature, vérifiez d’abord les autorisations et les profils de provisionnement ; ne générez pas de nouveaux certificats à répétition.

Créer une archive ne signifie pas que la publication est terminée

Vérifiez d’abord le nom de l’espace de travail et du scheme, puis inspectez l’archive obtenue. Pour exporter le package d’installation, vous devez aussi disposer d’une configuration d’exportation adaptée au mode de distribution. Après un premier build réussi, notez la version de Xcode, le fichier de verrouillage des dépendances et la commande complète avant de migrer vers le pipeline.

03 / Interface graphique

Ouvrez une session de bureau uniquement si vous en avez besoin

La ligne de commande convient au transfert, au build et à l’inspection des journaux. Utilisez l’interface graphique de macOS pour configurer des outils, répondre aux demandes d’accès au trousseau ou déboguer l’interface. L’accès au bureau est disponible dans les détails de l’instance après connexion.

Activation et autorisations

Accédez au système par le bureau fourni avec l’instance, puis vérifiez « Partage d’écran » dans « Réglages Système → Général → Partage ». Autorisez uniquement les utilisateurs concernés, pas tous les utilisateurs. Si le partage d’écran et la gestion à distance sont incompatibles, vérifiez la configuration actuelle avant de modifier l’un ou l’autre.

Si vous ne pouvez pas accéder au bureau lors de la première tentative, demandez une vérification en ouvrant un ticket depuis la console. Ne modifiez pas en masse les services d’accès à distance du système si vous ne maîtrisez pas leur fonctionnement.

Ouvrir un ticket dans la console

Client et chemin de connexion

Sur macOS, vous pouvez utiliser le client « Partage d’écran » intégré. Sur d’autres systèmes, utilisez un client compatible avec le protocole VNC et prenant en charge une connexion sécurisée. Privilégiez le mode d’accès sécurisé fourni avec l’instance et n’exposez pas directement le service de bureau à un réseau non fiable.

Si vous avez confirmé que le service VNC du nœud écoute sur le port local 5900, utilisez le tunnel SSH ci-dessous pour connecter le client à l’adresse locale 127.0.0.1:5901.

ssh -N -L 5901:127.0.0.1:5900 armshell-dev

Réduisez d’abord la charge graphique

Pour la première connexion, commencez par une résolution de 1440 × 900 sur un seul écran et désactivez les animations superflues. Si la bande passante est limitée, réduisez la qualité d’image ou la fréquence d’images. Une meilleure résolution n’accélère pas le build et augmente le volume de données transférées.

Les besoins en bande passante varient selon l’encodage et les changements à l’écran ; aucune valeur fixe ne convient à toutes les tâches. Si la connexion ralentit, mettez d’abord en pause les transferts de fichiers volumineux, puis vérifiez si SSH subit également des retards.

Le bureau à distance et la ligne de commande utilisent la même machine physique dédiée.
04 / Intégration continue

Faites fonctionner le Runner dans l’environnement que vous venez de valider

Enregistrez le Runner avec un compte macOS dédié au build. Commencez par un seul job pour vérifier les dépendances, la signature et le transfert des artefacts, puis augmentez la concurrence en fonction de l’utilisation de la mémoire et du disque. N’exécutez pas de demandes de fusion non fiables sur un Runner qui détient des identifiants de publication.

GitLab : enregistrer un shell executor

Installez une version de GitLab Runner adaptée à Apple Silicon. Les commandes ci-dessous supposent que l’exécutable est dans le PATH de l’utilisateur actuel et que vous avez créé un Runner dans l’interface d’administration CI pour obtenir l’URL du serveur et le jeton d’authentification.

read -r CI_SERVER_URL
read -rs RUNNER_TOKEN
gitlab-runner register --non-interactive \
  --url "$CI_SERVER_URL" \
  --token "$RUNNER_TOKEN" \
  --executor shell
unset RUNNER_TOKEN
gitlab-runner verify
gitlab-runner install
gitlab-runner start
gitlab-runner status

Dans l’interface d’administration CI, définissez des tags explicites, par exemple macos-arm64 ainsi que la version de Xcode requise par le projet. Les tags du job doivent correspondre à ceux du Runner. Exécutez d’abord whoami,xcodebuild -versionpuis lancez le build de production.

GitHub Actions : enregistrer un Runner auto-hébergé

Récupérez le package d’installation pour macOS ARM64 et la commande d’enregistrement à usage unique dans les paramètres des Runners du dépôt ou de l’organisation. Téléchargez le package, vérifiez-le et décompressez-le avant d’exécuter les commandes ci-dessous depuis le répertoire obtenu. Récupérez les deux variables dans la page des paramètres.

read -r REPOSITORY_URL
read -rs RUNNER_TOKEN
./config.sh --url "$REPOSITORY_URL" \
  --token "$RUNNER_TOKEN" \
  --labels macos-arm64 --unattended
unset RUNNER_TOKEN
./svc.sh install
./svc.sh start
./svc.sh status

Dans le workflow, utilisez runs-on: [self-hosted, macOS, ARM64]et ajoutez aussi vos tags personnalisés, le cas échéant. Le jeton d’enregistrement et le service d’exécution sont deux choses distinctes. Après la configuration, vérifiez l’état du service et lancez un véritable job de test.

Service launchd : après l’installation, vérifiez les éléments effectivement chargés

Les commandes d’installation ci-dessus créent une configuration de service macOS selon l’implémentation de chaque Runner. Utilisez de préférence les commandes de gestion fournies et ne créez pas un second service manuel pour lancer le même Runner.

Un LaunchAgent utilisateur est généralement chargé à la connexion de cet utilisateur. Pour assurer un fonctionnement sans intervention après un redémarrage, vérifiez la prise en charge du service par le Runner concerné, l’état de la session et la stratégie du trousseau. Un service en ligne actuellement ne garantit pas qu’il le sera après un redémarrage.

ls "$HOME/Library/LaunchAgents"
launchctl print "gui/$(id -u)"
gitlab-runner status
./svc.sh status

Exécutez les commandes de vérification pertinentes dans le répertoire de chaque Runner. L’environnement CI non interactif peut ne pas disposer du même PATH que votre terminal. Indiquez les chemins de Homebrew, Ruby et Xcode dans des scripts de build versionnés et veillez à ne pas afficher de jetons dans les journaux.

05 / Données

Ne synchronisez que les changements et conservez vos sauvegardes hors du nœud

Privilégiez le clonage du dépôt pour récupérer le code source. Vous pouvez synchroniser par SSH avec rsync les grands répertoires, les artefacts de build et les fichiers qui n’ont pas leur place dans le dépôt. Un nœud loué est un environnement de travail, pas votre seule copie de données.

Prévisualisez avant le transfert

Vérifiez d’abord les deux versions de rsync --version. Les options courantes ci-dessous conservent la barre oblique finale pour synchroniser le contenu du répertoire ; adaptez les exclusions à votre projet. Lisez toute la sortie de prévisualisation avant de supprimer l’option -n.

rsync -avzn --exclude '.git/' --exclude 'build/' \
  ./project/ armshell-dev:~/work/project/

rsync -avz --exclude '.git/' --exclude 'build/' \
  ./project/ armshell-dev:~/work/project/

rsync -avz armshell-dev:~/build/ ./artifacts/

N’ajoutez pas l’option --deletesans en avoir confirmé la nécessité : elle supprime les fichiers présents en trop sur la destination. Gérez séparément les autorisations d’accès aux clés, certificats et journaux contenant des données sensibles ; ne les distribuez pas librement avec l’ensemble du répertoire de travail.

L’interconnexion de nœuds n’accélère pas Internet

Thunderbolt 5 permet d’interconnecter plusieurs nœuds pour traiter ensemble des fichiers volumineux. Il ne remplace pas la connexion Internet entre votre réseau local et le nœud et n’accélère pas automatiquement toutes les tâches rsync. Avant de commander, précisez les nœuds concernés, le volume de données et le workflow pour confirmer le mode de connexion adapté.

Si vous avez besoin de plus d’espace de travail, vous pouvez envisager l’ajout d’un SSD de +1TB ou +2TB. Un disque supplémentaire ne remplace pas une sauvegarde : conservez une copie du code, des artefacts et des certificats hors du nœud.

Après chaque publication, vérifiez que les fichiers transférés sont lisibles et notez la somme de contrôle des artefacts importants. Avant l’expiration, effectuez au moins un test de restauration indépendant au lieu de vous fier uniquement au succès affiché par la commande de synchronisation.

06 / Compte et durée

Ajoutez la vérification de l’expiration à votre checklist avant publication

Consultez les commandes, la date d’expiration de l’instance, les factures et les options de renouvellement dans la console. Les nœuds fonctionnent normalement 365 jours par an. Gérez toutefois votre période de location et le statut de votre commande à partir des informations de la console.

Vérifier la durée et les dates

Le service est facturé à la journée, à la semaine, au mois ou au trimestre. Vérifiez les dates de début et de fin ainsi que le fuseau horaire indiqués dans la console, et prévoyez une marge pour le build, le transfert et la sauvegarde. Ne laissez pas le renouvellement pour le milieu d’une tâche longue et ne supposez pas qu’un prélèvement automatique sera effectué.

Fiez-vous au détail de la commande et à la date d’expiration.

Confirmez les changements avant toute migration

Avant de changer de modèle, d’ajouter du stockage ou de modifier la durée, vérifiez les opérations disponibles pour la commande actuelle, le devis et les modalités d’application. Ne supposez pas que toutes les modifications seront effectuées immédiatement sur place. En cas de migration de l’environnement, sauvegardez d’abord la liste des dépendances, la configuration de signature et les données.

Pour toute règle de prorata ou de mise en application qui n’est pas précisée, demandez confirmation en ouvrant un ticket.

Vérifier le paiement et sa réception

Les seuls moyens de paiement acceptés sont USDT-TRC20 et Visa / Mastercard / Amex (via Stripe). La facturation se fait en dollars américains (USD) ; les moyens réellement disponibles dépendent de la réponse de l’interface backend. Pour un paiement sur blockchain, vérifiez le réseau, le montant et les coordonnées du destinataire. Pour un paiement par carte, suivez la procédure de vérification indiquée sur la page de facturation.

Si le statut n’est pas à jour, joignez le numéro de commande et les informations de transaction à votre ticket.
Gérer le renouvellement dans la console
En cas de problème, procédez par étapes

Déterminez d’abord s’il s’agit d’un problème de connexion ou d’exécution

Lorsque vous signalez un problème, indiquez le numéro de commande, le nœud, la date et l’heure avec le fuseau horaire, la commande exécutée et l’extrait complet de l’erreur. Vous pouvez joindre une capture d’écran ou une sortie de terminal expurgée des données sensibles, mais jamais un mot de passe, une clé privée, un jeton ou toutes les données de votre carte bancaire.

Le délai de connexion SSH est dépassé : par où commencer ?
  1. Dans les détails de l’instance, vérifiez l’adresse IP, le port, la commande et l’état de fonctionnement pour écarter l’utilisation d’une ancienne adresse.
  2. Sur votre machine, exécutez ssh -vvv armshell-devpour distinguer un délai d’attente dépassé, une connexion refusée et un échec d’authentification. Il s’agit de problèmes différents.
  3. Vérifiez votre réseau local et les règles de sortie, puis refaites un test sur un autre réseau fiable. L’échec d’une requête ICMP ne suffit pas à prouver que le service SSH est indisponible.
  4. Si le blocage survient pendant l’authentification, vérifiez le nom d’utilisateur, les autorisations de la clé privée et l’association de la clé publique. Si la connexion expire systématiquement, joignez des journaux expurgés des données sensibles à un ticket au lieu de réinitialiser sans cesse le mot de passe.
Téléchargement de Xcode ou récupération des dépendances trop lente : comment faire la différence ?
  1. Commencez par exécuter df -h pour vérifier l’espace disque disponible. Prévoyez suffisamment de place pour le package d’installation, sa décompression et la coexistence de plusieurs versions.
  2. Distinguez le transfert du package Xcode, la récupération des dépendances depuis le dépôt et le premier build. Une pause dans le journal de compilation ne signifie pas forcément que le téléchargement est en cours.
  3. Utilisez un package d’installation complet provenant d’une source fiable et vérifiez son intégrité. Évitez de transférer des fichiers volumineux en même temps que vos sauvegardes afin de ne pas saturer la bande passante.
  4. Notez le type de source, la taille du fichier, l’heure de début et l’erreur. N’envoyez pas d’adresse de téléchargement contenant un jeton d’accès. Si vous devez vérifier le réseau du nœud, transmettez ces informations dans un ticket.
Le bureau à distance se connecte, mais l’écran reste noir ?
  1. Vérifiez d’abord que SSH fonctionne afin de déterminer si le nœud entier est inaccessible ou si le problème concerne uniquement la session de bureau.
  2. Vérifiez que l’utilisateur connecté est autorisé à partager l’écran et qu’une session graphique est active, puis reconnectez-vous avec une résolution plus basse.
  3. Si vous utilisez un tunnel SSH, vérifiez que le terminal du tunnel est toujours actif et que le client se connecte au port local redirigé, pas à un autre port du nœud.
  4. Ne forcez pas le redémarrage d’un nœud en plein build. Enregistrez les journaux disponibles, précisez si l’écran de connexion est visible, puis ouvrez un ticket pour demander une vérification.
Runner déconnecté ou en ligne, mais sans job ?
  1. Vérifiez d’abord l’état du service et les journaux du processus, puis l’interface d’administration CI. Pouvoir se connecter au nœud par SSH ne signifie pas que le service Runner est actif.
  2. Si le Runner est en ligne mais ne prend aucun job, vérifiez les autorisations du projet, ses tags, les conditions de sélection du workflow et les paramètres des branches protégées.
  3. En cas de déconnexion après un redémarrage, vérifiez le domaine de chargement launchd et l’état de connexion de l’utilisateur de build. Un lancement manuel depuis un terminal ne remplace pas un service actif en permanence.
  4. Si un job échoue au démarrage, affichez l’utilisateur, le PATH, la version de Xcode et le répertoire de travail, puis vérifiez le trousseau et les autorisations des répertoires. Ne commencez pas par désenregistrer et recréer le Runner à répétition.

SSH fonctionne, mais le problème persiste ?

Envoyez-nous l’erreur avec tout le contexte utile

Pour les questions commerciales et avant-vente, contactez-nous par e-mail. Pour toute question technique ou de facturation concernant une commande existante, connectez-vous à la console et ouvrez un ticket afin que nous puissions retrouver l’instance et l’historique de traitement.

Ouvrir un ticket dans la console Voir les moyens de contact et les éléments à préparer