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 #

S’assurer de disposer des éléments suivants :

• 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é)
• Un serveur Linux (Ubuntu 22.04 ou 24.04 recommandé) sur lequel Docker et Docker Compose sont déjà installés
• 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 – il suffit de continuer.

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. 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 #

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\MariaDB 10.11\bin\mysqldump.exe" -u root -p --single-transaction --routines --triggers --default-character-set=utf8mb4 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 le fichier de sauvegarde vers le serveur Linux #

Ouvrir WinSCP, se connecter au serveur Linux (adresse IP, nom d’utilisateur et mot de passe) et copier le fichier :

• Source (Windows) : C:\backup\relution_dump.sql
• Destination (Linux) : /opt/relution/relution_dump.sql

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é docker-compose.yml.

Créer le fichier :

nano /opt/relution/docker-compose.yml

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: HIER_ROOT_PASSWORT_EINSETZEN
      MYSQL_DATABASE: relution
      MYSQL_USER: relution
      MYSQL_PASSWORD: HIER_RELUTION_PASSWORT_EINSETZEN
    volumes:
      - mariadb_data:/var/lib/mysql
    networks:
      - relution-net

  relution:
    image: relution/relution:latest
    container_name: relution-app
    restart: unless-stopped
    depends_on:
      - mariadb
    ports:
      - "8080:8080"
      - "8443:8443"
    environment:
      DB_HOST: mariadb
      DB_PORT: 3306
      DB_NAME: relution
      DB_USER: relution
      DB_PASSWORD: HIER_RELUTION_PASSWORT_EINSETZEN
    volumes:
      - relution_data:/opt/relution/data
    networks:
      - relution-net

volumes:
  mariadb_data:
  relution_data:

networks:
  relution-net:

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

2.3 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.4 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.

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 -pHIER_ROOT_PASSWORT_EINSETZEN \
  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 -pHIER_ROOT_PASSWORT_EINSETZEN \
  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 beispiel en BEISPIEL (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 :

-- ============================================================
-- Schritt 1: Umbenennen zu temporären Namen (_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`;

-- ============================================================
-- Schritt 2: Umbenennen zu finalen Großbuchstaben-Namen
-- ============================================================
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 -pHIER_ROOT_PASSWORT_EINSETZEN \
  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 -pHIER_ROOT_PASSWORT_EINSETZEN \
  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 #

Maintenant que la base de données est correctement remplie et préparée, la pile complète peut être 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’un message tel que le suivant apparaît :

Started Relution in XX seconds

Quitter l’affichage des logs avec Ctrl + C.

5.2 Ouvrir Relution dans le navigateur #

Ouvrir un navigateur et accéder à Relution :

http://IP-ADRESSE-DES-SERVERS:8080

Remplacer IP-ADRESSE-DES-SERVERS par l’adresse IP réelle du serveur Linux.

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 un mot de passe de base de données incorrect dans le docker-compose.yml ou des tables qui n’ont pas encore été correctement renommées.

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 docker-compose.yml, 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 ssh) 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
• Mettre en place un certificat SSL (HTTPS) si ce n’est pas déjà le cas – guide : Configurer un certificat SSL →
• S’assurer que des sauvegardes régulières des volumes Docker 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