Temps réel et déploiements en auto-hébergé

TofuPilot auto-hébergé embarque deux services qui l'amènent à parité avec le cloud : un serveur temps réel et un déployeur. Le temps réel bascule les stations de test en ligne dès qu'elles se connectent et diffuse les runs en direct ; le déployeur construit votre bundle de procédure depuis Git et diffuse le journal de build pendant son exécution. Les deux arrivent avec le script de déploiement. Ce guide montre ce dont ils ont besoin et comment confirmer qu'ils fonctionnent.

Ce guide s'adresse aux instances auto-hébergées existantes qui ajoutent ces services. Les deux sont arrivés en 2.33 : si vous montez depuis une version antérieure, ils sont donc nouveaux pour vous. Relancer le script de déploiement les récupère, mais le serveur temps réel a aussi besoin d'un enregistrement DNS que les anciennes instances n'ont jamais eu (étape 1). TofuPilot cloud (tofupilot.app) a déjà les deux activés, et les nouvelles instances auto-hébergées les obtiennent désormais par défaut, comme décrit dans les références Configure et Deploy. Pour le flux général de mise à niveau, voir Upgrade. Une fois le temps réel et le déployeur en service, vous pouvez sortir vos bancs de l'application desktop v1.0 avec Migrer une station de la v1.0 vers le CLI TofuPilot.

Ce que vous obtenez

• Temps réel. Statut de station en direct, télémétrie et diffusion des runs vers l'interface opérateur et le tableau de bord, ainsi que les journaux de build en flux continu. Sans lui, l'application fonctionne toujours, mais les vues en direct retombent sur un rafraîchissement manuel.
• Déployeur. Le pipeline de déploiement par push Git : liez une procédure à un dépôt, poussez, et le bundle se construit et se déploie sur vos stations de test. Sans lui, le reste de la pile fonctionne, mais le pipeline de build est indisponible : les Stations v2.0 ne peuvent donc pas récupérer leurs bundles.

Étape 1 : ajouter le sous-domaine temps réel

Une instance auto-hébergée a besoin de trois sous-domaines. Le troisième porte le trafic temps réel. Créez un enregistrement A DNS pointant vers votre serveur :

Dans .env, l'hôte temps réel vaut par défaut realtime.<DOMAIN_NAME> : si votre application tourne sur tofupilot.yourcompany.com, vous pouvez donc le laisser non défini. Pour utiliser un autre hôte, définissez CENTRIFUGO_DOMAIN_NAME. Le script de déploiement génère les secrets du temps réel et du déployeur au premier lancement puis les réutilise, vous n'avez donc pas à les gérer à la main.

Étape 2 : exécuter Docker en root (pour le déployeur)

Le déployeur construit dans un bac à sable qui nécessite un conteneur privilégié, ce que seul Docker standard (root) autorise. Sous Docker rootless, le déployeur reste arrêté et le pipeline de build est indisponible, tandis que tout le reste, y compris le temps réel, fonctionne normalement. Si vous avez besoin du pipeline de build, installez Docker de manière standard, pas en rootless.

Étape 3 : déployer

Relancez le script de déploiement. La clé de licence est déjà dans .env, vous n'avez donc pas à la repasser :

Le script démarre les conteneurs temps réel et déployeur aux côtés du reste de la pile et demande automatiquement un certificat TLS pour le sous-domaine temps réel. Vérifiez que tout tourne :

Étape 4 : vérifier

Temps réel : ouvrez le tableau de bord et observez le statut d'une station de test, ou déclenchez un run et regardez les phases défiler. Le statut doit basculer et les runs se mettre à jour sans rafraîchissement de page.

Déployeur : liez une procédure à un dépôt Git, poussez sur la branche de déploiement automatique, et ouvrez le déploiement. Le journal de build doit défiler en direct pendant la construction du bundle, puis l'artefact est déployé sur vos stations de test.

Si le temps réel reste déconnecté, la cause est presque toujours le sous-domaine : vérifiez que l'enregistrement A realtime. résout vers votre serveur, que son certificat TLS a bien été délivré et que le port 443 est ouvert pour lui, tout comme pour l'application.