Guide de migration vers Canopsis 26.04.0¶
Ce guide donne les instructions vous permettant de mettre à jour Canopsis 25.04 (dernière version disponible) vers la version 26.04.0.
Sommaire¶
Prérequis¶
L'ensemble de cette procédure doit être lue avant son exécution.
Ce document ne prend en compte que Canopsis Community et Canopsis Pro : tout développement personnalisé dont vous pourriez bénéficier ne fait pas partie du cadre de ce Guide de migration.
Les fichiers de référence qui sont mentionnés dans ce guide sont disponibles à ces adresses
| Édition | Sources |
|---|---|
| Édition Community | https://git.canopsis.net/canopsis/canopsis-community/-/releases |
| Édition pro | https://git.canopsis.net/sources/canopsis-pro-sources/-/releases |
Utilisateurs Helm
Pour les environnements déployés via Helm, la grande majorité des mises à jour
décrites dans ce guide (MongoDB, TimescaleDB, RabbitMQ, Valkey) sont prises en
charge nativement par les configurations de référence fournies par Canopsis.
Sauf mention contraire dans l'onglet correspondant, aucune action manuelle n'est
requise pour ces composants. Seule la commande helm upgrade finale est
indispensable.
Réalisation d'une sauvegarde¶
Des sauvegardes sont toujours recommandées, qu'elles soient régulières ou lors de modifications importantes.
Arrêt de l'environnement en cours d'exécution¶
Vous devez prévoir une interruption du service afin de procéder à la mise à jour qui va suivre.
systemctl stop canopsis.service
Vous devez prévoir une interruption du service afin de procéder à la mise à jour qui va suivre.
CPS_EDITION=pro docker compose down
Vous devez prévoir une interruption du service afin de procéder à la mise à jour qui va suivre.
kubectl delete deployments --all
Mise à jour de MongoDB¶
Vérifications MongoDB¶
Vérification
Avant de démarrer la procédure de mise à jour, vous devez vérifier que la valeur de featureCompatibilityVersion est bien positionnée à 8.0
mongosh -u root -p root
> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
> exit
Mise à jour¶
Stopper MongoDB
systemctl stop mongod.service
Mettre à jour les versions des paquets de MongoDB
dnf update mongodb-org mongodb-org-database mongodb-org-server mongodb-org-mongos mongodb-org-tools -y
Relancer MongoDB
systemctl start mongod.service
Aucune action de mise à jour ne sont à réaliser dans un environnement Docker Compose.
Attention
Ce bloc est réservé uniquement aux environnements impliquant MongoDB exécuté dans un environnement Kubernetes.
Si ce n'est pas votre cas, référez-vous au bloc « RPM ».
Vous n'avez rien de particulier à prévoir, les configurations de référence livrées par Canopsis embarquent ce changement naturellement.
Mise à jour TimescaleDB¶
Dans cette version de Canopsis, la base de données TimescaleDB passe de la version 2.21.4 à 2.26.1.
Sauvegarder les bases de données canopsis et canopsis_tech_metrics
set -o allexport ; source /opt/canopsis/etc/go-engines-vars.conf
sudo -iu postgres pg_dump $(eval echo "$CPS_POSTGRES_URL") --no-owner -Fc -v -f /tmp/canopsis-$(date +"%Y-%m-%d")-canopsis-dump.sql.gz
sudo -iu postgres pg_dump $(eval echo "$CPS_POSTGRES_TECH_URL") --no-owner -Fc -v -f /tmp/canopsis-$(date +"%Y-%m-%d")-canopsis_tech_metrics-dump.sql.gz
Une fois les sauvegardes réalisées, supprimer le versionlock des paquets TimescaleDB
dnf versionlock delete timescaledb-2-postgresql-17
dnf versionlock delete timescaledb-2-loader-postgresql-17
Installer le paquet de la version de timescaledb :
dnf install timescaledb-2-postgresql-17-2.26.1 timescaledb-2-loader-postgresql-17-2.26.1
Réactiver le versionlock
dnf versionlock add timescaledb-2-loader-postgresql-17 timescaledb-2-postgresql-17
Se connecter avec le compte administrateur sur le base :
sudo -u postgres psql
Mettre à jour l'extension dans TimescaleDB :
- Sur la base de données canopsis
postgres=# \c canopsis
canopsis=# ALTER EXTENSION timescaledb UPDATE;
canopsis=# \dx timescaledb
Liste des extensions installées
Nom | Version | Schéma | Description
-------------+---------+--------+---------------------------------------------------------------------------------------
timescaledb | 2.26.1 | public | Enables scalable inserts and complex queries for time-series data (Community Edition)
(1 ligne)
- Sur la base de données
canopsis_tech_metricspostgres=# \c canopsis_tech_metrics canopsis_tech_metrics=# ALTER EXTENSION timescaledb UPDATE; canopsis_tech_metrics=# \dx timescaledb Liste des extensions installées Nom | Version | Schéma | Description -------------+---------+--------+--------------------------------------------------------------------------------------- timescaledb | 2.26.1 | public | Enables scalable inserts and complex queries for time-series data (Community Edition) (1 ligne)
Démarrez et mettez à jour l'extension TimescaleDB
CPS_EDITION=pro docker compose up -d timescaledb
CPS_EDITION=pro docker compose exec timescaledb psql postgresql://postgres:canopsis@timescaledb:5432/canopsis
canopsis=# ALTER EXTENSION timescaledb UPDATE;
canopsis=# \c canopsis_tech_metrics
canopsis_tech_metrics=# ALTER EXTENSION timescaledb UPDATE;
Vérifiez que la version de l'extension soit bien mise à jour
canopsis=# \dx timescaledb
List of installed extensions
Name | Version | Schema | Description
-------------+---------+--------+---------------------------------------------------------------------------------------
timescaledb | 2.26.1 | public | Enables scalable inserts and complex queries for time-series data (Community Edition)
(1 row)
Attention
Ce bloc est réservé uniquement aux environnements impliquant MongoDB exécuté dans un environnement Kubernetes.
Si ce n'est pas votre cas, référez-vous au bloc « RPM ».
Vous n'avez rien de particulier à prévoir, les configurations de référence livrées par Canopsis embarquent ce changement naturellement.
Mise à jour RabbitMQ¶
Pour mettre à jour RabbitMQ, retirer en premier lieu le versionlock de la version 4.1 de rabbitmq-server, puis appliquer celui pour la version 4.2 :
dnf versionlock delete 'rabbitmq-server-4.1*'
dnf versionlock add --raw 'rabbitmq-server-4.2*'
Stopper RabbitMQ
systemctl stop rabbitmq-server.service
Lancer la mise à jour :
dnf upgrade rabbitmq-server -y
Démarrer RabbitMQ
systemctl start rabbitmq-server.service
Vérifier la version de rabbitmq :
rabbitmqctl --version
4.2.4
Dans cette version de Canopsis, le bus de données RabbitMQ passe de la version 4.1 à 4.2.
Les configurations de référence fournies dans Canopsis embarquent déjà ce changement.
Démarrez le conteneur rabbitmq :
CPS_EDITION=pro docker compose up -d rabbitmq
Dans cette version de Canopsis, le bus de données RabbitMQ passe de la version 4.1 à 4.2.
Les configurations de référence fournies dans Canopsis embarquent déjà ce changement.
Mise à jour Valkey¶
Warning
Les paquets n'étant plus mis à jour dans les dépôts EPEL, il est nécessaire de passer sur les dépôts REMI afin d'avoir accès aux dernières versions de Valkey.
En passant sur les dépôts REMI, la méthode d'installation change pour repasser sur un système de module dnf.
Sauvegarder le contenu de configurations Valkey ainsi que les données présentes
cp -r /etc/valkey /etc/valkey.backup
cp -r /var/lib/valkey /var/lib/valkey.backup
Stopper Valkey
systemctl stop valkey
Supprimer la version EPEL de Valkey
dnf remove valkey
Supprimer le versionlock de Valkey
dnf versionlock delete 'valkey-8.*'
Installer les dépôts REMI et configurer le module pour Valkey
dnf install https://rpms.remirepo.net/enterprise/remi-release-$(cat /etc/redhat-release | cut -d'.' -f1 | awk '{print $NF}').rpm
dnf module reset valkey -y
dnf module enable valkey:remi-9.0 -y
dnf install valkey
Réappliquer la configuration
cp -r /etc/valkey.backup/* /etc/valkey/
Démarrer Valkey
systemctl enable --now valkey.service
Vérifier la version de valkey-server :
valkey-server --version
Valkey server v=9.0.3 sha=00000000:0 malloc=jemalloc-5.3.0 bits=64 build=91c5dc4ffc238810
Vous n'avez rien de particulier à prévoir, les configurations de référence livrées par Canopsis embarquent ce changement naturellement.
Vous n'avez rien de particulier à prévoir, les configurations de référence livrées par Canopsis embarquent ce changement naturellement.
Mise à jour de Canopsis¶
Mise à jour des paquets¶
Supprimer le versionlock
dnf versionlock delete 'canopsis-25.10.*'
dnf versionlock delete 'canopsis-common-25.10.*'
dnf versionlock delete 'canopsis-webui-25.10.*'
Mettre à jour les paquets de Canopsis
dnf upgrade canopsis-pro canopsis-webui
Ajouter le versionlock
dnf versionlock add --raw 'canopsis-26.04.*'
dnf versionlock add --raw 'canopsis-common-26.04.*'
dnf versionlock add --raw 'canopsis-webui-26.04.*'
Synchronisation du fichier de configuration canopsis.toml ou fichier de surcharge¶
Si vous avez modifié le fichier canopsis.toml (vous le voyez via une définition de volume dans votre fichier docker-compose.yml), vous devez vérifier qu'il soit bien à jour par rapport au fichier de référence.
Information
Pour éviter ce type de synchronisation fastidieuse, la bonne pratique est d'utiliser un fichier de surcharge de cette configuration.
Si vous avez utilisé un fichier de surcharge, alors vous n'avez rien à faire, uniquement continuer à le présenter dans un volume.
Lancement du provisioning canopsis-reconfigure et terminer la mise à jour.¶
Attention
Si vous avez personnalisé la ligne de commande de l'outil canopsis-reconfigure, nous vous conseillons de supprimer cette personnalisation.
L'outil est en effet pré paramétré pour fonctionner naturellement.
Si un fichier d'override du canopsis.toml est utilisé, ajouter à la ligne de commande suivante l'option -override suivie du chemin du fichier en question.
Il est nécessaire de vérifier que les services postgresql-17.service et mongod.service sont bien démarrés puis lancer le reconfigure
systemctl status postgresql-17 mongod
set -o allexport ; source /opt/canopsis/etc/go-engines-vars.conf
/opt/canopsis/bin/canopsis-reconfigure -migrate-postgres=true -migrate-tech-postgres=true -migrate-mongo=true -edition pro
Information
Cette opération peut prendre plusieurs minutes pour s'exécuter.
Vous pouvez ensuite vérifier que le mécanisme de reconfigure s'est correctement déroulé en lisant les logs sur la sortie standard de la commande.
Redémarrage de Canopsis
systemctl start canopsis
Vérifier que l'ensemble des services soient correctement exécutés.
systemctl status canopsis
Par ailleurs, le mécanisme de bilan de santé intégré à Canopsis ne doit pas présenter d'erreur.
CPS_EDITION=pro docker compose up -d reconfigure
Information
Cette opération peut prendre plusieurs minutes pour s'exécuter.
Vous pouvez ensuite vérifier que le mécanisme de provisioning/reconfigure s'est correctement déroulé. Le conteneur doit présenter un "exit 0"
CPS_EDITION=pro docker compose ps -a|grep reconfigure
canopsis-pro-reconfigure-1 "/canopsis-reconfigu…" reconfigure exited (0)
Enfin, il vous reste à mettre à jour et à démarrer tous les composants applicatifs de Canopsis
CPS_EDITION=pro docker compose up -d
Vous pouvez ensuite vérifier que l'ensemble des conteneurs soient correctement exécutés.
CPS_EDITION=pro docker compose ps
Par ailleurs, le mécanisme de bilan de santé intégré à Canopsis ne doit pas présenter d'erreur.
Définir le nom de votre instance
export RELEASE_NAME="canopsis-prod"
Mise à jour des repos helm
helm repo update
Mise à jour de Canopsis
helm upgrade ${RELEASE_NAME} canopsis/canopsis-pro -f customer-values.yaml
Par ailleurs, le mécanisme de bilan de santé intégré à Canopsis ne doit pas présenter d'erreur.