Connexion, builds et gestion courante

Premiers pas sur votre Mac

Récupérez vos informations de connexion dans le portail, puis vérifiez l’accès SSH ou le partage d’écran. Suivez les étapes dans l’ordre : transfert de fichiers, builds et sauvegarde des données avant expiration.

Vous avez déjà loué un Mac ? Le nom d’hôte, le port, le nom d’utilisateur et la date d’expiration de votre instance sont indiqués dans le portail une fois connecté. N’utilisez pas les exemples de ce guide comme de véritables identifiants.

Vérifier les infos de connexion

Trois moyens d’accès : choisissez selon votre besoin

Pour les tâches en ligne de commande, utilisez SSH. Pour l’interface graphique de macOS, optez pour le partage d’écran. Transférez vos projets et fichiers de build via SSH. Ne devinez pas les ports en multipliant les essais.

Connexion SSH

Ouvrez l’instance concernée dans le portail et vérifiez le nom d’hôte, le port SSH et le nom d’utilisateur. Dans votre terminal local, exécutez la commande ci-dessous en remplaçant les valeurs en majuscules par celles de l’instance.

ssh -p SSH_PORT USER@HOST

Le port SSH utilisé le plus souvent est le 22, mais votre instance peut être accessible sur un autre port. Vérifiez l’empreinte de l’hôte avant la première connexion. Si elle change, cherchez-en la raison au lieu d’ignorer l’avertissement.

En cas de délai d’attente, vérifiez le nom d’hôte, le réseau et le port. En cas de refus d’accès, vérifiez le nom d’utilisateur et le mode d’authentification. Ne divulguez pas vos mots de passe ni vos clés privées dans des journaux publics.

Pour les builds, les scripts et l’analyse des journaux

Partage d’écran macOS (VNC)

Récupérez l’adresse, le port et les informations d’authentification du partage d’écran dans le portail. Saisissez-les dans l’application de partage d’écran de votre Mac ou dans un client VNC compatible. N’utilisez pas le port SSH.

Le port VNC utilisé le plus souvent est le 5900, mais le port réellement accessible est celui indiqué dans les informations de l’instance. Ne faites pas apparaître les informations d’authentification du partage d’écran dans des captures ni dans des documents partagés avec toute l’équipe.

Privilégiez une connexion sécurisée. Pour créer un tunnel SSH, transférez le port local 5901 vers le service VNC de l’instance, puis connectez-vous à l’adresse locale.

ssh -N -L 5901:127.0.0.1:VNC_PORT -p SSH_PORT USER@HOST

Cette redirection ne fonctionne que si le service VNC écoute sur l’instance et que la redirection SSH est autorisée. Un écran noir et un échec d’authentification sont deux problèmes distincts : précisez lequel lorsque vous contactez le support.

Pour l’interface graphique et les vérifications de l’environnement

Transfert de fichiers (scp / rsync)

Commencez par vérifier que la connexion SSH fonctionne. Les transferts passent eux aussi par SSH : aucun service de transfert de fichiers supplémentaire n’est nécessaire. Utilisez scp pour les petits fichiers et rsync pour synchroniser régulièrement un répertoire de projet.

scp -P SSH_PORT ./build.zip USER@HOST:~/
rsync -av -e "ssh -p SSH_PORT" ./project/ USER@HOST:~/project/

Attention : l’option de port de scp est la majuscule -P, tandis que celle de SSH est la minuscule -p. Avec rsync, la barre oblique finale du chemin source indique que le contenu du répertoire doit être synchronisé.

Lors de la première synchronisation, n’ajoutez pas d’option de suppression automatique. Vérifiez d’abord le chemin de destination et le nombre de fichiers avant de transférer un grand volume de données. Une fois le téléchargement terminé, contrôlez l’intégrité de l’archive : la fin de la barre de progression ne suffit pas.

Pour le code, les ressources et les artefacts de build
Comprendre les résultats

Vérifiez séparément la connexion, le build et le téléversement

Cet exemple sert à distinguer trois étapes. Le nom d’hôte est fictif et ne permet pas de se connecter ; les sorties ne reflètent pas l’état d’une tâche en cours.

Nœud au Japon (Tokyo) · Exemple
$ ssh admin@jp-0417.node.vpskeep.com
Welcome to your dedicated Mac mini.

$ xcodebuild -scheme App archive
** ARCHIVE SUCCEEDED **

$ fastlane beta
Successfully uploaded package to App Store Connect.
  1. 01

    Message d’accueil SSH

    Ce message confirme l’ouverture d’une session distante, pas l’installation de l’environnement du projet. Exécutez ensuite sw_vers et xcodebuild -versionpour noter les versions du système et des outils.

  2. 02

    Archivage terminé

    ARCHIVE SUCCEEDED indique que l’étape d’archivage a réussi. Dans l’exemple, App est le nom du scheme. Pour votre projet, précisez aussi le workspace ou le projet, la plateforme cible et le chemin de sortie. Un archivage réussi ne signifie pas que l’export ou la distribution est terminé.

  3. 03

    Téléversement Fastlane terminé

    beta est un lane défini par le projet ; configurez d’abord la signature et l’authentification de distribution. Après le téléversement, vérifiez le traitement sur la plateforme : la fin de la commande locale ne signifie pas que la version est prête à être testée.

Pour diagnostiquer un échec, conservez la commande, le code de sortie et les journaux qui l’entourent. La seule mention « échec » sur la dernière ligne ne suffit généralement pas à identifier un problème d’environnement, de signature ou de réseau.

Stabiliser l’environnement

Choisissez d’abord la version de Xcode, puis configurez simulateurs et signature

Des versions différentes en local et à distance peuvent entraîner des écarts dans la résolution des dépendances ou les résultats de build. Commencez par noter les versions, puis procédez étape par étape. Évitez de mettre à jour simultanément la chaîne d’outils et les dépendances du projet.

  1. 01

    Vérifier et changer de version

    Exécutez les deux commandes de vérification ci-dessous. Si plusieurs versions de Xcode sont installées, vous pouvez changer le répertoire système par défaut. Pour ne modifier que la tâche en cours, définissez plutôt DEVELOPER_DIRdans l’environnement du processus.

    xcode-select -p
    xcodebuild -version
    sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
    DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer xcodebuild -version

    Le chemin doit correspondre à l’application réellement installée. Vérifiez dans l’environnement de l’instance si la version souhaitée est déjà disponible. Pour en installer une autre, utilisez un installateur sous licence et vérifiez d’abord l’espace disque disponible.

  2. 02

    Installer les environnements d’exécution des simulateurs

    Dans les réglages de Xcode, utilisez la section de gestion des plateformes ou des composants pour installer la version compatible avec le projet. Son nom varie selon la version. Affichez ensuite les appareils disponibles et sélectionnez une cible de test.

    xcrun simctl list runtimes
    xcrun simctl list devices available
    df -h

    Les simulateurs, DerivedData et les archives occupent de l’espace disque. Avant de lancer plusieurs tests, validez-en un sur un seul appareil, puis augmentez le parallélisme. Un test sur simulateur ne remplace pas un test sur un appareil iOS réel.

  3. 03

    Importer les éléments de signature

    Transférez le certificat de signature autorisé, sa clé privée et le profil associé vers l’instance par un canal sécurisé. Importez le certificat dans le trousseau utilisé par la tâche, installez le profil conformément aux exigences de votre version de Xcode, puis vérifiez l’équipe, le Bundle ID, la validité du certificat et le type de distribution visé.

    security find-identity -v -p codesigning

    Dans la CI, utilisez un trousseau dédié au build et stockez son mot de passe dans une variable secrète à accès restreint. Pour les tâches non interactives, vérifiez également le déverrouillage du trousseau et les autorisations d’accès aux outils de signature. La présence du certificat dans l’interface graphique ne suffit pas à confirmer que la configuration est opérationnelle.

    Avant de quitter l’instance, supprimez les clés privées de signature, jetons et profils dont vous n’avez plus besoin. Dans une demande au support, indiquez uniquement le nom du certificat et le texte de l’erreur ; n’envoyez ni clé privée, ni mot de passe, ni identifiants complets.

Fiabiliser l’exécution des tâches

Faites fonctionner un pipeline avant de laisser le runner actif en permanence

La configuration Keep M4 L (M4 / 24GB / 512GB) constitue un point de départ pour les builds sur plusieurs branches. Déterminez le parallélisme à partir de tests sur le projet ; le nombre de cœurs CPU ne permet pas à lui seul de savoir combien de tests d’interface peuvent s’exécuter en même temps.

Runner GitHub Actions autohébergé

Depuis la page des runners Actions des paramètres du dépôt ou de l’organisation, lancez l’inscription, choisissez macOS et l’architecture correspondante, puis téléchargez et inscrivez le runner avec les commandes affichées. N’utilisez le jeton d’inscription que le temps nécessaire et ne l’ajoutez pas au dépôt.

Attribuez des étiquettes explicites à l’instance, par exemple macos,arm64 et une étiquette correspondant à l’usage de l’équipe. Dans le workflow, sélectionnez la machine par ses étiquettes pour éviter d’envoyer une tâche de signature vers un environnement dépourvu de certificat.

runs-on: [self-hosted, macOS, ARM64]

Démarrez d’abord le runner manuellement et exécutez une tâche de test. Installez ensuite le service permanent à l’aide du script fourni avec le runner. Le compte d’exécution doit pouvoir accéder au répertoire du projet, à Xcode et au trousseau de build.

Journaux des tâches et diagnostics du runner

GitLab Runner et shell executor

Installez la version de GitLab Runner adaptée à l’architecture de l’instance. Récupérez les informations d’inscription dans l’interface d’administration du projet ou de l’équipe, puis exécutez gitlab-runner register. Pour utiliser la chaîne d’outils Xcode native, choisissez le shell executor conformément aux règles de sécurité de votre équipe.

Le shell executor exécute les tâches directement sur la machine. N’acceptez que des projets de confiance et limitez les branches et les tâches autorisées à accéder aux clés de signature. N’exécutez pas du code de contribution non vérifié sur une instance disposant d’identifiants de production.

gitlab-runner --version
gitlab-runner verify

Vérifiez d’abord que l’inscription et l’attribution des tâches fonctionnent, puis configurez le service selon son mode d’installation. Consignez le répertoire de build, le répertoire de cache et l’emplacement des journaux dans le document de passation de l’équipe.

Vérifiez l’inscription, puis l’exécution des tâches

Consignez le démarrage automatique et les journaux

Sur macOS, les processus permanents sont généralement gérés par launchd. Un LaunchAgent utilisateur et un LaunchDaemon système n’ont pas les mêmes conditions de démarrage. Si le service dépend d’une session graphique ou du trousseau de l’utilisateur, ne reprenez pas tel quel une configuration système.

Les fichiers de diagnostic du runner GitHub Actions se trouvent généralement dans le répertoire _diag de l’installation ; consultez les journaux des étapes dans la page du pipeline. Les sorties de service de GitLab Runner dépendent de son mode d’installation et de démarrage. Dans une configuration launchd personnalisée, définissez explicitement StandardOutPath et StandardErrorPathau lieu de supposer qu’il existe un fichier journal système unique.

Consignez le nom du runner, son compte d’exécution, la version de Xcode, le répertoire de travail et les chemins des journaux. Attribuez un DerivedData et un répertoire d’artefacts distincts à chaque tâche parallèle. Des fichiers de sortie portant le même nom peuvent s’écraser et faire passer un conflit pour un problème de machine.

Estimez la mémoire avant le chargement

Avec les 64GB du Keep M4 Pro, prévoyez de la marge au-delà des poids

Le Keep M4 Pro est configuré avec M4 Pro / 64GB / 2TB. La mémoire unifiée est partagée entre le système, le modèle et les autres processus : ne consacrez pas toute sa capacité aux poids du modèle. Les estimations ci-dessous portent uniquement sur les poids ; elles ne garantissent ni vitesse ni fonctionnement.

Volume brut des poids estimé à partir du nombre de paramètres et de la quantification
Nombre de paramètresPoids estimés en 4 bitsPoids estimés en 8 bitsÀ vérifier avant le chargement
Environ 7B paramètresEnviron 3,3 GiBEnviron 6,5 GiBPour valider l’installation, le format du modèle et une génération avec un contexte court.
Environ 14B paramètresEnviron 6,5 GiBEnviron 13,0 GiBMesurez le pic mémoire d’une requête avant d’envisager des tâches par lots.
Environ 32B paramètresEnviron 14,9 GiBEnviron 29,8 GiBUn contexte long et des requêtes simultanées peuvent augmenter sensiblement le cache KV.

Calcul : nombre de paramètres × nombre de bits ÷ 8 ÷ 2³⁰ ; résultat en GiB, arrondi à une décimale. Les groupes de quantification, facteurs d’échelle, couches non quantifiées, cache KV et tampons d’exécution augmentent l’utilisation réelle. La taille du fichier du modèle ne correspond pas au pic mémoire.

Lancez un premier test dans un environnement Python isolé

Vérifiez d’abord que la version de Python est compatible avec le paquet MLX utilisé, puis créez un environnement virtuel. Assurez-vous de pouvoir accéder à la source d’installation et aux fichiers du modèle, et d’en avoir l’autorisation d’utilisation. Vérifiez l’espace disque avant le téléchargement.

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install mlx mlx-lm
python -m mlx_lm.generate --model ./models/model --prompt "Explain unified memory." --max-tokens 128

./models/model doit désigner le répertoire d’un modèle compatible déjà préparé. Pour le premier test, utilisez une courte entrée et générez peu de texte, puis augmentez progressivement la longueur du contexte. Notez la version du modèle, la quantification, la longueur de l’entrée et le pic mémoire afin de pouvoir reproduire le résultat.

Si la mémoire reste sous pression ou que l’espace d’échange augmente rapidement, réduisez d’abord la longueur du contexte, la taille des lots et le nombre de requêtes simultanées. Ajouter un SSD augmente le stockage, pas la mémoire unifiée, et ne remplace pas une bonne estimation des besoins du modèle.

Gardez aussi un œil sur les échéances

Vérifiez le tarif avant de renouveler et la sauvegarde avant de résilier

Choisissez parmi quatre périodes de facturation : jour, semaine, mois ou trimestre. La date d’expiration fixe une échéance pour vos tâches : ne commencez pas la migration au moment du dernier build. Les nœuds fonctionnent normalement 365 jours par an ; la durée de location et l’état de livraison sont ceux indiqués dans la commande.

  1. 01

    Renouveler ou changer de période

    Connectez-vous au portail et consultez la date d’expiration dans l’instance ou l’abonnement concerné, puis lancez le renouvellement. Vérifiez le modèle, le nœud, la période choisie, les options et le montant total à payer. La date d’application d’un changement de période et tout éventuel complément dépendent des conditions et du tarif indiqués dans la commande. Après paiement, vérifiez que la nouvelle date d’expiration est bien affichée.

  2. 02

    Ajouter du stockage ou connecter des appareils en parallèle

    Pour disposer de plus d’espace pour vos ressources, consultez les options SSD de +1TB ou +2TB. Pour utiliser Thunderbolt 5 en parallèle, vérifiez d’abord la compatibilité de votre workflow et de vos appareils. Les options ne modifient pas la mémoire unifiée du modèle de Mac. Confirmez dans le portail leur disponibilité, leur période et les modalités de livraison avant de demander un changement de configuration. Si l’opération touche aux disques ou aux tâches, sauvegardez vos données et arrêtez les écritures concernées au préalable.

  3. 03

    Migrer les données avant l’expiration

    Exportez le code, les ressources, les artefacts de build et les configurations nécessaires, téléchargez-les vers un stockage que vous gérez et vérifiez qu’ils peuvent être restaurés. Arrêtez le runner et les tâches automatisées, révoquez les jetons d’accès temporaires et supprimez les clés privées de signature ainsi que les identifiants inutiles. Le simple fait d’avoir créé une archive sur la machine distante ne garantit pas que la sauvegarde est terminée.

  4. 04

    Après expiration

    Ne considérez pas la conservation des données après expiration comme une solution de sauvegarde. Consultez les conditions de traitement des données de la commande pour connaître la durée de conservation, l’avancement de la suppression et les possibilités de restauration. Si ces informations ne sont pas claires, demandez confirmation à l’avance via un ticket. Ne supposez pas que des données supprimées peuvent être récupérées : migrez les éléments importants avant l’expiration.

Donnez au technicien les éléments pour reproduire le problème

Regroupez ces quatre types d’informations dans un seul ticket

Connectez-vous au portail pour créer un ticket ; le problème sera associé à votre commande. Gardez un ticket par problème et ajoutez-y les résultats des tests suivants afin de conserver tout le contexte au même endroit.

  1. 01

    Instance et nœud

    Indiquez le numéro d’instance ou de commande, le modèle et le nœud concerné : Singapour, Japon (Tokyo), Corée du Sud (Séoul) ou Hong Kong. N’ajoutez ni mot de passe ni clé privée.

  2. 02

    Heure du problème

    Indiquez l’heure de début et le fuseau horaire, si le problème persiste et quand l’accès a fonctionné pour la dernière fois. Précisez s’il s’agit d’un délai d’attente SSH, d’un échec d’authentification, d’un écran VNC noir ou d’une erreur de commande de build.

  3. 03

    Étapes de reproduction et journaux

    Indiquez les étapes minimales pour reproduire le problème, les versions du système et des outils, le texte complet de l’erreur et les vérifications déjà effectuées. Masquez les identifiants dans les captures ; supprimez des journaux les jetons, mots de passe de certificats et autres données sensibles.

  4. 04

    En cas de paiement

    Indiquez le numéro de commande, le montant et le moyen de paiement. Les seuls moyens acceptés sont USDT-TRC20 et Visa / Mastercard / Amex (via Stripe). La facturation est en dollars américains ; les moyens effectivement disponibles dépendent de la réponse de la passerelle de paiement. Pour USDT, fournissez le hash de transaction ; pour une carte bancaire, le numéro de reçu. Ne transmettez pas le numéro complet de la carte.

Si vous ne pouvez pas vous connecter au portail, envoyez un e-mail à support@vpskeep.comen indiquant dans votre message l’adresse e-mail du compte et le numéro de commande. N’envoyez pas vos identifiants de connexion par e-mail.

Préparez l’environnement, puis confiez les tâches à la machine

Validez la connexion, un build et le téléchargement de ses artefacts avant d’activer l’automatisation. Vous n’avez pas encore choisi de machine ? Commencez par comparer les trois configurations et les quatre périodes de facturation.