Commandes crew

Un crew regroupe plusieurs machines exécutant Collie sous un même lead, et votre téléphone accède à la herd de chaque machine via l'URL unique du lead. Le lead est la machine que votre téléphone joint, chaque autre machine est un membre, et le deputy est le seul membre autorisé à prendre le relais.

collie join et collie leave fonctionnent toujours. Ce sont des alias de collie crew join et collie crew leave, utilisant les mêmes arguments et codes de sortie.

collie pack fonctionne toujours aussi, pour chaque verbe de ce tableau. C'est un alias de collie crew avec les mêmes arguments et codes de sortie. collie docs pack affiche cette page, et l'adresse /pack de l'application web redirige vers /crew. Tous les trois disparaissent dans la version 2.0.0 (ADR 0038).

Les commandes deputy, approve-promote et promote gèrent le basculement. Pour les instructions de configuration et de récupération, consultez docs/deployment.md → la porte de secours et le jour de panne.

Deux machines, une crew

Deux commandes ajoutent une machine, une pour Herdr et une pour Collie, et une méthode manuelle existe pour un hôte auquel crew add ne peut pas se connecter en SSH et pour un leader qui sert en HTTP simple.

herdr machine add --label <name> <ssh-target>   # prepare the remote host
collie crew add <ssh-host>                      # install Collie there and enroll it

herdr machine add s'exécute sur la machine devant laquelle vous vous trouvez. Elle installe Herdr sur l'hôte distant et l'enregistre dans la propre liste de Herdr, sans ajouter la machine au crew. collie crew add s'exécute sur le lead. <ssh-target> et <ssh-host> désignent le même hôte, écrit sous la forme user@host ou d'un alias Host de votre ~/.ssh/config, et <name> sert uniquement de libellé dans la liste de Herdr.

collie crew add <ssh-host> installe Collie sur l'hôte distant via votre propre ssh et l'enrôle. La commande génère le jeton localement, provisionne Collie sur la machine distante et y exécute collie crew join. Elle nécessite Herdr préinstallé sur l'hôte distant, que herdr machine add y dépose, ces deux commandes s'utilisent donc ensemble. Un lead qui fonctionne en HTTP simple nécessite une étape manuelle supplémentaire, car crew add ne prend pas en charge --insecure : exécutez collie crew join --insecure sur la machine qui rejoint le crew. Utilisez soit crew add, soit la procédure manuelle pour un hôte donné, jamais les deux. collie crew add sans cible liste les hôtes déjà connus par votre configuration ssh et Herdr, fusionnés selon l'hôte résolu par chaque nom ; choisissez donc dans cette liste plutôt que de saisir l'hôte sous une autre forme (ci-dessous).

crew add emprunte la voie indiquée par son propre type d'installation. Un leader exécuté depuis un checkout git, comme le fait l'installation du plugin Herdr, pousse son propre commit vers le membre et l'y compile ; ce membre a donc besoin de git et de Bun. Un leader issu de la installation autonome ou d'un paquet n'a pas de commit ; il installe donc le membre à partir de la release qu'il exécute lui-même, via l'installateur de Collie envoyé par la même connexion SSH, et ce membre a plutôt besoin de curl, tar et sha256sum ou shasum. --path indique le checkout distant sur la première voie et la racine d'installation sur la seconde. Un membre qui exécute déjà l'autre type d'installation est refusé plutôt qu'écrasé, et le refus indique la commande unique qui permet de le résoudre. Sur cette seconde voie, le membre télécharge lui-même la release depuis github.com ; un membre sans accès à github.com a donc besoin d'un leader exécuté depuis un checkout.

Le terminal collie crew update emprunte les deux mêmes voies, et lit le même élément pour en choisir une : un leader sur checkout pousse son propre commit vers chaque membre, et un leader issu de l'installation autonome ou d'un paquet met chaque membre au niveau de la release qu'il exécute lui-même. Sur un leader de release, un membre exécuté depuis un checkout git est ignoré, la commande unique permettant de le mettre à niveau étant indiquée sur sa ligne, collie update --to-tag v<version> sur cette machine. Sur un leader de checkout, un membre installé par install.sh est ignoré selon la logique inverse : il reçoit des releases, donc la page Mises à jour du téléphone le met à niveau. Un membre ignoré n'interrompt jamais l'exécution, et la confirmation le comptabilise à part.

La méthode manuelle comporte quatre commandes. Utilisez-la pour un hôte que votre SSH ne peut pas joindre, ou pour un leader qui sert en HTTP simple, et non en raison du type d'installation du leader : chaque type de leader ajoute un membre avec crew add. Le leader est l'instance que votre téléphone joint déjà, et la machine qui le rejoint doit avoir Collie installé et en cours d'exécution.

1. 01
   Sur le lead, générez le jeton.

   collie crew invite        # prints the token, then the join command to run

   Le jeton tient sur une ligne : <token>.<lead-fingerprint>.

1. 01
   Sur la machine qui rejoint, intégrez le crew et collez le jeton lorsque vous y êtes invité.

   collie crew join https://lead.tail1234.ts.net

   Copiez l'adresse depuis la sortie de invite. Il s'agit de celle de votre lead, et non de cet exemple.

1. 01
   Sur le lead, redémarrez-le pour que le processus en cours prenne en compte le nouveau membre.

   collie restart

1. 01
   Sur le lead, vérifiez que le lien a répondu.

   collie crew status        # the new member, its address, and whether the link answered

Les tokens sont à usage unique, valables dix minutes et affichés une seule fois. Le lead ne stocke que le hash. Exécuter invite redémarre le processus du lead pour qu'il puisse accepter l'enrôlement entrant, et affiche la ligne de jonction incluant le nom du lead.

L'étape 3 est un second redémarrage, et join l'indique en se terminant. invite a redémarré le lead pour qu'il accepte l'enrôlement. join a ensuite écrit le nouveau membre sur le disque, et le processus en cours d'exécution ne relaie pas le trafic vers ce membre tant qu'il n'a pas redémarré.

Dans un terminal interactif, join demande le token. Dans un script, passez - et fournissez le token sur stdin :

collie crew join https://lead.tail1234.ts.net -   # paste the token on stdin

Passez plutôt @<file> pour lire le token depuis le disque. Passer des tokens bruts directement en arguments affiche un avertissement, car la liste des processus expose les arguments à tous les utilisateurs locaux (CREW_PROTOCOL.md §8.3).

Définissez l'adresse du lead sur n'importe quel nom d'hôte ou host:port accessible depuis ce nœud. Une adresse sans protocole ni port est résolue en https://<host>:8787, le port sur lequel écoute le propre listener de Collie.

Ce que crew invite affiche dépend de la manière dont le lead est publié. Dans le mode HTTPS par défaut, le lead écoute sur la boucle locale (loopback) et tailscale serve le publie sur le port 443. Ainsi, invite affiche https://<full-tailnet-name>, qui contacte le port 443. Si vous avez déplacé le point d'entrée avec COLLIE_SERVE_PORT, il affiche <name>:<port>. Avec COLLIE_SERVE_MODE=http, le propre listener du lead répond sur le port 8787 en HTTP brut, et invite affiche le nom court, avec le port seulement si vous l'avez modifié. join demande confirmation une fois avant d'envoyer le jeton en HTTP brut, et --insecure le confirme automatiquement. Une adresse http:// explicite nécessite toujours --insecure et ne demande aucune confirmation.

crew add transmet le même point d'entrée au membre, qui contacte donc lui aussi le port 443. Un nom seul impliquerait le port 8787, qu'un lead derrière tailscale serve n'expose pas au tailnet.

--address sur crew join est l'adresse que le lead contacte pour joindre cette machine, et elle requiert un port : --address <host>:8787. join refuse une adresse sans port, car le lead tenterait de contacter le port 443. Une adresse https://host:8787 reste acceptée et enregistrée sous la forme host:8787.

La sélection du multiplexeur est locale à chaque nœud. Configurez COLLIE_MUX dans le .env propre à ce nœud, dans ~/.config/collie/.env pour une installation binaire ou dans le dossier de configuration des plugins de Herdr pour une installation Herdr. Le protocole crew, qui constitue la liaison réseau entre les machines, ne contient aucun champ spécifique à un multiplexeur. Notez que les pairs n'ont été testés qu'avec Herdr en v1 (CREW_PROTOCOL.md §16).

crew add fixe cette valeur pour un nouveau membre, car le membre ne peut pas toujours la déterminer lui-même. Un membre qui n'exécute qu'un seul multiplexeur est laissé tel quel, et choisit celui-ci lors de son propre premier démarrage. Pour un membre qui en exécute plusieurs, le leader vous pose la question, et votre réponse est écrite en tant que COLLIE_MUX dans le .env de ce membre. Un membre qui en indique déjà un est également laissé tel quel. Passez --mux <name> pour répondre à l'avance, ou pour remplacer un nom que le membre porte déjà. Un membre sans multiplexeur en cours d'exécution reçoit un avertissement et rien n'est écrit, car son premier démarrage refuse de s'exécuter tant qu'aucun multiplexeur ne tourne.

Machines Herdr et le crew

Les machines enregistrées de Herdr et un crew Collie sont deux listes distinctes, et aucune n'alimente l'autre.

Pour ajouter une machine, consultez Deux machines, une crew ci-dessus.

La liste des machines de Herdr appartient à votre fenêtre Herdr. Herdr 0.9.0 conserve les cibles SSH enregistrées dans son client et ouvre chacune d'elles via SSH chaque fois que vous l'utilisez. Vous obtenez des terminaux sur ces machines, dans cette fenêtre, sur la machine devant laquelle vous êtes assis.

Une crew correspond à Collie présent sur chaque machine. Le lead joint chaque membre via le lien chiffré propre à Collie, configuré une fois lors d'une installation passant par votre SSH. Une crew affiche aussi les terminaux, et transporte bien plus que des terminaux. Elle transfère les téléversements. Elle conserve le journal et le log d'audit de chaque machine sur celle qui a exécuté le volet. Elle met à jour toute la crew à partir d'une seule confirmation sur le téléphone. Elle peut transférer la porte d'entrée à un deputy lorsque le lead ne répond plus. Elle fonctionne à l'identique sous tmux et zellij, qui n'ont aucune liste de machines.

Trois faits séparent ces deux listes, et chacun constitue une raison en soi.

Le téléphone ne conserve jamais de clé SSH. Une clé SSH donne un shell complet sur la machine, et un téléphone se perd. Le téléphone conserve à la place un jeton d'association émis par le lead, qui ouvre l'application et rien d'autre, et collie devices revoke <label> révoque ce code à chaud, sans redémarrage (associer un appareil).

Les téléversements, le journal et le log d'audit résident sur la machine qui exécute le volet. Et le lien de crew, comme Collie appelle la ligne chiffrée entre deux machines, n'a plus besoin de SSH une fois le membre enrôlé.

Vous ne configurez donc pas la même chose deux fois. Vous configurez SSH une seule fois, et les deux outils l'utilisent. Herdr conserve sa liste pour sa propre fenêtre, et Collie conserve le crew pour votre téléphone. Ajouter une machine à Herdr ne l'ajoute pas au crew. Supprimer une machine de Herdr ne la supprime pas du crew. Un membre du crew exécutant tmux ou zellij n'apparaît jamais dans la liste de Herdr.

collie crew add sans cible propose les candidats des deux listes, pour que vous n'ayez jamais à saisir un hôte deux fois. Elle lit les entrées Host de votre ~/.ssh/config et exécute herdr machine list --json. Elle fusionne les deux listes selon la cible ssh vers laquelle chaque nom résout. La commande suit un Include dans cette configuration sur un seul niveau, et uniquement pour les chemins sous ~/.ssh/. Elle ne propose pas d'alias issu d'un fichier inclus depuis un fichier inclus. Chaque ligne indique la provenance du nom : ssh config, herdr, ou les deux. La ligne d'une machine faisant déjà partie de cette crew affiche l'identifiant de ce membre à la place d'un numéro.

Comment une crew est reliée

Seul le lead expose une porte d'entrée, et toutes les autres machines de la crew n'en exposent aucune.

Le lead est la porte d'entrée gérée, et il sert la PWA. Le téléphone le joint en HTTPS sur /api/* et ne communique avec rien d'autre. Le lead joint chaque membre sur /crew/v1/*, via un TLS mutuel épinglé transportant le secret de la crew. Un membre est un Collie complet sans porte d'entrée, et il conserve ses propres agents, son journal, ses téléversements et son log d'audit. La gestion s'effectue entièrement via la CLI, sans actions dans l'UI de Herdr. Le protocole réseau lui-même est spécifié dans CREW_PROTOCOL.md.

Un pair est une instance Collie, avec un multiplexeur de terminal et les agents durables qui y sont rattachés (Agents durables dans une crew). Un hôte avec deux multiplexeurs de terminal exécute un pair pour chacun. Chaque pair de ce type a son propre port et son propre répertoire d'état, rejoint l'équipage de manière autonome et apparaît comme une machine distincte dans la liste.

Le code transite par votre propre SSH vers chaque machine. crew add installe un membre de cette façon et crew update le met à niveau. Le lien de crew transporte les données d'exécution, et ne devient jamais un canal de distribution.

Un deputy est un pair désigné à l'avance par le lead. Il réserve une porte de secours avec trois routes, et cette porte n'est jamais publiée. Le silence du lead l'arme, et votre propre identifiant d'association la consomme, permettant au téléphone de joindre le deputy pendant l'absence du lead.

Agents durables dans une crew

Les agents durables d'un membre s'affichent sur le téléphone du lead, dans l'unique section Agents durables, et le Collie propre au membre répond pour eux.

# on a member that runs a durable agent beside Herdr, tmux or zellij: no second instance
collie durable attach desk --socket /run/user/1000/desk/app.sock --restart
# on a durable-only member that shares its host with another peer
collie crew join <lead-address> --label desk-agents

Un Collie porte un multiplexeur de terminal et chaque agent durable qui y est rattaché ; ainsi, une instance Herdr et ses agents durables forment un seul pair, qui n'a pas besoin d'étiquette propre. Une instance dédiée aux agents durables (COLLIE_MUX=durable) forme son propre pair. Elle rejoint sous le nom d'hôte sauf si vous passez --label ; donnez-lui donc un nom lorsqu'un autre pair utilise déjà cet hôte.

Un lead antérieur à la version 1.21.0 liste toujours les agents durables d'un membre, mais sans la fiche de question, et son onglet Terminal interroge un panneau sans terminal. Le membre le signale une fois dans son journal, et collie doctor sur le membre affiche la ligne durable-lead. Mettez à jour le lead pour corriger ce problème.

Messages entre machines

Un agent peut envoyer un message à un agent sur une autre machine du crew, et le lead relaie chacun de ces messages.

# on the lead: every agent pane of every machine
collie walky who

Un membre envoie le message au lead. Le lead vérifie la signature du membre, puis transmet le message à la machine désignée par l'adresse, et cette machine vérifie celle du lead. Le lead transmet aussi le certificat de l'expéditeur, afin que cette machine vérifie également la signature de l'expéditeur. Le who propre à un membre liste uniquement ses propres volets. Le lead prend connaissance du résultat de chaque message et le renvoie au membre émetteur. Exécutez collie walky status <id> sur la machine de l'expéditeur ou sur le lead (À travers une crew).

Sur le téléphone, un volet sur un membre affiche ses messages comme le fait le volet propre d'un lead. Le lead lit la liste dans le journal de ce membre, de sorte que les fiches et le panneau Messages ont la même apparence sur chaque machine (Sur le téléphone).

Remarque. Un membre nécessite Collie 1.23.0 pour recevoir un message et pour afficher ses messages sur le téléphone. Un message destiné à un membre plus ancien est refusé not sent: older member, et un membre sous un lead plus ancien reçoit not sent: older lead. Exécutez collie crew update --all pour mettre à niveau le crew (Mettre à jour un crew).

Machines

Chaque Collie mesure sa propre machine, le lead en conserve un historique d'une journée pour chaque machine du crew, et les pages Machines l'affichent tout en contenant les règles d'alerte.

Ouvrez la liste depuis Paramètres, Machines. Elle est également présente sur un collie qui s'exécute seul, en tant que machine unique. Sur un lead avec un crew, Paramètres, Système propose une deuxième ligne pour la même page, et la fiche d'un membre sur la page Crew renvoie vers la propre page de cette machine avec Charge et alertes.

Seul un lead, ou un collie autonome, conserve la liste. Un membre du crew ouvert directement indique qu'il n'a pas de liste de machines ; ouvrez la page sur le lead.

Chaque Collie lit son CPU, sa mémoire, ses disques et son réseau sur le même cycle qui surveille déjà vos panneaux, donc rien de nouveau ne s'exécute en arrière-plan. Il les lit environ toutes les 15 à 25 secondes. Le lead lit les siens toutes les 5 secondes lorsqu'un téléphone a les pages Machines ou l'onglet Crew ouverts. Dans tous les cas, chaque minute reçoit au moins une mesure. Un membre envoie sa dernière mesure avec la réponse qu'il transmet déjà au lead. Le lead conserve un point par minute pour chaque machine, pendant 24 heures. Un Collie sans crew conserve la même journée pour sa propre machine.

Les disques sont ceux qui contiennent vos fichiers. Collie lit le système de fichiers qui contient votre dossier personnel, celui qui contient la racine (sous Windows, le lecteur système) et celui qui contient le dossier d'état de Collie. Deux d'entre eux situés sur un même périphérique ne comptent qu'une fois, et Collie en affiche au maximum quatre. Il ignore les systèmes de fichiers de moins de 1 Gio ainsi que ceux en lecture seule sans aucun espace libre. La racine d'un système basé sur une image, tel que Fedora Atomic, correspond à ce cas : elle est toujours pleine à 100 % et ne correspond pas à un disque qui s'est rempli. Chaque disque affiche les mêmes valeurs que df : "used" correspond au Used de df, et le pourcentage correspond au Use% de df. Le total représente ce que vous pouvez encore remplir en tant qu'utilisateur normal ; il peut donc être inférieur de quelques pour cent au Size de df, qui inclut aussi l'espace réservé pour root. Collie lit les disques une fois par minute, en arrière-plan. Un disque qui ne répond pas, comme un point de montage réseau bloqué, ne retarde jamais le reste, et Collie cesse de l'afficher après trois minutes et demie sans réponse. Aucun agent durable n'est démarré pour lui.

Le réseau compte chaque octet une seule fois. Sur Linux, Collie additionne les interfaces physiques, telles que eth0, enp3s0 et wlan0. Il ignore chaque interface dont les octets traversent également une interface physique :

• —
  Boucle locale : lo.
• —
  Ponts : br* (également le br-* de Docker), docker*, virbr*, lxcbr*, lxdbr*, incusbr*, podman*, cni*, flannel*, cali*, cilium*, weave*, vxlan*.
• —
  Extrémités de conteneurs et de VM : veth*, vnet*, tap*.
• —
  Tunnels : tailscale*, wg*, tun*, zt*. Le trafic d'un tunnel sort également par l'interface physique, donc la liaison crew y est comptabilisée.
• —
  Agrégations et VLAN : bond*, team*, et tout nom contenant un point, tel que eth0.100.

La journée de points se trouve dans machine-history.json dans le dossier d'état du lead. Le lead l'écrit au plus une fois toutes les cinq minutes, seulement lorsqu'une minute a changé, et une fois supplémentaire lorsqu'il s'arrête. Une journée pour une machine prend environ 46 Ko sur le disque (54 Ko lorsqu'elle rapporte des disques) et environ 68 Ko de la mémoire du lead. L'historique conserve le disque le plus plein de chaque minute, qui correspond au disque surveillé par une alerte. Un membre ne conserve aucun historique lui-même ; le lead est donc le seul endroit à consulter. Lorsque le lead est arrêté, personne n'enregistre, et le graphique présente une discontinuité.

Une machine qui ne répond plus conserve sa dernière mesure, avec l'heure à laquelle elle a été prise, et n'enregistre aucune nouvelle minute. Collie n'affiche jamais un zéro qu'il n'a pas mesuré. Un membre qui renvoie la même mesure, identique dans chaque chiffre, n'a pas mesuré à nouveau. Le lead ne l'enregistre pas, et la mesure conserve son ancienne heure. Le collecteur d'un membre qui se fige entraîne donc une discontinuité, pas une ligne plate.

La journée de points et les règles restent sur un seul lead.

• —
  Un deputy qui prend le relais démarre sans règles d'alerte et sans historique. Les deux fichiers se trouvent sur l'ancien lead. Définissez à nouveau les règles sur le nouveau lead.
• —
  Un collie isolé qui devient lead abandonne son propre historique. Isolé, il nomme sa machine local. En tant que lead, il utilise son id de membre, et les points et règles de local disparaissent.
• —
  Une machine retirée du crew emporte son historique et ses règles d'alerte avec elle.

Un membre plus ancien que cette fonctionnalité n'envoie aucune mesure, et il reste dans le crew comme avant.

Alertes pour une machine

Vous pouvez définir une règle pour le processeur, une pour la mémoire et une pour le disque sur chaque machine. Une règle comporte un seuil, de 50 % à 99 %, et une durée, de 5 à 120 minutes. La règle de disque surveille le disque le plus plein, et la notification nomme ce disque. Les règles se trouvent dans machine-alerts.json sur le lead.

Le lead envoie une notification lorsque chaque minute de cette durée atteint ou dépasse le seuil. Il nécessite une mesure pour au moins 80 % de ces minutes. Il n'envoie plus rien tant que la valeur reste élevée. L'alerte prend fin après cinq minutes consécutives au moins cinq points sous le seuil, et la hausse suivante envoie une nouvelle notification. Une alerte active est enregistrée avec les règles, de sorte qu'un redémarrage ne l'envoie pas deux fois.

Une alerte signale uniquement une charge élevée prolongée. Il ne signale pas une machine qui se déconnecte. Une machine qui ne répond pas ne déclenche ni ne termine une alerte. Une mise en veille suspend chaque alerte, et le commutateur La charge de la machine reste élevée dans Settings les désactive toutes (quelles alertes Collie envoie).

Rien ne quitte la crew. Les relevés transitent sur le lien de la crew et restent sur le lead.

Sur le téléphone

La page d'une machine a deux vues, Statut et Alertes. Le commutateur se trouve sous l'en-tête. Statut s'ouvre en premier, et une notification push concernant une machine ouvre également Statut. La ligne « Alerte en cours » sur Statut et sur une carte ouvre Alertes, où se trouve la règle. Lorsqu'une règle se déclenche, le commutateur Alertes affiche un point. La vue fait partie de l'adresse (?tab=alerts), et basculer n'ajoute pas d'étape : Retour quitte la machine et revient là d'où vous l'avez ouverte. Seul Statut lit l'historique ; Alertes ne lit rien.

Une carte décrit textuellement ce qui ne va pas. Une machine qui ne répond pas affiche son état de santé et l'ancienneté de son dernier relevé, et aucun chiffre, car un 12 % obsolète à côté du mot « inaccessible » donnerait l'impression d'une machine au calme. Une machine qui répond mais n'a envoyé aucun nouveau relevé depuis deux minutes affiche ses chiffres grisés, avec une horloge et l'ancienneté de son dernier relevé. Un membre exécutant encore une version de Collie antérieure à la remontée de la charge indique « Mettez à jour cette machine pour voir sa charge », et sa page n'affiche aucun graphique. Sa vue Alertes indique que la machine nécessite une mise à jour. Une métrique dont l'alerte se déclenche colore son chiffre et son petit graphique en rouge, et la carte affiche « Alerte en cours : CPU ». Le chiffre du disque n'a pas de petit graphique, car un disque se remplit en plusieurs jours, pas en demi-heures. Le petit graphique a une échelle fixe de 0 à 100 %, une ligne en pointillés là où une règle est définie, un point pour le relevé actuel, et un espace vide pour une minute manquante.

Les pages ne lisent des données que lorsque vous les consultez. La liste des Machines lit les données avec l'actualisation propre au tableau de bord. La page d'une machine lit la journée une fois à l'ouverture, puis uniquement les minutes les plus récentes, une fois par minute. L'onglet Crew lit à l'ouverture et toutes les 15 secondes tant qu'il est à l'écran. Rien n'est lu pour une page ou un onglet hors écran, ni lorsque le téléphone est verrouillé.

Les graphiques laissent vide une minute manquante. L'historique comporte un point par minute. Lorsque le lead a été redémarré, ou qu'une machine a cessé d'émettre, la ligne s'arrête et reprend après le trou, sans le traverser. Le CPU trace sa moyenne sous forme de ligne et son pic sous forme de bande plus claire. Le seuil d'alerte est une ligne en pointillés lorsqu'une règle est définie. L'axe réseau n'a pas de plafond fixe : il suit la valeur maximale et affiche son unité. Une machine sur une plateforme sans compteurs réseau, ou sans disque, l'indique au lieu de tracer un graphique vide.

Chaque graphique comporte une phrase pour lecteur d'écran. Elle indique la métrique, la plage, la valeur actuelle, la moyenne et le pic. La légende sous le graphique nomme chaque repère, afin qu'aucun graphique ne repose uniquement sur la couleur.

Définir une alerte sur le téléphone

Définissez une règle sur la vue Alertes de la page de cette machine. Les règles et leurs limites figurent sous Alertes pour une machine ci-dessus. La règle de disque ne s'affiche que pour une machine rapportant ses disques.

Une règle définie autrement, avec une ligne ou une durée en dehors de ces choix, conserve sa valeur et l'affiche à côté.

Une nouvelle règle commence à 90 % pendant 10 minutes. Chaque modification envoie l'ensemble des règles pour cette machine, donc modifier le seuil de CPU ne supprime jamais la règle de mémoire ou de disque. La carte affiche Enregistrement, Enregistré ou Impossible d'enregistrer dans sa propre ligne d'état, et après un échec, elle affiche les dernières règles signalées par le bridge.

Le push est envoyé à tous les appareils abonnés à ce Collie. La carte renvoie vers Paramètres, Alertes, où vous choisissez les alertes que vous recevez.

Démarrer un élément sur une machine

La page New (+ Nouveau sur le tableau de bord) comporte un menu déroulant Machine lorsque vous exécutez une crew. L'agent, la commande et le dossier que vous choisissez appartiennent tous à la machine sélectionnée, et cette machine exécute le démarrage.

• —
  Chaque machine indique les agents dont elle dispose. Il vérifie le PATH utilisé par votre shell de connexion ; un agent installé via nvm ou dans un dossier personnel est donc pris en compte. Un agent manquant sur une machine reste affiché dans le menu déroulant, désactivé, avec la mention « not installed ». Un même agent peut être prêt sur une machine et grisé sur la suivante.
• —
  Chaque machine lit ses propres lanceurs. Les entrées dans launchers.toml, ainsi que celles ajoutées par un téléphone, ne sont pas partagées avec le reste de l'équipe (Vos propres lanceurs). Sa liste de dossiers (les sections Récent et Favori) lui est propre également, et la page vérifie le dossier sur le disque de cette machine.
• —
  Un nouveau worktree est créé uniquement sur le lead. Sur un membre, le commutateur reste désactivé et indique « only on » suivi du nom du lead.
• —
  Un membre antérieur à la version 1.19.0 ne lance rien par son nom. La page liste ses options, désactivées, avec la mention « this machine runs an older Collie ». Mettez à jour le membre pour y lancer des agents (Mettre à jour, depuis le téléphone ou le terminal).

Membres non installés par install.sh

Une crew met à jour chaque membre depuis le téléphone, sauf ceux dont les fichiers appartiennent à un autre propriétaire.

collie crew update et la mise à jour de crew en un geste sur le téléphone préparent tous deux une nouvelle version à côté de l'ancienne avant de basculer. Cela fonctionne sur les deux types d'installation effectués par le script d'installation et Herdr, mais pas sur tous les types d'installation; la crew signale donc les autres au lieu d'échouer.

Un membre installé par paquet attend son gestionnaire de paquets. Lorsque pacman, nix ou brew placent les fichiers, ce gestionnaire en est le propriétaire, et Collie ne remplace aucun fichier qui ne lui appartient pas (une installation par paquet). La crew ne lui envoie jamais de mise à jour, l'affiche avec l'état « en attente du gestionnaire de paquets » accompagné de la commande pour son préfixe si elle est connue, et considère l'opération terminée sans lui. Il se met à niveau lorsque vous exécutez cette commande sur cette machine, et la ligne disparaît lors de la vérification suivante.

Un LEAD installé par paquet met toujours ses membres à niveau. Le leader refuse son propre déplacement pour la même raison, et c'est là tout le motif du refus : le téléphone et collie crew update mettent tous deux chaque membre au niveau de la version que le leader exécute actuellement, et une seule confirmation s'applique à tous. Après que le gestionnaire de paquets a déplacé le leader et que vous y avez exécuté collie restart, rien ne se met à niveau automatiquement ; une confirmation supplémentaire sur la page Mises à jour du téléphone aligne les membres sur la nouvelle version du leader.

Un checkout source est un membre à part entière, sous un leader qui en possède un également. Un membre que vous avez cloné et compilé vous-même reçoit la mise à jour d'équipe depuis un leader sur checkout : ce leader pousse son commit, le recompile et le redémarre exactement comme il le fait pour lui-même. Sous un leader sans commit, collie crew update l'ignore et indique d'exécuter collie update --to-tag v<version> sur cette machine.

Une crew mixte est donc une crew normale. Un seul geste met à niveau chaque membre que le lead peut mettre à jour, indique ceux qu'il ne peut pas mettre à jour, et la crew est de nouveau à niveau dès que vous avez exécuté leurs gestionnaires de paquets.

Le nom du crew

Le nom d'un crew est une donnée d'affichage, et seul le lead le montre. collie crew invite --name "the shed" nomme un crew lors de sa création, et un crew créé sans --name s'appelle « collie crew ». Pour le modifier ultérieurement, exécutez collie crew rename <name> sur le lead. Le verbe réécrit le nom dans le crew-trust.json du lead et redémarre le bridge, de sorte que collie crew status et la page crew du téléphone affichent immédiatement le nouveau nom.

Rien n'est envoyé à un membre. Le nom transite une seule fois, dans la réponse du lead à une inscription, et un membre le stocke sans jamais l'afficher. Une machine qui rejoint après le renommage reçoit le nouveau nom, et les membres déjà présents dans le crew conservent l'ancienne chaîne dans un champ que personne ne lit. Un nom est nettoyé (trimmed), comporte au maximum 64 caractères et ne contient aucun caractère de contrôle. Sur un pair, ou sur une machine n'appartenant à aucun crew, le verbe refuse de s'exécuter et indique où le lancer.

Mise à jour vers la 1.9.0 depuis la 1.7.0 ou la 1.8.x

Passez chaque membre en 1.8.x avant de faire passer le lead en 1.9.0. La version 1.9.0 prend en charge une seule version de la liaison crew, et la 1.8.0 est la plus ancienne version qui la gère.

Vous n'avez pas besoin de retenir de quelles versions il s'agit. À partir de 1.8.0, la notification de mise à jour vous indique quand la prochaine version modifie le lien du crew, sur le bandeau, sur la carte Mises à jour et dans la notification push quotidienne, et elle répète la même consigne : mettez d'abord à jour le lead, les membres suivent.

1.8.0 renomme les identifiants qu'une machine lit. Les chemins réseau, les deux clés d'environnement, les trois fichiers d'état et le préfixe du journal utilisent désormais tous crew (ADR 0039). Le lien fonctionne exactement comme avant, et aucun de vos scripts n'a besoin d'être modifié le jour même.

La version 1.8.0 a pris en charge un membre en 1.7.0 pendant une version, ce que la 1.9.0 ne fait pas. Un lead en 1.8.0 répondait aussi aux anciens chemins, de sorte qu'un membre encore en 1.7.0 continuait à le suivre. La version 1.9.0 a supprimé cela, comme l'ADR 0039 l'avait annoncé.

Un membre resté en 1.7.0 sous un lead en 1.9.0 apparaît deux fois, et aucune de ces apparitions n'est silencieuse. Le contrôle préliminaire du lead passe au rouge la vérification version, en indiquant les deux versions et la commande à exécuter ; ce rouge bloque la mise à jour du crew plutôt que de lancer un déploiement qui ne peut pas aboutir. Dans collie crew status, le même membre affiche incompatible, avec un motif qui se termine par "this build speaks 2".

Mettez à niveau ce membre depuis sa propre machine. Un lead en 1.9.0 ne peut plus le joindre via la liaison : exécutez donc collie update sur cette machine, mettez-la à niveau en 1.8.x ou plus récent, et le lead la prendra en compte lors de la prochaine interrogation.

Les nouveaux noms

Renommez les deux clés d'environnement dans votre propre .env avant de passer en 1.9.0. Une version 1.9.0 ne lit pas l'ancienne clé et n'émet aucun avertissement à ce sujet.

Sur un journal qui couvre la mise à jour, cherchez les deux préfixes avec grep :

journalctl --user -u collie | grep -E '\[(crew|pack)\]'

Une ligne écrite avant la mise à jour indique [pack], et une ligne écrite après indique [crew]. Une fois que toute l'équipe est en 1.8.0, filtrez uniquement sur [crew].