Commencez par vérifier l’accès en ligne de commande avec SSH, puis ouvrez le bureau VNC. Pour limiter l’exposition sur Internet, faites passer VNC par un tunnel SSH. Vous louez un serveur physique dédié, et non une machine virtuelle. Les adresses, ports et comptes exacts figurent dans les informations de livraison de la console.
Pas encore de machine ? Choisissez un modèle et un nœud. Vous avez déjà commandé ? Connectez-vous à la console, consultez les informations de connexion de votre instance, puis suivez la première étape ci-dessous.
Relevez ces quatre informations dans la console avant de vous connecter. N’envoyez ni mot de passe ni clé privée dans un ticket.
SSH est une connexion chiffrée en ligne de commande. Sur macOS et Linux, utilisez le Terminal ; sous Windows, PowerShell. Remplacez l’adresse, le port et le nom d’utilisateur de l’exemple par les valeurs fournies dans la console.
ssh-ed25519 au compte distant, dans ~/.ssh/authorized_keys.ssh -p <port-SSH> <utilisateur>@<adresse-hote>
ssh-keygen -t ed25519 -C "cloud-mac"
cat ~/.ssh/id_ed25519.pub
ssh -i ~/.ssh/id_ed25519 \
-p <port-SSH> <utilisateur>@<adresse-hote>Si vous avez déjà des clés en local, vérifiez d’abord les noms de fichiers pour ne pas écraser une clé privée existante. Collez la clé publique sur une seule ligne complète et définissez les autorisations de ~/.ssh et de authorized_keys sur le serveur distant à 700 et 600.
VNC transmet l’écran du Mac à votre ordinateur pour vous permettre de le contrôler à distance. Vérifiez d’abord l’adresse du bureau, le port et le mode d’authentification indiqués dans les informations de livraison ; ils peuvent différer de ceux de SSH.
Ouvrez « Partage d’écran » et saisissez l’adresse VNC et le port fournis. Si vous avez établi le tunnel SSH ci-dessous, connectez-vous à l’adresse et au port locaux. Utilisez les informations de livraison pour l’authentification, et non votre clé privée SSH.
Idéal pour utiliser Xcode, Simulator et les réglages système.
Indiquez l’hôte, le port et les informations d’authentification fournis dans le client. S’il exige une adresse unique, utilisez le format « hôte:port » indiqué dans sa documentation. Privilégiez un tunnel SSH et définissez l’adresse de connexion sur l’adresse de bouclage locale.
Sélectionnez le protocole VNC dans le client ; n’utilisez pas le port SSH pour le bureau.
Réduisez la qualité au lieu de la laisser au maximum et baissez la fréquence d’images demandée par le client. Commencez par un seul écran et une résolution adaptée pour vérifier la stabilité de la connexion. Si le clavier répond mieux que l’image, vérifiez d’abord le chemin réseau entre vous et le nœud, plutôt que de réinstaller immédiatement l’environnement de développement.
Un tunnel SSH transfère de façon sécurisée un port local de votre ordinateur vers le port du bureau distant. Le client se connecte uniquement en local : inutile d’exposer davantage VNC sur Internet pour faciliter la connexion. Vérifiez que les informations de livraison autorisent ce mode de connexion avant de commencer.
5901 est un port local libre que vous choisissez ; cela ne signifie pas que le serveur utilise toujours ce port.-N signifie que le transfert est établi sans lancer de commande sur le serveur distant.127.0.0.1:5901. Quand vous avez terminé, quittez le client, puis fermez le terminal du tunnel.ssh -N \
-L 127.0.0.1:5901:127.0.0.1:<port-VNC-distant> \
-p <port-SSH> \
<utilisateur>@<adresse-hote>Si le port local 5901 est déjà utilisé, modifiez uniquement le premier port dans -L et utilisez ce nouveau port dans le client VNC. Ne modifiez pas le port distant pour résoudre un conflit de port local.
Un runner self-hosted est un exécuteur CI installé sur votre propre machine. Connectez-vous d’abord en SSH et vérifiez que les outils de ligne de commande Xcode sont disponibles, puis créez des identifiants d’inscription dans les paramètres de votre projet CI. Ne placez jamais de jeton à usage unique dans un dépôt ou des journaux de build.
Dans les paramètres des runners du projet, sélectionnez un runner macOS et suivez les commandes d’installation et de configuration à jour affichées sur la page pour l’inscrire sur votre Mac cloud. Utilisez des étiquettes qui identifient le modèle, le nœud et l’usage, par exemple macos, m4etios-build. Le champ runs-on du workflow doit correspondre aux étiquettes réellement attribuées.
Après l’inscription, lancez d’abord un petit job qui exécute uniquement xcodebuild -version , puis passez aux builds de production.
Consultez les instructions d’inscription du projet, installez sur le Mac cloud une version compatible de runner et choisissez le mode d’exécution shell adapté au projet. Attribuez-lui des étiquettes claires indiquant le nœud et le type de build. Vérifiez que les tâches protégées peuvent s’exécuter sur ce runner, puis lancez un pipeline de test.
Vérifiez d’abord que les tâches peuvent accéder à Xcode, aux certificats de signature et aux dépendances du projet, puis augmentez le niveau de parallélisme.
En suivant la procédure officielle du runner utilisé, enregistrez le processus comme service en arrière-plan macOS et précisez le compte sous lequel il s’exécute. Après le redémarrage, vérifiez l’état du service et lancez une tâche de test : le fait qu’un build fonctionne dans un terminal interactif ne garantit pas que le service en arrière-plan ait accès aux mêmes variables d’environnement ou au trousseau. Avant la fin de la location, révoquez le jeton d’inscription et sauvegardez les artefacts à conserver.
Quatre nœuds sont disponibles : Singapour, Japon (Tokyo), Corée du Sud (Séoul) et Hong Kong. Choisissez celui qui est le plus proche des principaux utilisateurs, puis testez la latence SSH et la réactivité du bureau depuis leur réseau de travail. Les liaisons internationales, les pertes de paquets et le réseau local influent également sur les résultats : le nom d’une ville ne suffit pas à estimer la latence.
| Nœud | Emplacement de l’équipe à privilégier | À vérifier lors de la connexion |
|---|---|---|
| Singapour | Équipes de développement et de build en Asie du Sud-Est | Latence réelle entre le réseau de travail et le nœud |
| Japon (Tokyo) | Équipes de développement au Japon et dans les régions voisines | Stabilité du bureau à distance et du transfert des artefacts de build |
| Corée du Sud (Séoul) | Équipes de développement en Corée du Sud et en Asie du Nord-Est | Pertes de paquets aux heures de pointe |
| Hong Kong | Équipes collaborant en Chine du Sud et en Asie du Sud-Est | Chemin d’accès utilisé par chaque membre de l’équipe |
Les deux configurations sont proposées dans les quatre nœuds. Leur disponibilité au moment de la commande est indiquée en temps réel dans la console. Si votre équipe est répartie sur plusieurs sites, choisissez d’abord le nœud des personnes qui utilisent le bureau au quotidien, puis tenez compte du chemin de transfert du code source et des artefacts pour les tâches CI.
La connexion Thunderbolt 5 entre plusieurs machines convient aux builds qui coordonnent plusieurs machines sur un même nœud ou aux workflows qui échangent souvent de gros fichiers. L’option est facturée par machine :$1/jour. Son intérêt dépend des besoins de transfert et de parallélisme ; elle n’est pas nécessaire pour utiliser VNC ni pour exécuter la CI sur une seule machine.
Vous pouvez, par exemple, répartir plusieurs cibles d’app, des lots de tests ou des builds de versions différentes sur des runners distincts. Attribuez une étiquette différente à chaque machine pour éviter d’envoyer une tâche à un nœud où les outils requis ne sont pas installés.
Mesurez d’abord la durée sur une seule machine, puis estimez le gain du parallélisme.
Si le build attend surtout la signature, le téléchargement de dépendances ou des services externes, la liaison entre machines n’est pas forcément le facteur limitant. Dressez la liste des fichiers à transférer, de leur taille, de la fréquence des transferts et du nombre de machines, puis vérifiez l’option lors de la configuration de la commande.
Une liaison locale entre machines ne suffit pas pour collaborer entre différents nœuds.
Vérifiez d’abord dans la console l’état de l’instance, son adresse et ses ports, puis déterminez si le problème vient de SSH, de VNC ou du réseau local. Ne réinitialisez pas l’environnement à répétition avant d’avoir sauvegardé les artefacts de build.
Vérifiez d’abord que la connexion SSH fonctionne toujours, puis fermez et rouvrez la session de bureau. Vérifiez les informations d’authentification VNC, l’état du tunnel et si le client se connecte au port local transféré ou au port direct indiqué dans les informations de livraison. Si SSH fonctionne mais que plusieurs clients affichent toujours un écran noir, ouvrez un ticket depuis la console en joignant le numéro de l’instance, l’heure du problème et une capture d’écran.
Désactivez d’abord le zoom fixe dans le client, puis vérifiez les réglages d’affichage macOS. Pour le bureau à distance, commencez avec un seul écran et une résolution courante. Reconnectez-vous après tout changement pour déterminer si le problème vient des réglages d’affichage du serveur ou du zoom du client.
Vérifiez que les dispositions de clavier locale et distante sont identiques, en particulier pour la ponctuation et les touches Option et Command. Consultez le mappage des touches de modification dans les réglages du client. Testez quelques caractères dans un éditeur de texte avant de saisir des commandes ou de modifier la configuration de signature.
Reconnectez-vous d’abord en SSH. Si vous utilisez un tunnel, relancez la commande de transfert, puis connectez-vous au port VNC local. Privilégiez un runner en arrière-plan pour les tâches de build, plutôt qu’un terminal de bureau qui doit rester connecté. Si SSH et VNC restent inaccessibles, ouvrez un ticket depuis la console en indiquant le numéro de commande, le numéro du nœud et en joignant une capture d’écran de l’erreur.
Commencez par une petite tâche SSH et vérifiez que le bureau et la CI répondent à vos besoins. Décidez ensuite si vous souhaitez prolonger la location ou ajouter des machines. Besoin d’aide avec une instance existante ? Connectez-vous à la console pour ouvrir un ticket.