Workers et pool

Les workers fournissent une capacité d'exécution partagée entre les projets de leur espace de travail d'inscription. Ils exécutent les jobs Playwright ou les explorations selon leurs capacités ; les hôtes personnels d'agents de programmation sont distincts.

Modele du pool de workers

Chaque worker se connecte a /ws/worker, declare son identite et peut executer un job assigne a la fois. Le backend suit les workers connectes en memoire et assigne les runs en attente aux workers libres.

Chaque worker est lié à un seul espace de travail par son propre identifiant d'accès. Il ne peut pas exécuter les jobs d'un autre espace. Son inscription persiste après déconnexion ; la passerelle conserve en mémoire l'état de connexion et l'affectation en cours.

Voir et gérer les workers

Cliquez sur l'engrenage du worker dans la barre supérieure ou sur Espace de travail → Workers dans la barre latérale pour ouvrir la page Workers. Sélectionnez un espace de travail si nécessaire. Aucun projet n'a besoin d'être sélectionné.

• La page affiche les workers nommés, connectés, occupés, en connexion, hors ligne ou révoqués. Elle s'actualise toutes les dix secondes lorsqu'elle est visible.
• Les membres de l'espace peuvent consulter l'inventaire. Les liens vers un job ou une exploration ne sont affichés que si le membre peut lire le projet correspondant.
• Dernière authentification indique l'authentification de l'identifiant d'accès, pas l'historique exact de connexion ou de disponibilité de la machine. Un état révoqué ou hors ligne ne prouve pas qu'un ancien processus s'est arrêté.
• Les propriétaires et administrateurs peuvent ouvrir Ajouter un worker pour la commande de configuration, et révoquer l'accès après confirmation. La révocation peut interrompre le travail ; elle ne désinstalle pas le worker et ne garantit pas l'arrêt immédiat du processus.
• Ajouter un worker ne génère ni n'affiche d'identifiant d'accès dans le navigateur. La CLI crée et conserve l'identifiant du worker localement ; l'approbation dans le navigateur le lie à l'espace sélectionné.

L'infobulle de disponibilité du projet conserve une vue de capacité filtrée par projet et anonymise les workers inactifs. Utilisez la page de l'espace pour les noms stables et l'historique d'inscription. Un échec d'actualisation est indiqué comme indisponible ou obsolète, jamais comme un inventaire vide.

Un inventaire vide est normal avant l'inscription. Créer un espace n'inscrit pas cet ordinateur. Les outils de démonstration locale peuvent provisionner leur propre worker ; consultez l'inventaire plutôt que de supposer le compte de démonstration vide ou cet ordinateur déjà inscrit.

Connecter un worker

Utilisez le bootstrap privé sur un hôte Ubuntu/Debian x86-64 avec UID 1000, Docker local rootful via un socket Unix, seccomp et AppArmor par défaut en mode enforcing, sans remappage des espaces de noms utilisateur. La CLI vérifie ces prérequis ; elle n'installe pas Docker et ne modifie pas la sécurité de l'hôte. Docker rootless, les UID arbitraires, ARM, Windows et macOS sont hors de ce parcours. L'acceptation sur un Ubuntu existant ne qualifie pas les OS neufs avec ou sans bureau ni la production cloud.

Obtenez l'archive complète du bootstrap privé approuvé auprès de votre opérateur. Authentifiez sa somme de contrôle et sa provenance par un canal de confiance avant extraction ou exécution ; aucune URL de téléchargement publique, commande curl | sh ou installation npm n'est prise en charge. Après extraction vérifiée, lancez avec votre utilisateur habituel sans sudo, en remplaçant le chemin d'exemple :

/absolute/verified/bootstrap-linux-x64/install.sh
export PATH="$HOME/.local/bin:$PATH"

Lancez ensuite la commande normale sur l'ordinateur qui exécutera les jobs de l'espace :

bernops setup

Choisissez 3 (worker d'automatisation), ou 4 (les deux) pour ajouter aussi un agent de code personnel. Le menu propose par défaut 1 (authentification plateforme uniquement), qui n'installe aucun worker. Le bootstrap inclut Node 22.19.0 ; l'installation normale n'exige ni NVM, ni checkout source, ni build manuel. L'opérateur doit configurer les versions signées approuvées.

1. Effectuez ou réutilisez la connexion plateforme dans l'assistant. Elle crée une session personnelle de CLI sans autoriser l'exécution ; aucune commande préalable bernops auth login n'est requise.
2. Pour un nouveau worker, l'assistant vérifie Docker, obtient et vérifie la version privée immuable signée avec SDK intégré, puis exécute de vrais contrôles SDK/navigateur avant de créer la nouvelle identité worker et de demander le consentement pour l'espace. Il ne compile pas depuis un checkout et ne vous demande ni d'installer le SDK ni de monter un tarball.
3. Approuvez séparément l'inscription dans le navigateur. Comparez le nom de l'ordinateur et son empreinte avec le terminal, vérifiez l'image et les capacités demandées, sélectionnez un espace dont vous êtes propriétaire ou administrateur, puis approuvez explicitement l'exécution de ses tâches sur cet ordinateur.
4. La CLI conserve un identifiant lié à l'espace, installe et démarre le conteneur, puis confirme une session récente prête, ou occupée si une tâche est déjà arrivée. La configuration unifiée exige à la fois la disponibilité SDK/image et une connexion confirmée. Une approbation, un test de vérification ou un conteneur actif ne suffisent pas seuls. Vérifiez le worker nommé sur la page Workers.

L'assistant réutilise son nom de worker enregistré, sinon un nom d'hôte normalisé. Pour le choisir explicitement, utilisez bernops setup --components worker --worker-name build-worker ; --worker-name appartient à la configuration unifiée, tandis que les commandes de gestion ci-dessous utilisent --name. Les noms contiennent lettres minuscules, chiffres et tirets, sur 48 caractères au maximum. L'espace se choisit dans le navigateur, pas via une option --workspace.

Sans --target explicite, l'assistant consulte l'identité utilisateur enregistrée, puis son journal, puis la cible compilée du bootstrap : local pour les bootstraps préparés localement et cloud pour les builds généraux. Lire ces docs localement ne sélectionne pas de cible. Les conflits échouent au lieu de migrer les identités. Utilisez --target cloud pour un environnement cloud configuré par l'opérateur, ou consultez le développement local.

Gérer le worker installé

Choisissez l'opération voulue en remplaçant NAME par le nom indiqué lors de la configuration :

bernops worker status --name NAME
bernops worker start --name NAME
bernops worker stop --name NAME
bernops worker restart --name NAME
bernops worker logs --name NAME

Ces commandes utilisent l'état local du worker, pas OAuth personnel. L'arrêt désactive le redémarrage Docker avant de laisser le travail se terminer ; il ne révoque pas l'accès. Les logs par défaut affichent un instantané borné du superviseur, pas la sortie brute des jobs. L'option avancée --unsafe-raw peut exposer des secrets des tâches ; ne partagez pas cette sortie. Pour les logs, étapes et traces des runs, consultez Workers et exécution.

Définissez APPROVED_IMAGE avec le digest privé fourni par l'opérateur, pas un tag modifiable. La mise à niveau attend que la connexion soit prête. La désinstallation conserve l'état local sauf si --purge est explicitement ajouté ; aucune des deux options ne révoque l'identifiant distant ni ne supprime l'identité d'inscription d'origine. Révoquez séparément l'accès devenu inutile depuis la page Workers de l'espace.

Configuration sans navigateur et options avancées

Pour approuver depuis un autre navigateur sans tenter d'en ouvrir un sur l'hôte du worker :

bernops setup --components worker --no-browser

Laissez la CLI interroger le backend et ouvrez chaque URL d'approbation affichée sur un autre appareil. Comparez le code humain, le compte connecté et l'empreinte du worker avant d'approuver la transaction concernée. --no-browser supprime l'ouverture, pas le consentement. --headless est réservé à l'agent et n'est pas accepté pour le worker seul. Gardez URL et codes privés ; ne copiez jamais fichiers d'identifiants, clés privées ou secrets d'appareil dans un chat ou des logs.

Les identifiants plateforme utilisent Linux Secret Service natif par défaut en local comme dans le cloud, même pour le worker seul en configuration unifiée. Il exige secret-tool, gdbus et un Secret Service déverrouillé dans la session D-Bus utilisateur. Pour une nouvelle identité seulement, ajoutez délibérément --credential-store file si vous acceptez un stockage de renouvellement réservé au propriétaire mais non chiffré. Aucun repli automatique en clair n'existe et l'option ne migre pas une identité native enregistrée. Réparez le stockage natif verrouillé ou indisponible. Les jetons d'accès restent en mémoire.

Alternative de bas niveau, distincte de la configuration unifiée : bernops worker setup reste disponible pour une installation source/image contrôlée par l'opérateur. Elle choisit le cloud par défaut (https://api.bernops.com, https://app.bernops.com), indépendamment d'une connexion personnelle enregistrée ou du bootstrap local. Elle n'effectue pas d'authentification plateforme de CLI et ne conserve pas de session OAuth personnelle ; elle utilise la connexion navigateur et l'approbation distincte de l'espace. bernops auth login n'est pas son prérequis.

bernops worker setup --target cloud --name build-worker --image "$APPROVED_IMAGE"

Cette commande de bas niveau peut préparer une image depuis les sources worker voisines de confiance de la CLI dans un checkout développeur approuvé, pas depuis le Dockerfile du dossier courant. Un bootstrap autonome sans ces sources exige --image ou BERNOPS_WORKER_SETUP_IMAGE : un digest de repository ou un ID d'image local sha256: existant approuvé par l'opérateur, jamais un tag modifiable. Ce parcours ne consulte pas le catalogue signé unifié ; la confiance dans l'image relève de l'opérateur. L'installation source/image ne remplace pas une version signée compatible SDK et ses capacités approuvées séparément. Les montages d'artéfacts SDK natifs ne sont pas une option de l'installateur. --no-browser et --target local explicite restent disponibles sur cette commande de bas niveau.

Pour la création, rotation ou révocation d'identifiants, ou l'installation manuelle, consultez agent-host/README.md, section Docker Worker Administration. L'administration distante des identifiants utilise une session OAuth personnelle de CLI ; ni l'inscription de bas niveau ni les commandes de gestion locale du worker n'en utilisent. Le remplacement local d'un identifiant après rotation distante n'est pas pris en charge par l'installateur.

Développement local uniquement

Depuis le checkout BernOps approuvé, préparez les versions locales signées et activez le bootstrap à cible locale sans redémarrer la pile :

./dev.sh install-cli
bernops setup

Choisissez 3 (worker d'automatisation) ou 4 (les deux), pas l'authentification seule par défaut. La préparation locale exige des prérequis de build développeur et peut utiliser un Node 22.19.0 déjà installé via NVM ; elle n'installe jamais NVM ni Node. Le backend local doit déjà fonctionner avec son catalogue signé configuré. Pour un choix local explicite plutôt que le menu :

bernops setup --target local --components worker

L'inscription locale utilise http://127.0.0.1:3410 et l'approbation navigateur http://app.bernops-dev. La configuration détecte automatiquement le backend Compose local correspondant et son réseau Docker. Sans ce service, le repli via la passerelle hôte doit être accessible depuis Docker ; un service limité à la boucle locale de l'hôte peut être inaccessible. Conservez la même cible et le même nom de worker pour reprendre.

Reprendre la configuration

• Après une interruption réseau, relancez bernops setup avec les mêmes choix, nom de worker, cible et stockage d'identifiants. L'assistant préserve les composants terminés sans remplacer silencieusement les identités ni déplacer un worker vers un autre espace. La sortie 0 signifie que les composants sélectionnés sont prêts, 2 indique une attention et 1 un échec.
• Après une déconnexion locale vérifiée, examinez Reconnect this PC? si l'assistant le propose. La reconnexion consentie inscrit un worker enfant distinct avec une nouvelle approbation d'espace, tout en préservant l'ancien conteneur et identifiant. Arrêtez/révoquez séparément l'ancien worker après vérification du remplaçant ; une erreur réseau seule ne prouve pas une révocation.
• worker_sdk_upgrade_required : le worker existant est préservé. Après configuration des versions signées par l'opérateur, utilisez un nom libre avec bernops setup --components worker --worker-name workstation-sdk et approuvez ses capacités SDK dans le navigateur. Une mise à niveau d'image ou rotation d'identifiant seule ne peut pas étendre les capacités déjà approuvées.
• component_release_trust_unconfigured ou component_releases_not_configured : obtenez le bootstrap approuvé ou demandez à l'opérateur de configurer le catalogue signé. Ne contournez jamais la vérification et ne substituez pas de paquet/image public.
• La commande de bas niveau bernops worker setup --reset-enrollment est réservée à une demande confirmée expirée, refusée ou annulée à archiver délibérément. Ce n'est ni une option de configuration unifiée ni une nouvelle tentative générale ; elle ne réinitialise pas une identité installée ou incertaine.
• Pour un échec de chemin ou de permissions, vérifiez XDG_STATE_HOME et ses parents. Réessayer sans changement de permissions ne résoudra rien. Ne faites pas de chmod sur le checkout ou les dossiers d'état partagés, n'utilisez pas sudo/chown et ne supprimez pas les fichiers d'identité pour contourner les contrôles.
• Un crash peut laisser un verrou de configuration ou d'installation. Confirmez la fin du processus initial puis relancez la même opération ; les verrous sécurisés ne récupèrent que des propriétaires obsolètes vérifiés. Demandez à l'opérateur d'examiner les verrous restants selon la procédure appropriée, sans suppression aveugle. Ne supprimez jamais l'état d'identité et ne forcez pas la suppression d'un conteneur inconnu.

Ce que le pool est

Le pool de workers est une cible de dispatch pour les runs BernOps en file d'attente.

Quand un run est cree, BernOps l'enregistre en pending. Le dispatcher le passe en running uniquement quand un worker libre existe et que le run respecte les limites de son scope.

Les limites peuvent etre configurees au niveau :

• Espace de travail
• Projet
• Job

Ce que le pool n'est pas

Le pool de workers n'est pas de l'autoscaling. Definir max_concurrent_executions a 5 ne cree pas cinq workers. Cela autorise seulement jusqu'a cinq runs correspondants a s'executer si assez de processus worker sont deja connectes.

Le pool de workers n'est pas une capacite reservee. Une limite projet a 3 signifie que le projet peut utiliser jusqu'a trois slots d'execution concurrents, pas que trois workers restent inactifs pour ce projet.

L'appartenance à l'espace de travail est obligatoire, mais l'affectation exclusive à un projet ou job n'est pas proposée : un worker nommé peut exécuter les tâches compatibles des projets de son espace.

L'opérateur provisionne toujours les processus worker. Le parcours CLI privé exige Linux/amd64, UID 1000 et Docker local rootful avec seccomp/AppArmor. L'acceptation sur un Ubuntu existant ne certifie pas les OS neufs ni les autres plateformes de déploiement.

Limites de concurrence

Les limites de concurrence sont des maximums. Elles sont evaluees ensemble.

Exemple :

Maximum espace de travail : 10
Maximum projet : 3
Maximum job : 1

Ce job ne peut executer qu'un run a la fois. Le projet peut executer au maximum trois runs au total. L'espace de travail peut executer au maximum dix runs au total sur tous ses projets.

Si une limite projet ou job n'est pas definie, ce scope n'ajoute pas de limite supplementaire. La limite de l'espace de travail continue de s'appliquer.

Comportement de la file

Les runs suivent ce cycle :

pending -> running -> passed | failed | error

Un run reste pending quand aucun worker n'est connecte, quand tous les workers sont occupes ou quand une limite de scope est deja atteinte.

Le dispatcher verifie les runs en attente regulierement. Il se reveille aussi quand des workers se connectent ou terminent des jobs. Les runs les plus anciens sont consideres en premier, mais si un run ancien est bloque par sa propre limite de scope, un autre run d'un scope ayant de la capacite disponible peut quand meme demarrer. Le dispatch exige aussi un worker avec la capacite requise, par exemple test_runner pour les runs Playwright ou agent pour le travail d'exploration discovery.

Selection du worker

Quand plusieurs workers sont libres, BernOps prefere ceux qui n'ont pas ete assignes recemment. Cela evite de dependre de l'ordre aleatoire d'une map et donne une distribution simple et equitable dans le pool partage.

Ce n'est pas du load balancing pondere, de la priorisation, du pinning de worker personnalise ou de l'ordonnancement base sur la duree historique.

Configuration

Definir la limite de l'espace de travail :

PUT /api/workspaces/{workspaceId}

{
  "max_concurrent_executions": 5
}

Definir la limite projet :

PUT /api/projects/{projectId}

{
  "max_concurrent_executions": 2
}

Definir la limite job :

PUT /api/jobs/{jobId}

{
  "max_concurrent_executions": 1
}

Conseils operationnels

Utilisez le nombre de processus worker pour controler le cout au niveau infrastructure. Utilisez les limites de concurrence BernOps pour controler comment cette capacite est consommee par les espaces de travail, projets et jobs.

Points de depart recommandes :

• Garder les limites d'espace de travail basses par defaut.
• Definir des limites projet pour les projets bruyants ou couteux.
• Definir les limites job a 1 quand des runs simultanes seraient dangereux.
• Augmenter le nombre reel de workers seulement quand le temps d'attente est trop eleve et que le cout est acceptable.

Limites actuelles

Le modèle actuel n'inclut pas l'autoscaling, les réservations de workers par projet ou job, les files prioritaires ni le verrouillage distribué entre backends. Utilisez une seule passerelle d'ordonnancement active. Les inscriptions persistent, mais la retransmission des résultats terminaux reste en mémoire et ne survit pas à la perte du processus worker.

Les capacités incluent agent, test_runner, secret_env_redaction_v1 et native_bridge_v1. La configuration unifiée d'un nouveau worker exige une version signée compatible SDK avec l'artéfact privé exact déjà intégré, de vrais contrôles SDK/navigateur, des capacités approuvées séparément et une connexion confirmée. Les workers existants gardent leurs images et identifiants ; l'assistant vérifie le SDK sans mise à niveau silencieuse. Une ancienne inscription seule n'ajoute pas le SDK. La distribution CLI/worker reste privée, sans paquet ni image de worker public supposé par ces instructions.