Table of Contents

Romexis-Migrationsdienst

Vorgesehener Migrationsablauf
Warum SFTP statt Flask-Uploads?
Projektstruktur
Schnellstart
Erwartetes Upload-Layout
Manifest
Aktueller Stand
Aktuelle Implementierungsänderung
Serverseitige Manifest-Erstellung
Koordination des Romexis-Neustarts
Entwicklungshinweise

Romexis-Migrationsdienst

Dieser Container ist ein Migrationshilfsdienst, mit dem eine vorhandene Windows-basierte Planmeca-Romexis-Installation in den Docker-basierten Romexis-Server-Stack migriert wird.

Flask-Web-UI / REST-API für Migrationsverwaltung, Status, Validierung und Wiederherstellungsorchestrierung
SFTP-Upload-Endpunkt für große Dateien und Verzeichnisbäume
Manifest-basierte Migrationsjobs zur Beschreibung der übertragenen Daten
Wiederherstellungs-Hooks für die Wiederherstellung der SQL-Server-Datenbank und die abschließende Datenplatzierung

Der Dienst startet, stellt eine Web-UI bereit, erstellt Migrationsjobs, stellt Upload-Zugangsdaten pro Job bereit, nimmt Uploads über SFTP an und zeigt den Migrationszustand an.

Vorgesehener Migrationsablauf

Existing Windows Romexis Installation
    |
    | 1. Create SQL Server .bak backup
    | 2. Collect Romexis data directories
    | 3. Generate manifest.json
    | 4. Upload via SFTP/rclone/WinSCP
    v
Romexis Migration Service
    |
    | 5. Validate uploaded files
    | 6. Stop Romexis container
    | 7. Restore SQL backup
    | 8. Move data directories into target volumes
    | 9. Start Romexis container
    v
Docker-based Romexis Server

Warum SFTP statt Flask-Uploads?

Romexis-Bildarchive können sehr groß werden. Ein reiner Flask-Upload-Ansatz würde eine besondere Behandlung erfordern für:

Upload-Zeitüberschreitungen
unterbrochene Übertragungen
Unterstützung zur Wiederaufnahme
Fortschrittsverfolgung
große Dateimengen
große einzelne .bak-Dateien

SFTP eignet sich besser für diese Aufgabe, da es von vielen ausgereiften Werkzeugen unterstützt wird:

rclone (bevorzugtes Werkzeug)
WinSCP
FileZilla
OpenSSH sftp
PowerShell/OpenSSH
Automatisierungsskripte

Die Webanwendung bleibt für Orchestrierung, Status und Wiederherstellungsaktionen zuständig.

Projektstruktur

.
├── migration-service/
│   ├── Dockerfile
│   ├── requirements.txt
│   ├── entrypoint.sh
│   ├── app/
│   │   ├── app.py
│   │   ├── core/
│   │   │   ├── config.py
│   │   │   ├── migrations.py
│   │   │   └── sftp_users.py
│   │   ├── templates/
│   │   │   ├── base.html
│   │   │   ├── index.html
│   │   │   ├── migration.html
│   │   │   └── new_migration.html
│   │   └── static/
│   │       └── style.css
│   ├── scripts/
│   │   ├── restore-migration.sh
│   │   └── validate-migration.sh
│   └── ssh/
│       └── sshd_config
│
├── migration-client/
│   └── romexis_migration_client.py
│
└── docs/
    ├── examples/
    │   └── manifest.example.json
    ├── MIGRATION_WORKFLOW.md
    └── SECURITY.md

Schnellstart

Migrationsdienst bauen und starten:

docker compose -f docker-compose.migration.yml up -d --build

Web-UI öffnen:

http://localhost:8080

SFTP-Endpunkt:

localhost:2222

Erstelle eine Migration in der Web-UI. Der Dienst erzeugt:

Migrations-ID
SFTP-Benutzername
SFTP-Passwort
Upload-Pfad

Lade anschließend Dateien in das Migrationsverzeichnis hoch.

Erwartetes Upload-Layout

Jede Migration erhält ihr eigenes Eingangsverzeichnis:

/incoming/<migration-id>/
├── manifest.json
├── database/
│   └── Romexis_db.bak
├── romexis_images/
│   └── ...
├── romexis_ergodata/
│   └── ...
└── romexis_cache/
    └── ...     # optional

Das Cache-Verzeichnis ist optional und kann normalerweise ausgelassen werden.

Manifest

Die Datei manifest.json beschreibt die übertragenen Daten.

Beispiel:

{
  "source": {
    "hostname": "old-romexis-server",
    "romexis_version": "6.5.3",
    "database_name": "Romexis_db"
  },
  "backup": {
    "file": "database/Romexis_db.bak"
  },
  "data": {
    "images": "romexis_images",
    "ergodata": "romexis_ergodata",
    "cache": null
  }
}

Ein vollständiges Beispiel ist enthalten in:

examples/manifest.example.json

Aktueller Stand

Implementiert:

Flask-Web-UI
REST-API
Erstellung von Migrationsjobs
als JSON-Dateien gespeicherter Migrationszustand
erzeugte Zugangsdaten pro Migration
SFTP-Server im selben Container
Vorbereitung des Upload-Verzeichnisses
Validierungs-Hook
SQL-Server-Wiederherstellung
Python-Client

Noch nicht vollständig implementiert:

koordinierter Romexis-Neustart über eine gemeinsame Zustandsdatei
Prüfsummenvalidierung
Fortschrittsaggregation
Authentifizierung für die Web-UI
produktionsreife Benutzerisolation

Diese Bestandteile sind bewusst getrennt, damit sie schrittweise implementiert und getestet werden können.

Aktuelle Implementierungsänderung

Der Migrationsdienst unterstützt jetzt sowohl Client-gesteuerte als auch manuelle browserbasierte Migrationen.

Implementierter Workflow:

Migrationsjob erstellen.
Datenbanksicherung über die Web-UI oder den Client-Workflow hochladen.
manifest.json auf dem Server erzeugen.
Datenbanksicherung wiederherstellen.
romexis_images, romexis_ergodata und optional romexis_cache über SFTP hochladen.
Abschluss des Uploads bestätigen.
Upload validieren.
Wiederherstellungsworkflow ausführen.
Romexis-Neustart über die gemeinsame Zustandsdatei anfordern.
Migration abschließen und temporären SFTP-Zugriff entfernen.

Zusätzlich unterstützte Operation:

Migration abbrechen und temporären SFTP-Benutzer entfernen

Endzustände wie completed, cancelled und failed erstellen nach einem Neustart des Dienstes keine SFTP-Benutzer erneut.

Serverseitige Manifest-Erstellung

Der Server besitzt das Manifest-Format. Clients und Web-UI sollten ausschließlich Parameter übermitteln.

Das Wiederherstellungsskript erwartet:

{
  "backup": {
    "file": "database/Romexis_db.bak"
  }
}

Bei manuellen Uploads wird das Manifest automatisch erzeugt, nachdem die Datenbanksicherung über die Web-UI hochgeladen wurde.

Koordination des Romexis-Neustarts

Nach einer erfolgreichen Datenbankwiederherstellung kann der Migrationsdienst einen Romexis-Neustart anfordern über:

/data/romexis_images/.romexis_restart_state

Der Romexis-Entrypoint überwacht diese Zustandsdatei, startet den Romexis-Prozess neu und schreibt das Ergebnis zurück. Der Migrationsdienst liest das Ergebnis, protokolliert es und entfernt die Zustandsdatei.

Entwicklungshinweise

Die aktuelle Implementierung ist als praktische Grundlage ausgelegt. Sie hält den Übertragungsweg für große Dateien unabhängig von der Webanwendung und ermöglicht, Migrationsworkflows schrittweise zu testen.

Nächste Schritte: