Installer un runner
Le runner exécute vos pipelines sur vos propres machines. Il se connecte à la plateforme en sortant uniquement : aucun port entrant à ouvrir, aucune règle de pare-feu à ajouter.
On ne l'installe plus directement. C'est le gestionnaire de runners qui s'en charge : un petit programme posé une fois par machine, qui installe ensuite autant de runners que nécessaire, les met à jour et les diagnostique.
Un runner ne peut pas s'installer lui-même, et une machine en héberge souvent plusieurs — un par environnement, ou un par client. Le gestionnaire est ce qui tient ce parc local : il sait ce qui est posé où, quelle version tourne, et ce qu'il faut réparer. Il ne pilote pas leur travail : pipelines, déploiements et tâches planifiées restent du ressort de la plateforme.
Prérequis
- Une machine Windows x64, macOS (Apple Silicon) ou Linux x64 ;
- Un accès réseau sortant vers la plateforme (HTTPS et WebSocket) ;
- Environ 500 Mo d'espace disque par runner : l'exécutable, puis un environnement Python autoportant d'environ 170 Mo.
Aucun Python à installer vous-même. Le gestionnaire télécharge un environnement dédié et le pose dans le dossier que vous choisissez, distinct de tout Python déjà présent sur la machine.
1. Installer le gestionnaire
Depuis la page Runners, bouton Télécharger le gestionnaire. Le lien s'adapte à l'environnement sur lequel vous êtes connecté : vous obtenez toujours le binaire du bon canal.
| Système | Ce que vous récupérez |
|---|---|
| macOS (Apple Silicon) | une archive contenant Fluhoms Launcher.app |
| macOS (Intel) | la même archive, compilée pour Intel |
| Windows | un exécutable Fluhoms.exe |
| Linux | la ligne de commande fluhoms |
La page reconnaît votre système et met en avant la tuile correspondante. Les autres restent accessibles : on télécharge souvent pour une autre machine.
Un Mac Apple Silicon n'exécute pas un binaire Intel sans Rosetta, et un Mac Intel n'exécute jamais un binaire Apple Silicon. Si votre navigateur ne communique pas son architecture — c'est le cas de Safari — la page vous le dit et vous laisse choisir. Dans le doute : menu Pomme › À propos de ce Mac.
Sous macOS, glissez l'application dans Applications. Sous Linux, le
gestionnaire se limite à sa ligne de commande : placez fluhoms dans votre
PATH et rendez-le exécutable.
Une seule installation par machine suffit, quel que soit le nombre de runners.
2. Rattacher le gestionnaire à votre compte
Le gestionnaire doit savoir à quelle plateforme il s'adresse. Depuis la page Runners, bouton Connecter le gestionnaire : vous téléchargez un fichier de connexion chiffré qui porte l'adresse de votre environnement.
Ouvrez-le — double-clic, ou glissez-le sur la fenêtre du gestionnaire. En ligne de commande :
fluhoms connect mon-compte.accountfluhoms
Le fichier porte l'environnement. Sans lui, il faudrait afficher la liste de tous les environnements existants pour vous laisser choisir — ce qu'aucun client n'a à connaître.
3. Poser un runner
Un runner naît sur la plateforme, pas sur la machine. Le parcours complet est décrit dans Enregistrer un runner ; en résumé :
- vous déclarez le runner depuis la page Runners ;
- vous téléchargez son paramétrage chiffré (
.runnerfluhoms) ; - le gestionnaire l'applique : il prend en charge le runner, puis l'installe — exécutable, environnement Python, enregistrement.
Le dossier d'installation vous est demandé à ce moment-là. Vous suivez la progression sur la tuile du runner, et la plateforme reflète chaque étape.
En ligne de commande :
fluhoms runner enroll mon-runner.runnerfluhoms --path /opt/fluhoms
Démarrage automatique
Par défaut, un runner tourne en session : il s'arrête quand vous fermez votre session. Pour qu'il démarre seul et se relance après un incident, passez-le en mode machine :
fluhoms runner config mon-runner --set mode=machine
fluhoms runner start mon-runner
Le gestionnaire déclare alors le runner auprès du système : agent launchd
sous macOS, unité systemd utilisateur sous Linux, tâche planifiée sous
Windows.
Le runner démarre à l'ouverture de votre session et se relance après un arrêt inattendu. Il ne tourne pas avant qu'un utilisateur se connecte, et ne survit pas à la déconnexion de tous les utilisateurs : un véritable service système exige les droits administrateur, que le gestionnaire ne demande jamais.
Pour un serveur qui doit exécuter des pipelines sans session ouverte, déclarez
vous-même un service système pointant sur fluhoms_runner serve.
Chemins de données
Chaque runner possède son propre dossier de données, distinct du dossier d'installation :
| Plateforme | Chemin |
|---|---|
| macOS / Linux | ~/.fluhoms/runners/<nom>/ |
| Windows | %LOCALAPPDATA%\Fluhoms\runners\<nom>\ |
On y trouve :
- les données sensibles : clé privée et jeton de rafraîchissement ;
agent.json: nom et identifiant du runner ;runtime.json: le port réellement obtenu, publié au démarrage ;etl/lib/: le cache des composants téléchargés, comparé par empreinte pour ne retélécharger que ce qui a changé.
C'est ce dossier — et non un port figé — qu'un runner verrouille en démarrant. C'est ce qui permet à plusieurs runners de coexister sur une même machine.
Le runner devra être ré-enrôlé depuis la plateforme. fluhoms runner remove le
conserve par défaut ; seul --purge l'efface.
Et ensuite ?
- Enregistrer un runner : le parcours complet, de la déclaration à l'installation ;
- Gérer les runners : états, détail, redémarrage automatique, clusters ;
- CLI du gestionnaire : référence des commandes ;
- Configuration du runner : variables d'environnement.