Arm Line M4
M4 / 16GB / 256GB
Adapté à un premier build Xcode, à une seule file CI et aux builds iOS ponctuels. Vérifiez l’installation des dépendances, la taille du cache et le workflow de build avec un vrai projet.
$21.2/jour
Louer un Arm Line M4
Bien démarrer
De la commande
De la commande
au premier
archive
Louez un nœud physique Apple Silicon dédié et vérifiez chaque étape : connexion, toolchain et build. Commencez par faire tourner un projet, puis intégrez-le à la CI de votre équipe.
2 configurations, 5 nœuds, dès $21.2/jour. Une machine physique dédiée, pas une VM. L’état de livraison et la disponibilité réelle sont indiqués en temps réel dans le portail.
Étape 1 / Choisir les ressources
Partez de votre charge de travail
Pour compiler et effectuer une première validation, commencez par l’Arm Line M4. Pour l’inférence de modèles ou des besoins importants en mémoire unifiée, choisissez l’Arm Grid M4 Pro. La taille du dossier du projet ne suffit pas à estimer la mémoire nécessaire : tenez aussi compte des tâches simultanées et de la consommation de la toolchain.
Arm Grid M4 Pro
M4 Pro / 64GB / 2TB
Adapté à l’inférence de modèles, aux caches de build volumineux et aux workflows gourmands en mémoire. Pour vérifier qu’un modèle donné peut fonctionner, tenez compte de sa quantification, de la taille du contexte et des paramètres d’exécution.
$59.8/jour
Louer un Arm Grid M4 ProLes 2 configurations sont disponibles dans 5 nœuds
Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong et côte est des États-Unis. Pour un bureau interactif, privilégiez un nœud bien relié à l’emplacement de votre équipe. Pour les builds automatisés, tenez aussi compte du téléchargement du code et des dépendances, ainsi que du transfert des artefacts. La distance géographique n’est qu’un premier indicateur, pas une mesure de latence.
Pour votre première location, commencez à la journée et exécutez un workflow complet sur le même projet avant de choisir une durée plus longue. Consultez la page des tarifs pour les quatre périodes de location et les options supplémentaires.
Étape 2 / Paiement et livraison
Après le paiement, vérifiez l’état de la commande
Seuls USDT-TRC20 et Visa / Mastercard / Amex (via Stripe) sont acceptés. Tous les paiements sont en dollars américains (USD). Les moyens de paiement effectivement disponibles sont ceux indiqués par l’API côté serveur.
-
01
Vérifier la commande
Vérifiez la configuration, la durée, le nœud et les options. Pour un paiement en USDT, sélectionnez impérativement le réseau TRC20 et vérifiez chaque information de paiement ainsi que le montant affichés sur la page. Ne réutilisez pas les informations d’une ancienne commande.
-
02
Attendre la confirmation
Les paiements on-chain doivent être confirmés et le délai varie selon l’état du réseau. Pour un paiement par carte, fiez-vous au résultat du paiement et à l’état de la commande. Ne payez pas une seconde fois si la page n’est pas encore actualisée et ne confondez pas paiement réussi et livraison du nœud.
-
03
Récupérer les informations de connexion
Consultez l’état de livraison dans le portail. Une fois le nœud disponible, vérifiez l’adresse IP, le nom d’utilisateur, le mot de passe initial et le port de connexion. En cas de divergence entre le justificatif de paiement et l’état de la commande, ouvrez un ticket en indiquant le numéro de commande et le hash de transaction ou le justificatif de paiement.
Étape 3 / Première connexion
Vérifiez SSH avant d’ouvrir le bureau
Exécutez les commandes suivantes dans un terminal local. Saisissez l’adresse, le port et le nom d’utilisateur indiqués dans le portail. Les exemples de cette page ne sont pas des identifiants de connexion.
Ouvrir une session SSH
read -r -p "Node IP: " NODE_IP
read -r -p "SSH port: " SSH_PORT
read -r -p "Login user: " NODE_USER
ssh -p "$SSH_PORT" "$NODE_USER@$NODE_IP"Lors de la première connexion, SSH affiche l’empreinte de l’hôte. Vérifiez-la par un canal fiable avant de l’accepter. Si une empreinte déjà enregistrée a changé, vérifiez d’abord si le nœud a été réinstallé ou remplacé : ne contournez pas cette vérification.
Changer le mot de passe de l’utilisateur distant
whoami
hostname
passwdExécutez passwd dans la session SSH du Mac cloud. Suivez les instructions pour saisir l’ancien puis le nouveau mot de passe ; rien ne s’affiche pendant la saisie. N’utilisez pas ce mot de passe sur d’autres services et ne l’inscrivez pas dans les logs de build.
Configurer un client VNC
| Champ | Valeur | Vérification |
|---|---|---|
| Adresse du serveur | Adresse IP du nœud indiquée dans le portail | Elle doit correspondre à la commande en cours, pas à l’adresse de votre ordinateur. |
| Port | Port VNC indiqué dans le portail | Si le client dispose d’un champ dédié, saisissez le port séparément. Ne le devinez pas. |
| Authentification | Identifiants de connexion graphique fournis dans le portail | Ne partez pas du principe que le mot de passe VNC est toujours le même que celui de SSH. |
| Réglage d’affichage initial | Commencez avec une résolution basse | Vérifiez l’image et les entrées, puis augmentez la qualité en fonction de votre bande passante. |
macOS permet aussi le partage d’écran intégré. Après avoir changé le mot de passe de connexion, vérifiez dans les instructions de livraison si les identifiants VNC doivent être mis à jour. N’exposez pas directement le service VNC à un réseau non fiable.
Étape 4 / Préparer l’environnement de build
Vérifiez la toolchain avant votre premier build
Exécutez les commandes suivantes sur le Mac cloud. Commencez par vérifier le système et les outils déjà installés, puis ajoutez uniquement les composants manquants. Ne remplacez pas les versions de Xcode, Ruby ou des dépendances déjà imposées par votre équipe simplement pour reproduire cet exemple.
1. Vérifier le système et Xcode
sw_vers
uname -m
df -h /
ls /Applications
xcode-select -p
xcodebuild -versionSi xcode-select pointe vers les outils en ligne de commande indépendants, cela ne signifie pas que la version complète de Xcode est disponible. Si elle n’est pas installée, préparez un installateur autorisé par votre équipe et placez-le dans /Applications après décompression. Prévoyez aussi assez d’espace disque pour la décompression, les dépendances et les artefacts d’archive.
2. Sélectionner Xcode et terminer l’initialisation
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
sudo xcodebuild -license
sudo xcodebuild -runFirstLaunch
xcodebuild -version
xcodebuild -showsdksDans cet exemple, l’application s’appelle Xcode.app. Si plusieurs versions sont installées, indiquez le chemin réel. Lisez les conditions avant de les accepter. Pour éviter de modifier la toolchain d’autres tâches, vous pouvez aussi définir DEVELOPER_DIR sur la version voulue pour un build ponctuel.
3. Vérifier Homebrew, Ruby et Fastlane
command -v brew
brew --version
ruby --version
bundle --versionSi Homebrew n’est pas installé, suivez la procédure approuvée par votre équipe. Ne collez pas de script d’installation distant provenant d’une source inconnue. Sur Apple Silicon, le chemin courant est /opt/homebrew : vérifiez la sortie réelle. Si Homebrew est installé mais introuvable dans la session actuelle, chargez son environnement :
eval "$(/opt/homebrew/bin/brew shellenv)"
brew install ruby
export PATH="$(brew --prefix ruby)/bin:$PATH"
gem install bundler
bundle install
bundle exec fastlane --versionExécutez les quatre dernières commandes depuis le répertoire du projet. Cet exemple suppose que le dépôt contient un Gemfile et un fichier de verrouillage définissant les dépendances Fastlane. S’ils sont absents, demandez à l’équipe de fixer les versions et de valider le fichier de verrouillage avant l’installation. N’installez pas les dépendances de build système en masse avec les droits administrateur.
4. Valider d’abord un archive sans signature
read -r -p "Workspace path: " WORKSPACE
read -r -p "Shared scheme: " SCHEME
xcodebuild -list -workspace "$WORKSPACE"
xcodebuild \
-workspace "$WORKSPACE" \
-scheme "$SCHEME" \
-destination 'generic/platform=iOS' \
-archivePath "$HOME/BuildArtifacts/FirstBuild.xcarchive" \
CODE_SIGNING_ALLOWED=NO \
archiveAccédez d’abord au répertoire du projet, installez les dépendances déclarées et vérifiez que le scheme est partagé. Pour un projet contenant uniquement un .xcodeproj, remplacez -workspace par -project. Cette commande vérifie la compilation et la création de l’archive, mais ne produit pas de build signé prêt à distribuer et ne garantit pas le succès des scripts de build qui exigent une signature.
Étape 5 / Intégrer l’automatisation
Enregistrez le runner après avoir validé les commandes
Choisissez GitHub Actions ou GitLab Runner selon votre plateforme de code. Commencez par valider une tâche sur une branche de confiance, puis vérifiez l’utilisateur du service, les variables d’environnement et l’accès au trousseau avant d’y faire passer vos pipelines de production.
GitHub Actions : enregistrer et installer le service utilisateur
Dans les paramètres du runner du dépôt ou de l’organisation, choisissez macOS et ARM64. Suivez les instructions actuelles de la plateforme pour télécharger le package, le vérifier et le décompresser dans un répertoire dédié. Exécutez les commandes ci-dessous depuis ce répertoire. Récupérez l’URL d’enregistrement et le jeton temporaire dans la page des paramètres en cours.
read -r -p "Repository or organization URL: " RUNNER_URL
read -r -s -p "Registration token: " RUNNER_TOKEN
printf '\n'
./config.sh \
--url "$RUNNER_URL" \
--token "$RUNNER_TOKEN" \
--labels armvnc,macos,arm64
unset RUNNER_TOKEN
./svc.sh install
./svc.sh start
./svc.sh statusDans le workflow, utilisez runs-on: [self-hosted, macOS, ARM64, armvnc] et vérifiez les labels réellement affichés par la plateforme. Le démarrage du service utilisateur dépend de la session de connexion. Après l’installation, vérifiez son comportement après une nouvelle connexion et un redémarrage : un enregistrement réussi ne garantit pas l’exécution des tâches dans toutes les situations.
GitLab Runner : enregistrer un exécuteur shell
Créez d’abord un runner dans les paramètres du projet ou du groupe et récupérez son jeton d’authentification. Une fois Homebrew configuré, installez le runner et enregistrez-le en suivant les invites. Le service s’exécute sous l’utilisateur actuel : les fichiers de build et les identifiants doivent également être gérés par cet utilisateur.
brew install gitlab-runner
read -r -p "CI server URL: " CI_SERVER_URL
read -r -s -p "Runner authentication token: " RUNNER_TOKEN
printf '\n'
gitlab-runner register \
--url "$CI_SERVER_URL" \
--token "$RUNNER_TOKEN" \
--executor shell \
--description "ArmVNC macOS ARM64"
unset RUNNER_TOKEN
gitlab-runner install
gitlab-runner start
gitlab-runner status
gitlab-runner verifyConfigurez les labels et les règles de branche protégée dans les paramètres de la plateforme. Les tags du pipeline doivent correspondre aux labels du runner. Un service utilisateur dépend généralement d’une session ouverte : consultez la documentation de votre version du runner pour vérifier LaunchAgent et le comportement au démarrage. Ne lancez pas une seconde instance avec un autre gestionnaire de services.
Les 4 vérifications de votre première tâche CI
- Affichez
whoami,xcode-select -petxcodebuild -versionpour confirmer que la tâche s’exécute dans le bon environnement. - Chargez explicitement le PATH de la toolchain. Un service en arrière-plan ne lit pas forcément la configuration du shell interactif.
- Lancez d’abord un build sans signature, puis configurez le trousseau et les étapes de signature de manière contrôlée. N’affichez aucun secret, mot de passe ou jeton dans les logs.
- Définissez une stratégie de transfert et de nettoyage des artefacts. N’exécutez pas directement du code non vérifié provenant d’une source publique sur un runner qui détient des éléments de signature.
Les nœuds fonctionnent toute l’année, 365 jours par an, mais la gestion du processus CI vous incombe. Après une déconnexion, une mise à jour système ou un redémarrage, vérifiez que le service runner, le réseau et l’environnement de signature sont de nouveau opérationnels. Avant de mettre fin à la location, supprimez l’enregistrement sur la plateforme, révoquez les identifiants et récupérez les artefacts.
Les termes, côté pratique
8 notions pour comprendre livraison et connexion
Pour savoir si une notion est importante, demandez-vous quelle étape elle modifie : l’attribution des ressources, le mode de connexion, l’exécution des tâches ou la collaboration entre plusieurs machines.
- Nœud physique
- Un véritable Mac dans un centre de données. Le portail fournit les informations de connexion à cette machine, pas un environnement de développement sur votre ordinateur.
- Machine dédiée
- Une commande réserve les ressources de calcul et de stockage de l’ensemble du Mac. À vous de gérer les tâches simultanées, les dépendances et le cache.
- Pas une VM
- Le service est fourni sur un appareil physique qui exécute macOS nativement. Vous pouvez utiliser l’interface graphique comme la ligne de commande.
- VNC
- Un protocole de connexion graphique à distance. Il permet d’afficher et de piloter le bureau du Mac depuis différents systèmes d’exploitation. L’expérience dépend du réseau et des réglages d’affichage.
- Partage d’écran
- La solution de connexion graphique à distance intégrée à macOS. Depuis un client Mac, connectez-vous au bureau du nœud avec les informations de livraison.
- Runner self-hosted
- Un runner CI que vous enregistrez et gérez vous-même. La plateforme de code lui attribue des tâches, exécutées par le processus runner sur le Mac cloud.
- Mémoire unifiée
- Ressource mémoire partagée par le CPU et le GPU d’une puce Apple Silicon. Les modèles, les builds et les processus système se la partagent.
- Connexion Thunderbolt 5
- Option permettant de relier plusieurs machines via Thunderbolt 5, facturée par machine. Elle ne fusionne pas automatiquement leur mémoire en un seul espace d’adressage : l’orchestration des tâches reste à votre charge.
Étape suivante / Suivre les résultats
Le build fonctionne ? Stabilisez le workflow
Consignez dans le dépôt la version de Xcode validée, le fichier de verrouillage des dépendances et les commandes de build. En cas de problème, identifiez d’abord s’il vient de la connexion, de la toolchain ou du projet, puis demandez de l’aide avec les informations minimales nécessaires à sa reproduction.
Validez le workflow avec un vrai projet
Commencez par une location à la journée et vérifiez la connexion, les dépendances et l’archive. Paiement uniquement par USDT-TRC20 ou Visa / Mastercard / Amex (via Stripe), en USD.