Migration de Windows vers Docker

Ce guide accompagne pas à pas la migration d’une installation Relution existante sur un serveur Windows vers une installation moderne basée sur Docker sur un serveur Linux.

Que se passe-t-il lors de cette migration ? #

L’installation Relution actuelle fonctionne sur un serveur Windows avec une base de données MariaDB. La nouvelle configuration fonctionne sur un serveur Linux dans des « conteneurs » (Docker). La différence qui rend cette migration nécessaire : Windows ne distingue pas les majuscules et les minuscules dans les noms de fichiers et de tables. Linux, en revanche, fait cette distinction. C’est pourquoi certains noms de tables dans la base de données doivent être convertis en majuscules après le déménagement – un script prêt à l’emploi est fourni à cet effet à la fin de ce guide.

La migration se déroule selon les phases suivantes :

1. Créer une sauvegarde (dump) de la base de données sur le serveur Windows
2. Préparer le nouveau serveur Linux avec Docker
3. Importer la sauvegarde dans la nouvelle base de données
4. Renommer les noms de tables en majuscules
5. Démarrer Relution et vérifier

Éléments nécessaires avant de commencer #

Les éléments suivants sont nécessaires :

• Un accès au serveur Windows (directement sur site ou via Bureau à distance / RDP)
• Le nom de la base de données Relution – si celui-ci est inconnu, consulter l’administrateur ou le fichier de configuration Relution existant. Le nom est souvent simplement relution.
• Le mot de passe de l’utilisateur de la base de données MariaDB (généralement root ou un utilisateur Relution dédié)
• La version de Relution installée sur le serveur Windows ; elle détermine l’image avec laquelle Relution est démarré pour la première fois sous Docker (voir Phase 2)
• Un serveur Linux doté d’un système d’exploitation pris en charge (Alma Linux ou Rocky Linux 9/10 ou RHEL 9 et versions ultérieures, voir Exigences du système →), sur lequel Docker et Docker Compose sont déjà installés (voir Docker (Recommandé) →)
• Un accès au serveur Linux via SSH (un programme de terminal tel que PuTTY sous Windows ou le terminal intégré sous macOS/Linux)
• Un programme de transfert de fichiers tel que WinSCP → (gratuit), pour copier des fichiers du serveur Windows vers le serveur Linux

Phase 1 – Créer une sauvegarde sur le serveur Windows #

Cette étape crée une copie de sauvegarde complète de la base de données Relution sous forme de fichier SQL. Ce fichier contient l’ensemble des données et sera importé plus tard dans le nouvel environnement.

1.1 Ouvrir l’invite de commandes en tant qu’administrateur #

1. Sur le serveur Windows, appuyer sur la combinaison de touches Windows+R
2. Saisir cmd et appuyer sur Ctrl+Maj+Entrée (pas seulement Entrée) – cela ouvre l’invite de commandes avec les droits administrateur
3. Confirmer la demande de sécurité avec Oui

1.2 Créer le dossier de destination pour la sauvegarde #

Saisir la commande suivante et appuyer sur Entrée :

mkdir C:\backup

Cette commande crée le dossier C:\backup, dans lequel le fichier de sauvegarde sera déposé. Si le dossier existe déjà, un message sans conséquence apparaît et le processus peut être poursuivi.

1.3 Déterminer le chemin de la base de données #

mysqldump est le programme qui crée la sauvegarde. Il se trouve dans le répertoire d’installation de MariaDB. Vérifier quel chemin est correct dans l’environnement concerné :

dir "C:\Program Files\MariaDB*"

Un dossier nommé MariaDB 10.6 ou MariaDB 10.11 apparaît alors, par exemple, directement sous C:\Program Files. Noter le numéro de version exact – il sera nécessaire à l’étape suivante.

1.4 Créer le dump de la base de données #

Avant l’export, le service Relution est arrêté sur le serveur Windows afin qu’aucune donnée ne soit écrite après le dump, données qui manqueraient dans le nouvel environnement :

sc stop relution

Dans la commande suivante, remplacer 10.11 par le numéro de version MariaDB réel et relution par le nom de la base de données, si celui-ci diffère :

"C:\Program Files\MariaDB 10.11\bin\mysqldump.exe" -u root -p --single-transaction --routines --triggers --default-character-set=utf8mb4 --max-allowed-packet=1G relution > C:\backup\relution_dump.sql

Après avoir appuyé sur Entrée, le mot de passe de la base de données est demandé. Le saisir (la saisie est invisible – c’est normal) et appuyer sur Entrée.

Si aucune erreur n’apparaît et que l’invite de commandes normale réapparaît, l’export a réussi.

Brève explication des options utilisées :

1.5 Vérifier la sauvegarde #

Vérifier que le fichier a été correctement créé :

dir C:\backup\relution_dump.sql

Le fichier devrait apparaître avec une taille (généralement plusieurs Mo). Si le fichier a une taille de 0 octet, quelque chose s’est mal passé – exécuter alors à nouveau la commande de l’étape 1.4 et surveiller les messages d’erreur.

1.6 Transférer les fichiers vers le serveur Linux #

Dans WinSCP, une connexion au serveur Linux est établie (adresse IP, nom d’utilisateur et mot de passe) et deux fichiers sont copiés :

Le fichier application.yml contient entre autres l’URL externe du serveur et est réutilisé dans le nouvel environnement. Si Relution se trouve dans un autre répertoire sur le serveur Windows, le fichier se trouve dans le répertoire d’installation correspondant.

Si le dossier /opt/relution/ n’existe pas encore sur le serveur Linux, le créer d’abord (voir Phase 2, étape 2.1).

Phase 2 – Préparer le serveur Linux #

Toutes les commandes suivantes sont exécutées sur le serveur Linux dans un terminal SSH.

2.1 Créer le répertoire de travail #

mkdir -p /opt/relution
cd /opt/relution

La commande mkdir -p crée le dossier et tous les dossiers parents s’ils n’existent pas encore. La commande cd permet ensuite de se déplacer dans ce dossier.

2.2 Créer le fichier Docker Compose #

Docker Compose est une méthode permettant de démarrer et de gérer conjointement plusieurs programmes liés entre eux (ici : base de données + Relution). La configuration est stockée dans un fichier nommé compose.yaml.

Créer le fichier :

nano /opt/relution/compose.yaml

La commande nano ouvre un éditeur de texte simple directement dans le terminal. Y copier l’intégralité du contenu suivant :

version: "3.8"

services:
  mariadb:
    image: mariadb:10.11
    container_name: relution-db
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: <ROOT_PASSWORD>
      MYSQL_DATABASE: relution
      MYSQL_USER: relution
      MYSQL_PASSWORD: <RELUTION_PASSWORD>
    volumes:
      - mariadb_data:/var/lib/mysql
      - ./database.cnf:/etc/mysql/conf.d/database.cnf:ro
    networks:
      - relution-net

  relution:
    image: relution/relution:<VERSION>
    container_name: relution-app
    restart: unless-stopped
    depends_on:
      - mariadb
    ports:
      - "8080:8080"
    environment:
      DATABASE_TYPE: mariadb
      DATABASE_URL: jdbc:mariadb://mariadb:3306/relution?useServerPrepStmts=true
      DATABASE_USER: relution
      DATABASE_PWD: <RELUTION_PASSWORD>
    volumes:
      - ./application.yml:/opt/relution/application.yml
    networks:
      - relution-net

volumes:
  mariadb_data:

networks:
  relution-net:

<VERSION> est remplacé par la version de Relution de l’installation Windows, par exemple relution/relution:26.0.3. Lors du premier démarrage, Relution met à jour la base de données vers la version de l’image ; un tag fixe évite une mise à jour imprévue sur plusieurs versions.

Le port 8080 n’est prévu que pour le premier test ; l’accès depuis l’extérieur se fait ensuite via un proxy inverse avec HTTPS (voir Phase 5).

Enregistrer et fermer le fichier : Ctrl+O (enregistrer), puis Entrée, puis Ctrl+X (quitter).

2.3 Créer la configuration de la base de données #

Le fichier database.cnf définit le jeu de caractères, la collation et la taille maximale des paquets du serveur de base de données, conformément à la configuration standard de Relution :

nano /opt/relution/database.cnf

[mysqld]
collation-server=utf8mb4_general_ci
character-set-server=utf8mb4
max_allowed_packet=1G
innodb_file_per_table=1

La raison principale est max_allowed_packet : Relution peut stocker des fichiers sous forme d’enregistrements uniques dans la base de données. Avec la valeur par défaut de MariaDB (16 Mo), l’import de tels enregistrements échoue. Les paramètres de jeu de caractères et de collation servent de précaution, car les images MariaDB plus récentes utilisent une autre collation par défaut.

Le fichier doit exister avant le premier démarrage du conteneur de base de données (étape 2.5), car la base de données relution n’est créée avec ces paramètres serveur que lors de la première initialisation.

Enregistrer et quitter : Ctrl+O, Entrée, Ctrl+X.

2.4 Adapter le fichier application.yml #

nano /opt/relution/application.yml

Dans le fichier application.yml repris de Windows, la section database sous relution est entièrement supprimée, par exemple :

  database:
    type: mariadb
    url: jdbc:mariadb://localhost/relution?useServerPrepStmts=true
    username: relution
    password: ...

La connexion à la base de données est définie via les variables d’environnement DATABASE_* dans le fichier compose.yaml ; une section database restante serait prioritaire et pointerait toujours vers l’ancienne base de données. Toutes les autres entrées, en particulier externalURL, restent inchangées.

Enregistrer et quitter : Ctrl+O, Entrée, Ctrl+X.

2.5 Démarrer uniquement la base de données #

Seul le conteneur de base de données est démarré pour l’instant – pas encore Relution lui-même. Cela est important pour que Relution, lors de son premier démarrage, ne se trouve pas face à une base de données vide et ne commence à créer ses propres tables (incorrectes).

cd /opt/relution
docker compose up -d mariadb

L’option -d signifie « detached » – le conteneur s’exécute en arrière-plan et ne bloque pas le terminal.

2.6 Attendre que la base de données soit prête #

docker logs -f relution-db

Cette commande affiche les journaux (messages de log) du conteneur de base de données en temps réel. Attendre que le message suivant apparaisse :

[Note] mariadbd: ready for connections.

Dès que ce message est visible, appuyer sur Ctrl+C pour arrêter l’affichage. La base de données continue de s’exécuter en arrière-plan.

Ensuite, la commande suivante vérifie que la configuration de la base de données de l’étape 2.3 est appliquée :

docker exec -it relution-db mariadb \
  -u root -p<ROOT_PASSWORD> \
  -e "SHOW VARIABLES LIKE 'collation_server';"

Le résultat doit contenir utf8mb4_general_ci. Sinon, le fichier database.cnf n’est pas monté ; informations complémentaires sous Illegal mix of collations →.

Phase 3 – Importer la sauvegarde #

Si le fichier dump n’a pas encore été transféré vers le serveur, le faire maintenant (voir Phase 1, étape 1.6).

3.1 Importer le dump dans la base de données #

docker exec -i relution-db mariadb \
  -u root -p<ROOT_PASSWORD> \
  --max-allowed-packet=1G \
  relution < /opt/relution/relution_dump.sql

Brève explication de ce qui se passe ici : docker exec -i relution-db permet d’exécuter une commande à l’intérieur du conteneur de base de données en cours d’exécution. mariadb ... < fichier.sql importe le fichier SQL dans la base de données.

L’import peut prendre plusieurs minutes selon le volume de données. Si aucune erreur n’apparaît et que l’invite normale réapparaît, l’import a réussi.

3.2 Vérifier l’import #

docker exec -it relution-db mariadb \
  -u root -p<ROOT_PASSWORD> \
  relution -e "SHOW TABLES;" | head -30

Cette commande liste les 30 premières tables de la base de données. Des noms de tables familiers devraient apparaître (par ex. databasechangelog, qrtz_triggers, etc.). Si la liste est vide ou qu’un message d’erreur apparaît, répéter la Phase 3.

Phase 4 – Renommer les noms de tables en majuscules #

Comme expliqué au début : Linux distingue les majuscules et les minuscules, Windows non. Sous Linux, Relution attend des noms de tables en majuscules. Cette étape renomme toutes les tables concernées.

Comme il n’est pas possible de renommer directement une table de exemple en EXEMPLE (Linux considère cela comme le même nom), le renommage se déroule en deux passes : d’abord vers des noms temporaires (avec _tmp), puis vers les noms finaux en majuscules.

4.1 Créer le fichier de script #

nano /opt/relution/rename_tables.sql

Copier l’intégralité du contenu suivant dans l’éditeur :

-- ============================================================
-- Étape 1 : renommage vers des noms temporaires (_tmp)
-- ============================================================
RENAME TABLE
  `databasechangelog`         TO `databasechangelog_tmp`,
  `databasechangeloglock`     TO `databasechangeloglock_tmp`,
  `jgroupsping`               TO `jgroupsping_tmp`,
  `qrtz_blob_triggers`        TO `qrtz_blob_triggers_tmp`,
  `qrtz_calendars`            TO `qrtz_calendars_tmp`,
  `qrtz_cron_triggers`        TO `qrtz_cron_triggers_tmp`,
  `qrtz_fired_triggers`       TO `qrtz_fired_triggers_tmp`,
  `qrtz_job_details`          TO `qrtz_job_details_tmp`,
  `qrtz_locks`                TO `qrtz_locks_tmp`,
  `qrtz_paused_trigger_grps`  TO `qrtz_paused_trigger_grps_tmp`,
  `qrtz_scheduler_state`      TO `qrtz_scheduler_state_tmp`,
  `qrtz_simple_triggers`      TO `qrtz_simple_triggers_tmp`,
  `qrtz_simprop_triggers`     TO `qrtz_simprop_triggers_tmp`,
  `qrtz_triggers`             TO `qrtz_triggers_tmp`,
  `scheduler_lock`            TO `scheduler_lock_tmp`;

-- ============================================================
-- Étape 2 : renommage vers les noms finaux en majuscules
-- ============================================================
RENAME TABLE
  `databasechangelog_tmp`         TO `DATABASECHANGELOG`,
  `databasechangeloglock_tmp`     TO `DATABASECHANGELOGLOCK`,
  `jgroupsping_tmp`               TO `JGROUPSPING`,
  `qrtz_blob_triggers_tmp`        TO `QRTZ_BLOB_TRIGGERS`,
  `qrtz_calendars_tmp`            TO `QRTZ_CALENDARS`,
  `qrtz_cron_triggers_tmp`        TO `QRTZ_CRON_TRIGGERS`,
  `qrtz_fired_triggers_tmp`       TO `QRTZ_FIRED_TRIGGERS`,
  `qrtz_job_details_tmp`          TO `QRTZ_JOB_DETAILS`,
  `qrtz_locks_tmp`                TO `QRTZ_LOCKS`,
  `qrtz_paused_trigger_grps_tmp`  TO `QRTZ_PAUSED_TRIGGER_GRPS`,
  `qrtz_scheduler_state_tmp`      TO `QRTZ_SCHEDULER_STATE`,
  `qrtz_simple_triggers_tmp`      TO `QRTZ_SIMPLE_TRIGGERS`,
  `qrtz_simprop_triggers_tmp`     TO `QRTZ_SIMPROP_TRIGGERS`,
  `qrtz_triggers_tmp`             TO `QRTZ_TRIGGERS`,
  `scheduler_lock_tmp`            TO `SCHEDULER_LOCK`;

Enregistrer et quitter : Ctrl+O, Entrée, Ctrl+X.

4.2 Exécuter le script #

docker exec -i relution-db mariadb \
  -u root -p<ROOT_PASSWORD> \
  relution < /opt/relution/rename_tables.sql

Si aucun message d’erreur n’apparaît, le renommage a réussi.

4.3 Vérifier le résultat #

docker exec -it relution-db mariadb \
  -u root -p<ROOT_PASSWORD> \
  relution -e "SHOW TABLES;"

Dans le résultat, des noms de tables en majuscules devraient maintenant apparaître, par exemple :

DATABASECHANGELOG
DATABASECHANGELOGLOCK
JGROUPSPING
QRTZ_BLOB_TRIGGERS
...

Phase 5 – Démarrer Relution #

Dès que la base de données est correctement remplie et préparée, la pile complète est démarrée, y compris Relution :

cd /opt/relution
docker compose up -d

5.1 Observer le démarrage #

docker logs -f relution-app

Suivre la sortie. Lors de son premier démarrage, Relution effectue diverses vérifications de la base de données – cela peut prendre 1 à 3 minutes. Le démarrage a réussi lorsqu’une ligne telle que la suivante apparaît (la ligne commence par un horodatage et le niveau de journalisation) :

Started Main in XX seconds (process running for XX)

Quitter l’affichage des logs avec Ctrl+C.

5.2 Configurer HTTPS #

Relution refuse la connexion via HTTP non chiffré depuis d’autres ordinateurs. L’accès depuis le réseau et pour les appareils nécessite donc un proxy inverse avec TLS. Le fichier Compose ci-dessus ne contient pas de proxy inverse ; le service traefik avec un certificat Let’s Encrypt automatique est ajouté comme décrit sous Docker (Recommandé) →, ou bien nginx avec un certificat selon Certificats SSL - Certbot →.

L’URL externe (externalURL dans le fichier application.yml) reste inchangée, car les appareils sont liés à cette URL. L’enregistrement DNS de cette URL est basculé vers le nouveau serveur Linux.

5.3 Ouvrir Relution dans le navigateur #

Relution est ouvert dans le navigateur via l’URL externe, par exemple https://mdm.example.com.

Problèmes fréquents et solutions #

Table doesn't exist lors de l’exécution du script de renommage Cela signifie que l’import du dump n’était pas complet. Vérifier avec SHOW TABLES; quelles tables manquent et répéter la Phase 3.

Relution ne démarre pas / reste en boucle Consulter les logs : docker logs relution-app. Les causes les plus fréquentes sont des variables DATABASE_* manquantes ou incorrectes ou un mot de passe de base de données incorrect dans le compose.yaml, une section database restante dans le fichier application.yml ou des tables qui n’ont pas encore été correctement renommées. Si An update from version 5 to 26.1+ detected apparaît, l’étape intermédiaire via 5.35.4 et 26.0.3 manque (voir Phase 2, étape 2.2).

Le fichier dump a une taille de 0 octet La commande d’export n’a pas fonctionné. Vérifier le chemin vers mysqldump.exe et le mot de passe de la base de données.

Le port 8080 est déjà utilisé Un autre programme utilise le port 8080. Dans le compose.yaml, modifier la ligne "8080:8080" en, par exemple, "8181:8080", puis accéder à Relution via le port 8181.

WinSCP ne se connecte pas S’assurer que le service SSH est actif sur le serveur Linux (sudo systemctl status sshd) et que le pare-feu autorise le port 22.

Récapitulatif des chemins de fichiers importants #

Prochaines étapes après une migration réussie #

Une fois que Relution fonctionne et que la connexion réussit :

• Vérifier que tous les appareils, utilisateurs et paramètres ont été correctement repris
• Si une version plus ancienne a d’abord été démarrée, mettre ensuite Relution à jour vers la version actuelle, voir Mise à jour →
• S’assurer que des sauvegardes régulières de la base de données (volume mariadb_data ou dump régulier de la base de données) et du fichier application.yml sont en place
• N’éteindre l’ancien serveur Windows qu’une fois que le nouvel environnement a fonctionné de manière stable pendant plusieurs jours