docs: Add recommended migration plan to RELOCATION.md [30388f42]
This commit updates the RELOCATION.md file to include a detailed, safer migration plan as a recommended alternative to the initial proposal. This provides a clear and secure strategy for the discussion with the IT department.
This commit is contained in:
@@ -59,3 +59,72 @@ Die VM muss in der Lage sein, ausgehende Verbindungen zu den folgenden externen
|
|||||||
1. **Firewall-Regeln (eingehend):** Bitte öffnen Sie die Ports `3000`, `2222`, `8090`, `8003`, `8501`, `8004`, `8002` und `5173` für die Ziel-IP `10.10.81.2`.
|
1. **Firewall-Regeln (eingehend):** Bitte öffnen Sie die Ports `3000`, `2222`, `8090`, `8003`, `8501`, `8004`, `8002` und `5173` für die Ziel-IP `10.10.81.2`.
|
||||||
2. **Firewall-Regeln (ausgehend):** Stellen Sie sicher, dass die VM ausgehende HTTPS-Verbindungen (Port 443) zu beliebigen Zielen im Internet aufbauen kann.
|
2. **Firewall-Regeln (ausgehend):** Stellen Sie sicher, dass die VM ausgehende HTTPS-Verbindungen (Port 443) zu beliebigen Zielen im Internet aufbauen kann.
|
||||||
3. **Reverse Proxy (Optional, aber empfohlen):** Planen Sie die Einrichtung eines Reverse Proxys (z.B. Nginx, Traefik) mit SSL-Zertifikaten für den Zugriff auf die Web-Anwendungen, insbesondere für den Haupt-Port `8090`.
|
3. **Reverse Proxy (Optional, aber empfohlen):** Planen Sie die Einrichtung eines Reverse Proxys (z.B. Nginx, Traefik) mit SSL-Zertifikaten für den Zugriff auf die Web-Anwendungen, insbesondere für den Haupt-Port `8090`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### **Anhang: Migrationsvorschlag der IT**
|
||||||
|
|
||||||
|
Das Folgende ist der initial vorgeschlagene Migrationsprozess seitens der IT.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Auf dem Quellsystem (Synology)
|
||||||
|
cd /volume1/homes/Floke/python
|
||||||
|
tar czf lead-engine-app.tgz brancheneinstufung/
|
||||||
|
|
||||||
|
docker images
|
||||||
|
docker save <image-name>:<tag> > lead-engine-image.tar
|
||||||
|
|
||||||
|
# Manuelle Übertragung via USB-Stick
|
||||||
|
|
||||||
|
# Auf dem Zielsystem (docker1)
|
||||||
|
docker load < lead-engine-image.tar
|
||||||
|
mkdir -p /srv/lead-engine
|
||||||
|
tar xzf lead-engine-app.tgz -C /srv/lead-engine
|
||||||
|
|
||||||
|
# Und starten
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### **Empfohlener Migrationsplan (Sicherer Ansatz)**
|
||||||
|
|
||||||
|
Der Vorschlag der IT ist für einen einzelnen, einfachen Container geeignet, birgt jedoch für diesen komplexen Anwendungs-Stack erhebliche Risiken (Datenverlust, Konfigurationsfehler). Ein sicherer Umzug muss zwingend **Code, Konfiguration UND persistente Daten** umfassen.
|
||||||
|
|
||||||
|
**Analyse der Risiken des IT-Vorschlags:**
|
||||||
|
1. **Fokus auf nur einen Container:** Der Plan berücksichtigt nur die `lead-engine`, ignoriert aber die ca. 20 anderen, voneinander abhängigen Dienste (Gitea, Datenbanken, Proxy etc.).
|
||||||
|
2. **Fehlende persistente Daten (Größtes Risiko):** Der Plan sichert nur den Anwendungs-Code. Er ignoriert die Daten-Volumes, was zum **Totalverlust aller Git-Repositories, Datenbankinhalte und anderer kritischer Daten** führen würde.
|
||||||
|
3. **Fehlende Orchestrierung:** Die `docker-compose.yml`, das "Gehirn" des Systems, wird ignoriert. Ohne sie ist ein Starten des komplexen Stacks nicht möglich, da alle Netzwerk-Verbindungen, Port-Mappings und Volume-Zuweisungen fehlen.
|
||||||
|
|
||||||
|
**Der empfohlene, sichere Prozess:**
|
||||||
|
|
||||||
|
Der korrekte Ansatz ist, das gesamte Projektverzeichnis zu archivieren, welches alle drei Säulen (Code, Konfiguration, Daten) enthält.
|
||||||
|
|
||||||
|
**Schritt 1: Ein vollständiges Archiv auf dem Quellsystem erstellen**
|
||||||
|
Anstatt nur einen Dienst zu sichern, wird das gesamte Projekt-Stammverzeichnis, das alle Docker-Konfigurationen und Daten-Volumes enthält, als einzelnes Archiv (`.tar.gz`) zusammengefasst.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Beispielhafter Befehl im übergeordneten Verzeichnis
|
||||||
|
# Der genaue Pfad und Name muss vor der Ausführung verifiziert werden.
|
||||||
|
tar czf GTM_ENGINE_MIGRATION_ARCHIVE.tar.gz ./DEIN_PROJEKT_ORDNER/
|
||||||
|
```
|
||||||
|
|
||||||
|
Dieses Archiv enthält:
|
||||||
|
- Den gesamten Quellcode aller Dienste.
|
||||||
|
- Die zentrale `docker-compose.yml`.
|
||||||
|
- Alle `.env`-Dateien mit API-Schlüsseln und Secrets.
|
||||||
|
- **Alle lokalen Daten-Volumes** (z.B. `./postgres:/var/lib/postgresql/data`, `./gitea:/data`, etc.), die in der `docker-compose.yml` definiert sind.
|
||||||
|
|
||||||
|
**Schritt 2: Archiv auf das Zielsystem übertragen**
|
||||||
|
Die erstellte Archivdatei (`GTM_ENGINE_MIGRATION_ARCHIVE.tar.gz`) wird auf die neue VM `docker1` übertragen (z.B. via `scp` oder `rsync`).
|
||||||
|
|
||||||
|
**Schritt 3: Auf dem Zielsystem wiederherstellen und starten**
|
||||||
|
Auf der neuen VM sind nur zwei Befehle nötig:
|
||||||
|
```bash
|
||||||
|
# 1. Archiv entpacken
|
||||||
|
tar xzf GTM_ENGINE_MIGRATION_ARCHIVE.tar.gz
|
||||||
|
|
||||||
|
# 2. Den kompletten Stack starten
|
||||||
|
cd DEIN_PROJEKT_ORDNER/
|
||||||
|
docker compose up -d
|
||||||
|
```
|
||||||
|
Docker Compose wird die Konfiguration lesen, alle Dienste mit ihren Daten und Netzwerk-Verbindungen korrekt starten und den Zustand des Quellsystems exakt replizieren.
|
||||||
|
|||||||
Reference in New Issue
Block a user