Mises à jour des nœuds et comportement hors ligne

Les services appliqués continuent de s’exécuter sur un nœud pendant sa mise à jour ou lorsqu’il est hors ligne ; ce qui s’arrête, c’est la capacité d’Opfield à les modifier ou à les observer en temps réel. Conservez l’identité durable du nœud, rétablissez la session authentifiée et vérifiez que chaque ressource dépendante s’est réconciliée, et pas seulement que l’état est revenu au vert.

Une mise à jour ou une reprise est terminée lorsqu’on dispose d’une connexion, d’un inventaire, de métriques et de capacités récents, de chemins de charges de travail représentatifs qui fonctionnent, et d’aucune opération interrompue inexpliquée.

Détails pour l’opérateur : mise à jour et reconnexion

Vérifiez la compatibilité avant de mettre à jour Opfield, Relay et les démons. Appliquez les mises à jour signées des démons via le cycle de vie du nœud et vérifiez la reconnexion, la version, l’inventaire, les journaux, la santé et les liaisons gérées.

Lorsqu’un nœud passe hors ligne, ses charges de travail continuent de s’exécuter localement, et les modifications Opfield qui le concernent sont désactivées. Diagnostiquez la disponibilité de l’hôte, le service démon, l’heure système, l’identité du certificat, le DNS et l’accès sortant à Relay. Évitez de supprimer l’enregistrement du nœud tant que l’ancien démon peut se reconnecter.

Après la reprise, vérifiez la réconciliation de l’état souhaité pour les Routes, les charges de travail, les liaisons de bases de données, le matériel de certificats et la supervision. Une connexion au vert ne prouve pas à elle seule que chaque ressource dépendante s’est rétablie.

Lanceur de mise à jour résistant aux pannes

En 2.10, les démons Docker, nginx, de supervision et le superviseur Relay ont reçu un lanceur distinct. Lorsqu’elle est gérée par le lanceur, une mise à jour conserve le binaire précédent et un journal sur disque. Le candidat doit signaler sa disponibilité locale et passer une fenêtre de stabilité de 30 secondes avant d’être validé ; les candidats en échec peuvent être annulés. Le gestionnaire de services supervise le lanceur, qui supervise le processus du démon.

La disponibilité locale ne prouve ni la connectivité Relay ni la santé des applications. Continuez à vérifier la version, la reconnexion, les capacités du nœud et une opération réelle après la mise à jour. Si l’amorçage du lanceur n’est pas disponible et que le démon s’exécute directement, la protection par retour arrière du lanceur n’est pas disponible.

Un démon candidat qui déclare la disponibilité de sa connexion de contrôle doit aussi joindre Opfield dans les 3 minutes qui suivent sa disponibilité locale ; sinon, le lanceur rétablit le démon précédent. Opfield attend aussi longtemps (4,5 minutes) avant de déclarer la mise à jour en échec ; un retour arrière s’affiche alors comme « The daemon came back on … instead of … ».

Le lanceur se met aussi à jour lui-même. Une fois un démon mis à jour validé et connecté, le lanceur se remplace sur place par le lanceur de cette version en conservant son processus, le démon en cours d’exécution et les sockets d’écoute qu’il détient. Il ne le fait que sous systemd ou OpenRC ; en mode manuel, le nouveau lanceur démarre au prochain redémarrage manuel. Les détails du nœud affichent la version du lanceur.

Connexions pendant une mise à jour du démon

Sur un nœud Docker ou nginx dont le démon prend en charge le transfert à chaud (2.11.4 et ultérieur), une mise à jour conserve les sessions de flux Relay et les liens entre conteneurs vers une cible située sur le même nœud : le nouveau processus du démon les reprend après une pause d’une à deux secondes. Les flux bruts de pairs plus anciens, les liens PostgreSQL pour lesquels le démon ouvre TLS, les récupérations et envois vers le registre et les exécutions de sauvegarde sont toujours coupés. La première mise à jour vers un démon doté du transfert à chaud, et un retour arrière en dessous de cette version, coupent une fois les connexions ouvertes. Un nœud dont le lanceur a démarré avant 2.11.4 redémarre tout son service une fois lors de sa prochaine mise à jour du démon, ce qui coupe aussi une fois les connexions ouvertes ; les mises à jour suivantes les conservent.

La page du nœud indique ce que ferait une mise à jour à ce moment : The update keeps connections, N connections will be cut ou Open connections are cut once. Last Update, sous Runtime, indique ce que la dernière mise à jour a conservé et coupé.

Renouvellement des certificats

Opfield renouvelle ses certificats internes pendant son fonctionnement, sans redémarrage, et enregistre chaque renouvellement dans le journal d’audit :

Certificat	Validité	Renouvellement
Écouteurs d’Opfield et certificats de service et client du relais local	365 jours	Vérifié toutes les heures et renouvelé 30 jours avant l’expiration ; les connexions existantes conservent l’ancien certificat jusqu’à leur reconnexion. Tant que des jetons d’enrôlement inutilisés existent, le renouvellement attend les 7 derniers jours, car les commandes d’installation épinglent l’empreinte du certificat d’Opfield ; les commandes générées avant un renouvellement doivent alors être générées à nouveau
Un certificat fourni via GRPC_TLS_CERT	Défini par vous	Jamais renouvelé par Opfield ; un avertissement quotidien est consigné
Certificats serveur des relais distants	365 jours	Vérifié toutes les heures tant que le superviseur Relay est connecté et renouvelé 60 jours avant l’expiration, au plus une fois par jour
Certificats client des démons sur chaque nœud	365 jours	Vérifié toutes les heures par le démon et renouvelé lorsqu’il reste un tiers de la durée de vie, environ 120 jours avant l’expiration. Une tentative en échec est relancée après 5, 10, 20 et 40 minutes, puis toutes les heures. Le démon se reconnecte pour présenter le nouveau certificat
Certificat du proxy de registre sur les nœuds Docker	2 ans	Vérifié au démarrage du démon et toutes les 12 heures, et réémis par la même CA lorsqu’il reste un tiers de la durée de vie ou 30 jours ; servi sans redémarrage
Certificats TLS du stockage managé et des bases de données managées	Défini par Opfield	Vérifié toutes les heures et rechargé sur place sans redémarrage ; voir stockage managé et bases de données managées

Un nœud doit rester connecté pour renouveler son certificat. Comme le renouvellement commence des mois avant l’expiration, un certificat de nœud auquel il reste moins de 30 jours signifie que le renouvellement échoue : Opfield déclenche une alerte d’avertissement à 30 jours et une alerte critique à 7 jours. Assurez-vous que le nœud peut joindre Opfield et exécute un démon à jour ; une fois son certificat expiré, un nœud doit être enrôlé à nouveau.

Les CA système qui émettent ces certificats sont valables 10 ans et n’ont pas encore de renouvellement automatique (rollover). Les certificats qu’elles émettent prennent fin avec la CA, et Opfield alerte 730, 365, 180, 60, 30 et 7 jours avant l’expiration d’une CA système. Voir PKI interne.

Jetons d’enrôlement

Les jetons d’enrôlement sont à usage unique et expirent au bout de 7 jours. Pour un nœud encore en attente, New enrollment token émet une commande d’installation de remplacement. Un nœud enrôlé ne peut pas être réenrôlé sur place ; seuls les membres Relay prennent en charge le réenrôlement. Voir Relay et Relay Pool.

Mises à jour des démons

Mettez à jour un nœud depuis sa page de détail avec Update, ou plusieurs à la fois avec Nodes > Update Nodes. La boîte de dialogue liste chaque nœud dont le démon est plus ancien que la dernière version de son type et met à jour ensemble ceux qui sont sélectionnés. Les nœuds Relay ne sont pas listés : ils se mettent à jour avec le Relay Pool (Settings > General > Update Relay Pool), qui les vide un par un. Opfield refuse une mise à jour du démon pour un nœud non connecté, pour un nœud Relay et pour un nœud qui exécute déjà cette version ou une version plus récente.

• État de mise à jour. Un nœud conserve son état de mise à jour dans la liste et sur sa page, sans badge de mise à jour ni clignotement hors ligne pendant sa mise à jour. Une mise à jour en échec, annulée ou ayant dépassé son délai conserve sa raison sur le nœud, affichée sous Update Available, et un nœud qui revient sur son ancienne version est immédiatement signalé comme tel.
• Pairs de bail. Les nœuds qui partagent une politique Availability en mode bail redémarrent l’un après l’autre ; une mise à jour en file d’attente affiche Queued avec ce qu’elle attend. Voir Mises à jour et versions mixtes.
• Tâches en cours. Une mise à jour attend d’abord les tâches longues en cours sur le nœud : exécutions de sauvegarde et de restauration, builds d’images, migrations Docker, récupérations d’images et actions sur les conteneurs, tâches de copie de stockage, et exports et imports d’archives de conteneurs. Au bout de 30 minutes, elle démarre quand même et le nœud conserve un avertissement ; Update now la démarre immédiatement après une confirmation, car les tâches en cours peuvent échouer.
• Redémarrages d’Opfield. Après un redémarrage d’Opfield pendant des mises à jour de nœuds, les mises à jour en cours attendent la reconnexion de leurs nœuds et se terminent ou échouent dans les délais, et les mises à jour en file d’attente sont reprises. Opfield recherche les mises à jour des démons à son démarrage et après une mise à jour d’Opfield.
• Connexions interrompues. Un démon qui a préparé une mise à jour automatique redémarre dessus même si sa connexion à Opfield a été interrompue pendant le téléchargement.
• Installateurs. Les commandes de configuration des nœuds et des relais proviennent de la version propre à l’installation Opfield en cours d’exécution et sont vérifiées par rapport aux sommes de contrôle de cette version, et les installateurs de démons épinglent le démon le plus récent de la ligne de versions de cette installation ; une installation Opfield ne distribue donc jamais d’installateurs issus d’une ligne de développement plus récente.

Avant une mise à jour

1. Lisez les notes de version du composant et le plancher de compatibilité.
2. Vérifiez que le canal de mise à jour de l’installation est délibéré : Stable pour les versions de production, ou Preview pour des préversions explicitement acceptées.
3. Vérifiez que le nœud est en ligne et qu’aucune opération de cycle de vie conflictuelle n’est en cours.
4. Consignez sa version actuelle, ses capacités, ses charges de travail actives et ses erreurs récentes.
5. Pour un Relay Pool, utilisez la mise à jour du Relay Pool, qui vide, met à jour et vérifie un membre à la fois.
6. Assurez-vous qu’un opérateur peut joindre l’hôte si la reprise automatique échoue.

Opfield et les démons vérifient les manifestes de mise à jour signés et les sommes de contrôle. Ne remplacez pas une mise à jour signée en échec par un binaire non signé copié depuis un autre hôte.

Vérification de la mise à jour

Après le redémarrage du démon, vérifiez davantage que sa version :

• la reconnexion authentifiée et une heure de dernière activité récente ;
• un rapport de capacités complet ;
• l’actualisation de l’inventaire et des métriques ;
• la santé des services propres au rôle ;
• la réconciliation des tâches en attente ;
• les Routes, certificats, charges de travail, projets Compose et liaisons de bases de données détenus par ce nœud ;
• les alertes déclenchées ou levées comme prévu.

Comportement hors ligne par responsabilité

Une connexion de contrôle hors ligne n’arrête pas automatiquement les services de l’hôte. nginx, les conteneurs, les bases de données managées et les autres services déjà appliqués peuvent continuer à partir de l’état local. Opfield empêche les modifications qui nécessitent un propriétaire actif et n’affiche l’inventaire en cache que pour le diagnostic.

Les liaisons de bases de données peuvent continuer via un chemin Relay et base de données sain pendant un redémarrage de la seule application Opfield ; les relais continuent d’admettre de nouvelles connexions selon leur dernière politique signée pendant la durée du bail de politique. Une panne de Relay est différente : elle interrompt les nouvelles admissions de liens privés et le trafic de contrôle des nœuds gérés, même lorsque les charges de travail locales continuent. Lorsqu’Opfield revient, les démons se reconnectent en moins de 15 secondes.

Redémarrages du démon Docker

Le redémarrage ou la mise à jour du démon Docker n’arrête pas les conteneurs, et n’interrompt que brièvement le trafic vers eux. Une mise à jour avec transfert à chaud conserve les connexions ouvertes, comme décrit dans Connexions pendant une mise à jour du démon ; les points ci-dessous s’appliquent aux redémarrages qui ne transfèrent pas les connexions :

• Le démon se connecte d’abord à Opfield et réenregistre ses points de terminaison Relay, en une seconde environ, dès que les nouvelles autorisations d’Opfield arrivent. Secure Runtime (gVisor) est ensuite revérifié en arrière-plan. Tant que ce n’est pas terminé, le nœud signale le dernier résultat vérifié pour la même version de runsc, ou un état inconnu avec la raison verification_pending au premier démarrage d’une nouvelle version ; la création de charges de travail sécurisées ne fluctue donc pas.
• Un redémarrage ou une mise à jour en douceur est annoncé. Avant de s’arrêter, le démon indique aux relais que ses points de terminaison redémarrent, termine les requêtes Secure Link en cours (au plus 1 seconde) et ferme les connexions inactives entre deux requêtes. Les relais conservent ses enregistrements jusqu’à 15 secondes, le temps que le processus suivant s’enregistre, et les nœuds Ingress retiennent les nouvelles connexions vers lui jusqu’à 8 secondes au lieu de les faire échouer ; un redémarrage se traduit donc par un délai de quelques secondes plutôt que par des erreurs. Une réplique Availability disposant d’une autre réplique active n’attend pas : ses requêtes vont immédiatement vers l’autre réplique. Cela nécessite des relais et des démons nginx de cette version ; avec des relais plus anciens, le nœud Ingress retient tout de même les nouvelles connexions jusqu’à 3 secondes.
• Le détenteur d’un bail Availability continue de servir lors d’un redémarrage dans le même cycle de démarrage de l’hôte : son bail est toujours valide, et sa copie reprend donc le trafic dès que le nouveau processus s’enregistre.
• Un démon qui plante, ou dont l’hôte devient injoignable, n’est pas retenu : les relais abandonnent sa connexion en 3,5 secondes environ, et les requêtes passent sur d’autres placements s’il en existe.
• Après un redémarrage de l’hôte, chaque Secure Link est rétabli indépendamment : un lien dont la cible n’est pas revenue reste non lié jusqu’à ce que sa cible s’exécute, et ne bloque pas les autres.
• Un Docker Engine (dockerd) bloqué n’arrête pas le trafic vers les conteneurs et Deployments en cours d’exécution : les connexions Secure Link, aux bases de données managées et au stockage l’attendent au plus 300 millisecondes puis utilisent la dernière adresse qu’il a indiquée, les liens restent liés lorsqu’il ne répond pas à une synchronisation, et les routeurs de Deployment n’utilisent ni le DNS de Docker ni un journal d’accès. Une application qui écrit chaque requête sur la sortie de son conteneur peut tout de même se bloquer tant que dockerd est figé.
• Un nœud Storage ou de base de données démarre même lorsque l’un de ses conteneurs managés est manquant ; ce stockage ou cette base de données apparaît comme arrêté au lieu de mettre le nœud hors ligne.
• Les avertissements de chaque composant du démon, comme les connexions de liens refusées, parviennent aux journaux du nœud dans Opfield, et pas seulement au journal de l’hôte.

Les nœuds qui votent pour les baux du basculement du plan de données ou peuvent en détenir sont mis à jour un par un pour chaque politique Availability : une mise à jour du démon d’un tel nœud peut attendre ses pairs de bail, et le nœud apparaît comme en cours de mise à jour pendant ce temps. Voir Mises à jour et versions mixtes. Sur les nœuds Docker susceptibles de détenir des baux, le lease watchdog s’exécute comme service propre, opfield-lease-watchdog, et se met à jour lui-même.

Un nœud ramené à n’importe quelle version de démon depuis 2.10.0 démarre toujours : les démons conservent, à côté des leurs, les fichiers d’état que lit une version plus ancienne. Les démons remplacent leurs fichiers d’état de façon durable (écriture, vidage sur disque, renommage) ; un kill -9 ou une coupure de courant ne laisse donc jamais de fichier partiel.

Démon Docker 2.11.1 et connecteur partagé

Le démon Docker 2.11.1 sert chaque liaison de base de données, chaque lien de stockage et chaque lien entre conteneurs du nœud via un seul connecteur secure-link partagé, sans conteneurs par lien ni écouteurs sur l’hôte ; voir Connecteur partagé et réseaux de liens.

• Les liaisons de bases de données passent sur le connecteur après la mise à jour : Opfield recrée une fois chaque charge de travail liée, une à la fois sur chaque nœud, la suivante une fois que la précédente s’exécute sainement. Un Deployment se déploie en blue/green sans interruption ; un Container autonome ou un service Compose redémarre une fois.
• Les liens de stockage créés avant 2.11.1 passent sur le connecteur après la mise à jour, et Opfield recrée une fois chaque charge de travail liée juste après la bascule de son lien. Les liens créés en 2.11.1 ne nécessitent pas de recréation.
• Revenir au démon Docker 2.11.0 rebascule automatiquement les liens, là encore avec une recréation par charge de travail. Au plus quatre charges de travail par nœud sont recréées simultanément, limite du démon pour les commandes concurrentes ; sur un nœud comportant de nombreux Deployments liés, les derniers se reconnectent donc un peu plus tard.
• Les mises à jour du connecteur conservent les connexions de liens ouvertes : à partir de 2.11.4, l’ancien connecteur les transmet au nouveau. Un connecteur antérieur à 2.11.4 les conserve jusqu’à une heure, puis les ferme une fois ; les clients se reconnectent au nouveau connecteur.
• Les liens entre conteneurs nécessitent le démon Docker 2.11.1 sur les deux nœuds et affichent update required d’ici là.
• Plage des réseaux de liens : les nouveaux réseaux de liens prennent chacun un /26 dans docker.secure_links.subnet_pool de /etc/docker-daemon/config.yaml, 10.213.x.x (un /16) par défaut. Le démon ignore les sous-réseaux déjà utilisés par des réseaux Docker ou par les routes de l’hôte ; changez la plage lorsqu’elle chevauche un réseau que le nœud joint par sa route par défaut, puis redémarrez le démon.

Redémarrages du démon nginx

Le redémarrage ou la mise à jour du démon nginx sur un nœud Ingress ne ferme pas ses sockets Secure Link. Le lanceur qui supervise le démon conserve une copie de chaque socket d’écoute et les transmet au processus suivant du démon ; avec systemd, il les conserve aussi dans le magasin de descripteurs de fichiers de l’unité, afin qu’ils survivent à systemctl restart. Tant qu’aucun processus du démon ne s’exécute, les nouvelles connexions attendent dans la file du socket et sont servies par le processus suivant. À l’arrêt, le démon cesse d’accepter, termine les requêtes en cours pendant au plus 1,5 seconde et ferme les connexions inactives entre deux requêtes afin que nginx se reconnecte dans la file.

• La mise à jour depuis 2.10 est visible une fois. L’ancien démon ne transmet rien lorsqu’il s’arrête ; cette mise à jour-là interrompt donc les routes Secure Link passant par le nœud pendant environ une seconde. Ensuite, les redémarrages et mises à jour conservent les sockets, y compris le redémarrage au cours duquel le lanceur essaie sa nouvelle version : tant qu’un lanceur plus ancien qui ne conserve pas de sockets s’exécute encore, le démon stocke lui-même ses écouteurs dans le magasin de descripteurs de fichiers de systemd.
• Les requêtes qui durent plus longtemps que le vidage de 1,5 seconde, ainsi que les flux de longue durée comme WebSocket ou les server-sent events, sont coupés lors d’un redémarrage qui ne transfère pas les connexions ; une mise à jour du démon avec transfert à chaud les conserve.
• Sur les nœuds sans systemd (OpenRC), les redémarrages pour mise à jour et après un plantage sont couverts par le lanceur, mais pas un redémarrage du service. Les Routes dont la configuration utilise encore un écouteur TCP en boucle locale au lieu d’un socket Secure Link refusent les connexions pendant un redémarrage, comme auparavant.

Les sockets Secure Link sont créés sous un nom temporaire avec leur propriétaire et leur mode définitifs, puis renommés ; nginx ne trouve donc jamais un socket manquant ou qu’il n’a pas le droit d’utiliser ; avant le chargement d’une configuration, chaque socket qu’elle référence écoute déjà.

Lorsqu’Opfield démarre avant qu’un nœud Ingress ne se soit reconnecté, les modifications destinées à ce nœud, comme des routes réécrites après une mise à jour de modèle, sont laissées à la synchronisation de reconnexion du nœud au lieu d’échouer.

Séquence de reprise

1. Rétablissez l’alimentation et la joignabilité réseau de l’hôte.
2. Vérifiez l’heure système, le DNS et la connectivité au point de terminaison Relay.
3. Examinez l’unité systemd du démon et des journaux limités.
4. Confirmez que le certificat du démon et l’identité du nœud n’ont pas été remplacés.
5. Attendez la reconnexion et un nouvel inventaire.
6. Examinez les opérations échouées ou interrompues avant de les relancer.
7. Vérifiez chaque famille de ressources dépendantes détenue par le nœud.

Ne supprimez pas un nœud hors ligne simplement pour faire disparaître un avertissement. La suppression modifie la propriété durable et peut empêcher l’ancien démon, toujours en cours d’exécution, de se réconcilier en toute sécurité.

Opérations interrompues

Un passage hors ligne peut laisser une opération dont l’intention a été acceptée mais dont le résultat final sur l’hôte n’a pas été acquitté. Après la reconnexion, Opfield réconcilie l’état interrompu pris en charge à partir du démon et de l’inventaire des ressources. Examinez l’opération avant de lancer une autre action : répéter à l’aveugle une création, une mise à jour, une migration ou une suppression peut entrer en conflit avec un travail déjà terminé sur l’hôte.

Comparez l’enregistrement de l’opération avec la ressource propriétaire réelle. Un Container peut être en cours d’exécution même si la dernière progression affichée a été interrompue ; un projet Compose peut avoir appliqué une révision sans renvoyer son acquittement final ; une mise à jour peut avoir redémarré le démon avant le retour de la session de contrôle. Utilisez l’instantané actualisé et l’état propre au rôle comme éléments de preuve, puis ne relancez que la poursuite ou l’action de reprise prise en charge.

L’annulation forcée d’une tâche arrête ou abandonne le travail du plan de contrôle lorsque c’est pris en charge ; elle ne garantit pas que chaque sous-processus côté hôte ou chaque modification d’exécution déjà appliquée a été annulé. Vérifiez la ressource après l’annulation et effectuez un nettoyage explicite lorsque l’opération indique qu’il est nécessaire.

Remplacement ou reprise

Reprenez l’identité existante lorsque l’hôte et le matériel persistant de son démon existent encore. Ne remplacez le nœud que lorsque l’hôte est délibérément reconstruit ou que son identité ne peut pas être récupérée. Avant le remplacement, inventoriez les Routes, charges de travail, instances de bases de données, affectations de builds, certificats, volumes et affectations Relay détenus par l’ancien nœud, et déplacez-les ou mettez-les hors service via leur cycle de vie pris en charge.

N’exécutez jamais la même identité de démon simultanément sur l’ancien hôte et sur son remplaçant. Si l’hôte d’origine est susceptible de revenir, désactivez-le ou désinstallez-le avant d’enrôler le remplaçant. Une identité en double peut produire des inventaires et des acquittements d’opérations contradictoires, même lorsque les deux hôtes ont des adresses différentes.

Test hors ligne planifié

Avant de vous appuyer sur un nœud en production, effectuez un exercice de reprise borné : redémarrez le démon, confirmez que les services locaux se comportent comme documenté, attendez la reconnexion et vérifiez un nouvel inventaire ainsi qu’une ressource dépendante représentative. Pour les chemins Relay et de bases de données, testez les nouvelles connexions comme les connexions existantes. Consignez le temps de reprise observé et le chemin d’accès manuel nécessaire si la reconnexion automatique échoue.