Comment mettre à jour Shinken ?

I. Présentation

Installer Shinken est une chose, mais le mettre à jour en est une autre. Lorsqu’une nouvelle version de Shinken voit le jour, il faut alors pouvoir mettre à jour celle-ci sur la plateforme de production, sans pour autant perdre les informations et le contenu du site de supervision.

Rappelons qu’il existe deux grandes stratégies d’installation de Shinken et qu’il n’y a (pour le moment), aucun package ne permettant d’automatiser la phase d’installation :

- Installation par les fichiers sources .tar.gz
- Installation par les utilitaires pip ou easy_install

De plus, la mise à jour de la version de Shinken reste principalement un objectif de sécurisation (correction de bug) et aussi d’évolutivité (mise à jour du système d’exploitation). Mais, quelle que soit la méthode utilisée pour mettre en œuvre Shinken, lorsque l’on souhaite upgrader sa plateforme de production, il faut toujours utiliser la même méthode, au fil du temps.

ATTENTION : indépendamment de la méthode utilisée pour installer et mettre à jour Shinken, il faut systématiquement faire une sauvegarde préventive avant toute modification.

Puis, il faut alors créer les répertoires à restaurer, sur un nouveau serveur :

- /etc/shinken
- /var/lib/shinken
- /var/run/shinken
- /var/log/shinken

Il faut bien évidemment positionner les droits d’appartenance au compte shinken pour ces différents répertoires :

# chown –R shinken:shinken /etc/shinken
# chown –R shinken:shinken /var/lib/shinken
# chown –R shinken:shinken /var/run/shinken
# chown –R shinken:shinken /var/log/shinken

On peut alors lancer l’installation de Shinken selon le choix effectué au préalable. On peut éventuellement s’inspirer du billet concernant l’installation Shinken en 10 étapes :

- Initialisation de l’environnement & prérequis
- Installation d’outils supplémentaires
- Clonage de la branche git du projet Shinken
- Installation de l’application Shinken
- Mise en place des droits
- Initialisation de Shinken
- Installation des modules de base
- Démarrage des services
- Connexion à Shinken

Une fois que l’installation de la nouvelle vm, ou de la nouvelle machine de façon générale, est installée, on peut alors copier le contenu de l’ancienne version dans la nouvelle arborescence.

REMARQUE : on peut utiliser un archivage, via la commande tar, contenant l’intégralité de la configuration de production ou utiliser une copie : cp, scp ou rsync.

II. Sauvegarde intégrale du site de supervision de production

Afin d’effectuer une sauvegarde complète du site de supervision de production, on peut donc utiliser la commande tar :

$ tar cvf SaveFullShinken.tar /etc/shinken /var/lib/shinken

Bien évidemment, le fait d’avoir initialement installé Shinken, permet de générer les scripts de pilotage (dans le répertoire /etc/init.d), ainsi que les fichiers de processus (dans /var/run/shinken) et les fichiers de traces (dans /var/log/shinken).

Donc, seuls les deux répertoires /etc/shinken et /var/lib/shinken , contenant les définitions des objets et des contrôles de supervision, ainsi que le code Python des modules et de l’interface WebUI, sont nécessaires pour récupérer l’environnement de production actuel.

III. Restauration de l’archive Shinken

Pour installer la nouvelle version, deux cas de figure se présentent :

- Soit on installe la nouvelle version sur le même serveur
- Soit on installe un nouveau serveur

Personnellement, j’aurai tendance à privilégier la seconde solution, car il y a moins de risque d’écrasement d’une version par l’autre. Dans ce cas, il suffit de réinstaller un nouveau serveur (cf. le tutoriel sur l’installation Shinken en dix étapes).

A. Installation sur un nouveau serveur

Une fois que l’on a installé le nouveau site Shinken, il ne reste plus alors qu’à réinjecter le contenu de la sauvegarde précédente :

$ tar xvf --atime-preserve --preserve --same-owner /tmp/SaveFull/shinken.tar

Ainsi, on retrouve l’intégralité des scripts et des modèles liés à notre supervision de production, en conservant les permissions, les propriétaires actuels ainsi que l’horodatage. Cette dernière propriété garantit une totale adéquation avec la date et heure des fichiers actuels, à condition, bien sûr que le nouveau serveur soit également synchronisé sur le même serveur de temps NTP, que celui de production.

ATTENTION : les répertoires contenant les modules ont changé depuis la version Shinken 2.0. Donc, si l’on copie la version d’une distribution antérieure, cela fonctionnera, mais on risque de rencontrer des problèmes lors de l’utilisation du mode commande Shinken.

B. Installation sur le même serveur

Dans ce cas, les choses sont un peu plus compliquées. Il faut commencer par arrêter les services Shinken, pour pouvoir renommer les répertoires en guise de sauvegarde :

# systemctl stop shinken
# cp /etc/shinken /etc/shinken.sav
# cp //var/lib/shinken /var/lib/shinken.sav
# cp /var/run/shinken /var/run/shinken.sav
# cp /var/log/shinken /var/log/shinken.sav

REMARQUE : il faut également renommer les scripts d’arrêt et de démarrage se trouvant dans /etc/init.d. En effet, peut-être que la nouvelle version apporte aussi son lot de modifications lors des phases d’initialisation.

On peut alors installer la nouvelle version (toujours en suivant le tutoriel concernant l’installation Shinken en dix étapes). On devrait alors disposer des nouveaux répertoires ci-dessous ainsi que des scripts de démarrage dans /etc/init. :

- /etc/shinken
- /var/log/shinken
- /var/run/shinken
- /var/lib/shinken

Bien, maintenant, il ne reste plus qu’à réinjecter le contenu de l’archive tar créé précédemment afin de réinjecter l’ensemble des scripts et de la configuration du site de production :

$ tar xvf --atime-preserve --preserve --same-owner /tmp/SaveFull/shinken.tar

On devrait alors pouvoir démarrer l’ensemble des services en ayant conservé la configuration de production et en ayant migré sur la nouvelle version Shinken :

# systemctl start shinken

IV. Vérifications

Lorsque l’ensemble des services et du contenu sont restaurés, on peut alors démarrer les services Shinken.

ATTENTION : il faut toujours s’assurer d’avoir récupérer la totalité des modules, précédemment déclarés dans le répertoire /var/lib/shinken/modules, avant de démarrer les services Shinken.

Il faut donc lister les modules déjà actifs sur le site de production avec la commande ci-dessous et comparer le résultat à celui du nouveau site :

$ shinken inventory

Il faut impérativement que les deux coïncident. Sinon, il manque quelque chose et les services risquent de ne pas démarrer ou de ne pas fonctionner correctement.

Certains modules peuvent également nécessiter une mise à jour, pour être opérationnels dans le nouveau contexte. Dans ce cas, il faudra exécuter la commande ci-dessous, autant de fois qu’il y aura de modules à mettre à jour :

$ shinken update <Module>

Où <Module> représente le nom du ou des module(s) à mettre à jour.

Quoi qu’il en soit, il faut également scruter les journaux de logs (dans /var/log/shinken), afin de s’assurer que sur le nouveau serveur, lors du redémarrage, avec la nouvelle version, aucune erreur n’est détectée. On peut également vérifier qu’aucun fichier bad* n’a été généré dans le répertoire /tmp : signe qu’une erreur est survenue lors de la phase de démarrage des services.

REMARQUE : il ne faut surtout pas changer de système d’exploitation ou de distribution en cours de migration. La mise à jour doit se faire sur un système équivalent à celui du site de production initial.

Philippe PIERRE

A exercé de nombreuses années en tant qu'administrateur de base de données et comme administrateur Système Unix/Linux. Il a enseigné les réseaux au CNAM (Paris). Aujourd'hui, employé en tant qu'ingénieur infrastructure, au sein d'un laboratoire pharmaceutique et administrant un cluster de calculs HPC, il connaît parfaitement les environnements GNU/Linux dans le cadre d'une entreprise et des systèmes de haute disponibilité. Il aime partager son expérience.

See Full Bio