CLI du gestionnaire

Le binaire fluhoms installe, configure et diagnostique les runners d'une machine. Il est distinct du runner : il doit exister avant qu'un runner soit installé, et un runner ne s'installe pas lui-même.

Il ne pilote pas le travail des runners. Pipelines, déploiements, tâches planifiées et supervision des exécutions relèvent de la plateforme.

fluhoms <commande> [options]

Toutes les commandes de lecture acceptent --json, ce qui rend le gestionnaire utilisable depuis un script de provisionnement ou de supervision. health et doctor rendent un code d'erreur lorsqu'un runner n'est pas sain : elles s'emploient telles quelles comme sonde.

Se rattacher à un compte

fluhoms login <fichier.accountfluhoms>
fluhoms whoami
fluhoms logout

Le fichier de connexion se télécharge depuis le portail. Il porte l'adresse de la plateforme : c'est lui qui décide de l'environnement auquel le gestionnaire se rattache. Il ne contient aucune session, seulement un accès à usage unique valable quelques minutes.

Sans fichier, fluhoms login --api-url <adresse> affiche un code à approuver depuis le portail.

Se déconnecter n'arrête aucun runner : chacun est enregistré pour lui-même.

Voir le parc

fluhoms fleet              # tous les runners du compte, ici et ailleurs
fluhoms runner list        # seulement ceux de cette machine

fleet rapproche ce que la plateforme sait et ce qui est installé localement. Les deux vues ne se recouvrent pas :

Emplacement	Signification	Gérable ici
cette machine	Installé ici et connu de la plateforme	Oui
à installer	Déclaré, aucune machine ne s'en charge encore	Après prise en charge
ailleurs	En service sur une autre machine	Non
non rattaché	Installé ici, inconnu de la plateforme	Oui

Mettre un runner en service

Un runner passe par trois états : déclaré sur la plateforme, pris en charge par une machine, puis installé.

fluhoms runner reference <uuid|nom> [--name local] [--path /dossier]
fluhoms runner install <nom> [--path /dossier]
fluhoms runner start <nom>

La prise en charge est une réservation : elle ne télécharge rien et fait apparaître le runner comme pris en charge sur le portail. L'installation télécharge ensuite l'exécutable et un environnement Python dédié — comptez environ 400 Mo dans le dossier choisi. Un transfert interrompu reprend là où il s'était arrêté.

Depuis un fichier de paramétrage

fluhoms runner enroll <fichier.runnerfluhoms> [--path /dossier]
fluhoms runner enroll <fichier.runnerfluhoms> --dry-run

Le paramétrage émis par le portail porte le nom du runner, le serveur à joindre et son code d'enregistrement. enroll déroule les trois étapes d'un seul geste. --dry-run montre ce que le fichier contient sans rien installer.

Le suffixe annonce le canal : .runnerfluhoms en production, .dev.runnerfluhoms ou .beta.runnerfluhoms ailleurs.

Diagnostiquer

fluhoms runner health [nom]
fluhoms doctor
fluhoms runner logs <nom> -f
fluhoms update [nom]

health rapporte l'identité du runner, sa liaison avec la plateforme, sa version, l'état de son environnement Python et sa charge. doctor étend le diagnostic à toute la machine et signale ce qui mérite attention — une installation antérieure reprenable, deux runners qui se disputent le même dossier de données.

logs affiche le journal technique du démon : démarrage, liaison, erreurs d'installation. Les logs d'exécution des pipelines se consultent depuis la plateforme.

update compare la version installée à celle publiée sur le canal du runner.

Cycle de vie

fluhoms runner start | stop | restart <nom>
fluhoms runner register <nom> <code>
fluhoms runner config <nom> --set channel=beta
fluhoms runner remove <nom> [--purge --yes]

remove conserve par défaut le dossier de données, donc l'enregistrement du runner auprès de la plateforme. --purge le détruit, et exige --yes : cette suppression est irréversible et le runner devrait être ré-enregistré.

Mettre à jour les runners

fluhoms update                    # comparer les versions
fluhoms update --apply            # appliquer ce qui est périmé
fluhoms update mon-runner --apply # un seul runner
fluhoms update mon-runner --force # réinstaller même si les versions concordent

Sans --apply, la commande se borne à rapporter : remplacer des exécutables et redémarrer des runners n'est pas ce qu'on attend d'une commande qui compare des versions.

Ce qui se passe à l'application :

1. le runner est arrêté — sous Windows un exécutable en cours ne peut pas être écrasé, ailleurs l'écraser laisserait tourner l'ancienne image ;
2. le nouveau binaire est téléchargé, son empreinte vérifiée avant écriture ;
3. il remplace l'ancien ;
4. le runner redémarre s'il tournait. Un runner que vous aviez éteint reste éteint.

L'environnement Python n'est pas retéléchargé : cent soixante-dix mégaoctets qui ne bougent pas d'une version de runner à l'autre. Employez --force si c'est lui qu'il faut réparer.

Si la mise à jour échoue

Le runner est relancé tel qu'il était. Une mise à jour manquée ne doit pas laisser un parc éteint.

--force sert aussi à réparer une installation abîmée, cas où la comparaison de versions ne signale évidemment rien.

Redémarrage automatique

Un runner qui tourne des semaines accumule ce qu'aucun correctif ne rattrape à chaud : mémoire fragmentée, descripteurs retenus, version devenue ancienne. Le redémarrage périodique y répond, à condition d'être placé où il dérange le moins.

fluhoms runner schedule <nom>                                  # consulter
fluhoms runner schedule <nom> --enable --days dim --at 03:00
fluhoms runner schedule <nom> --days lun,jeu --wait force
fluhoms runner schedule <nom> --disable

Les jours s'écrivent lun…dim, ou tous, ou par indices 0-6. Zéro désigne lundi, non dimanche : préférez les abréviations, la convention numérique n'est pas celle qu'on attend spontanément.

Traitements en cours

Option	Effet
--wait wait	laisser finir les traitements en cours
--wait force	les interrompre
--max-wait <min>	plafond de l'attente ; 0 = sans limite
--on-timeout skip	passé le plafond, reporter à la prochaine occurrence
--on-timeout force	passé le plafond, interrompre

Attendre sans limite (--max-wait 0) sans jamais interrompre est licite, mais le redémarrage peut alors ne jamais survenir. Le runner n'est pas en panne pour autant.

Nouveaux traitements

fluhoms runner schedule <nom> --drain on --drain-lead 15

Le runner cesse d'accepter de nouveaux traitements quinze minutes avant l'heure. Sans ce délai, un traitement lancé à la dernière minute repousserait le redémarrage de toute sa durée.

Où vit le réglage

La plateforme en est la seule dépositaire. La ligne de commande, la fenêtre du gestionnaire et le portail y écrivent tous trois ; le runner le tire ensuite et le garde en cache — il continue donc de l'appliquer coupé du serveur, ce qui est justement le cas où l'on ne peut plus intervenir à la main.

En découlent deux conséquences visibles :

• régler exige un compte rattaché (fluhoms login), consulter non ;
• le réglage enregistré et le réglage appliqué peuvent différer le temps que le runner le reçoive. schedule les affiche séparément et signale l'écart plutôt que de le masquer.

Le calcul de l'échéance se fait dans le fuseau indiqué, pas en UTC : « 3 h » reste 3 h de part et d'autre d'un changement d'heure.

Reprendre une installation existante

fluhoms runner adopt --name default

Un runner installé avant le gestionnaire est repris sans ré-enregistrement : son dossier de données n'est pas touché, ses identifiants restent valables.

Variables d'environnement

Variable	Rôle
FLUHOMS_MANAGER_ROOT	Registre et journaux du gestionnaire
FLUHOMS_RUNNER_BIN	Exécutable du runner à utiliser
FLUHOMS_DOWNLOAD_URL	Dépôt d'où télécharger, pour éprouver la chaîne en local