Mise à niveau

Une mise à niveau installe les paquets d'une nouvelle version par-dessus les anciens, depuis un nouveau dépôt hors ligne. Les services redémarrent, les machines virtuelles continuent de s'exécuter pendant le redémarrage de l'agent d'un hôte, et les fichiers de configuration ne sont pas écrasés. L'installateur s'exécute sur chaque machine ; la console affiche les versions avant et après. Les notes de version listent les changements qui demandent une action : Notes de version.

Dans la console

1. Sur la page Accueil, sélectionnez État des mises à niveau. La carte Contrôleur affiche la Version du contrôleur, la Version de l’API, En fonctionnement depuis et le Rôle. Le tableau Hôtes affiche la version de l'agent de chaque hôte.

   (Agrandir)

   Fermer la vue agrandie
2. Sauvegardez le contrôleur. Sélectionnez Sauvegarde, puis Sauvegarder le contrôleur maintenant ; voir Sauvegarder le contrôleur. Vérifiez que le disque du contrôleur a de la place pour une seconde copie du magasin (inventory.redb).
3. Vérifiez le nouveau dépôt avec la clé publique de la version sur la machine : Dépôt hors ligne. Lisez les notes de version et la note de mise à niveau ci-dessous.
4. Installez le rôle de contrôleur depuis le nouveau dépôt sur la machine du contrôleur ; la commande est dans Automatisation. Le service redémarre et la console se reconnecte.
5. Mettez les hôtes à niveau un par un. L'agent et le VMM d'un hôte sont installés ensemble à la même version. L'agent redémarre et ses machines virtuelles continuent de s'exécuter. Lorsqu'un hôte doit être libre de machines virtuelles pour un autre travail, sélectionnez l'hôte et sélectionnez d'abord Passer en mode maintenance, après avoir déplacé ou mis hors tension ses machines (mode maintenance). Installez le rôle d'agent sur la machine, puis vérifiez que l'hôte est de nouveau Connecté avant de passer à l'hôte suivant. Mettez fin au mode maintenance avec Quitter le mode maintenance.
6. Revenez à État des mises à niveau. La colonne État affiche À la version du contrôleur pour chaque hôte. Un hôte d'une autre version que le contrôleur affiche Diffère du contrôleur, et un avertissement au-dessus du tableau les compte.

Résultat

La carte Contrôleur affiche la nouvelle version, et chaque hôte indique la même version d'agent dans le tableau Hôtes.

Note de mise à niveau : historique sur disque

Une mise à niveau n'exige aucune action pour ceci : un magasin et un fichier de métriques existants s'ouvrent tels quels, avec une exception.

Le premier démarrage de cette version déplace les tâches, événements et enregistrements d'audit de l'instantané vers des tables de inventory.redb. Il écrit pour cela un instantané aussitôt et, avant, copie le magasin fermé vers /var/lib/kyvernon/controller/inventory.redb.before-history-on-disk sauf si l'opérateur a désactivé cette copie. Laissez de la place sur le disque pour une seconde copie du magasin, et supprimez la copie lorsque le contrôleur fonctionne bien. Le fichier du magasin contient maintenant le texte de l'historique, jusqu'à la limite de taille de l'historique plus les enregistrements d'audit ; voir Configuration.

Pour revenir à une version précédente, l'opérateur désactive l'historique sur disque dans la configuration du contrôleur et démarre le contrôleur une fois : il charge l'historique en mémoire (il refuse au-delà de 512 MiB de texte sauf si l'opérateur le force) et réécrit l'instantané dans l'ancien format. Arrêtez-le ensuite et installez la version précédente. Une version précédente ne peut pas ouvrir un magasin dans lequel l'historique a été déplacé. Restaurer la copie faite avant la mise à niveau fonctionne aussi, mais perd ce qui a été écrit depuis.

Automatisation

Avec la CLI

Sur le contrôleur, installez le rôle de contrôleur depuis le nouveau dépôt. La commande est celle de la première installation :

sudo ./kyvernon-install --role controller --pubkey /path/to/release-signing.minisign.pub

Un service configuré qui s'exécutait est redémarré par la mise à niveau. Les fichiers de configuration de /etc/kyvernon ne sont jamais écrasés : comparez-les aux nouveaux squelettes de /usr/share/kyvernon/ pour y trouver de nouvelles clés, puis vérifiez la configuration :

diff /etc/kyvernon/controller.toml /usr/share/kyvernon/controller.toml.example
sudo kyvernon-controller --config /etc/kyvernon/controller.toml check-config
kyvernon system ready

Mettez ensuite les hôtes à niveau, un par un :

sudo ./kyvernon-install --role agent --pubkey /path/to/release-signing.minisign.pub

kyvernon about sur une machine avec le client en ligne de commande affiche la version du contrôleur, et kyvernon inventory host <id> affiche la version d'agent d'un hôte.

Avec l'API

GET /v1/about renvoie la version du contrôleur, et GET /v1/inventory/hosts/{id} la version d'agent d'un hôte. L'API n'a aucun appel qui installe une mise à niveau.

Voir aussi

• Configuration
• Hôtes