m158/docs/README.md

231 lines
17 KiB
Markdown
Raw Normal View History

2024-07-02 18:35:35 +00:00
# Modul 158: Softwaremigration Planen und Durchführen
## Inhaltsverzeichnis
2024-07-12 14:15:15 +00:00
- [Inhaltsverzeichnis](#inhaltsverzeichnis)
- [Einleitung](#einleitung)
- [Informieren](#informieren)
- [Planen](#planen)
- [Ziele](#ziele)
- [Must-have](#must-have)
- [Nice to have](#nice-to-have)
- [Low priority](#low-priority)
- [To-do](#to-do)
- [Panel](#panel)
- [Wings](#wings)
- [Post-Installation](#post-installation)
- [Migrationsplan](#migrationsplan)
- [Serverressourcen](#serverressourcen)
- [Entscheiden](#entscheiden)
- [Neue Zeitplanung](#neue-zeitplanung)
- [Realisieren](#realisieren)
- [Planänderung](#planänderung)
- [Kontrollieren](#kontrollieren)
- [Testen](#testen)
- [Auswerten](#auswerten)
- [Aleksander](#aleksander)
- [Milena](#milena)
- [Stelian](#stelian)
2024-07-02 18:35:35 +00:00
## Einleitung
Das ist die Dokumentation für die Migration von einem Pterodactyl Panel von einem alten Server auf einen neuen.<br>
Es wird von einem Netcup vServer zu einem Hetzner Dedicated Server migriert. Diese Migration entspricht also nicht nur einem Hardware- sondern auch einem Anbieterwechsel.
## Informieren
## Planen
Damit die Migration von dem Pterodactyl Gameserver Panel reibungslos verläuft, sollten wir am besten einige Ziele und Zeitpläne festlegen. So kann am effizientesten gearbeitet werden.
### Ziele
#### Must-have
- [ ] Minecraft Server 100% migriert (inkl. save data)
2024-07-10 21:05:38 +00:00
- [x] Funktionelles Wings Backend
- [x] Virtualisiertes Wings & Panel
2024-07-05 13:55:04 +00:00
- [x] Reverse Proxy
2024-07-10 21:05:38 +00:00
- [x] 2FA
2024-07-02 18:35:35 +00:00
#### Nice to have
2024-07-11 20:16:49 +00:00
- [ ] Virtualisiertes Wings Panel mit dedizierter IP Adresse
2024-07-02 18:35:35 +00:00
#### Low priority
2024-07-10 21:05:38 +00:00
- [ ] Backups
2024-07-02 18:35:35 +00:00
### To-do
#### Panel
2024-07-05 13:55:04 +00:00
- [x] Setup LXC CT
- [x] Check if all dependecies are met (PHP, MYSQL, etc...)
- [x] Download extra pterodactyl files
- [x] Database Setup
- [x] Crontab configurations
- [x] Configure Reverse Proxy
2024-07-02 18:35:35 +00:00
#### Wings
2024-07-05 13:55:04 +00:00
- [x] Setup VM
- [x] Check if all dependencies are met. (`curl`, `docker`)
2024-07-10 21:05:38 +00:00
- [x] Download and Configure Wings
2024-07-02 18:35:35 +00:00
#### Post-Installation
- [ ] Add new host as a node to the old host
- [ ] Transfer server eggs
- [ ] Delete the old host from the new host
### Migrationsplan
2024-07-12 11:39:48 +00:00
![migration plan](../assets/migration-plan-new.png)
2024-07-02 18:35:35 +00:00
### Serverressourcen
Damit die Migration so flüssig wie möglich verlaufen kann, muss man garantieren, dass der neue Server genau so viel (oder mehr) Ressourcen wie der letzte hat. Natürlich kann man das auch anders lösen, was dann in einem Fall wie im Runterskalieren besser wäre.
2024-07-04 17:40:47 +00:00
In unserem Fall aber haben wir Gameserver, die migriert werden müssen, die man schlecht downscalen kann. Man müsste deren Welten und Mods modifizieren, was auf keinem Fall passieren darf, da das zu Korruption im bestehenden Spielstand führen kann. Heisst, wir brauchen gleich viel oder mehr Hardwareressourcen.<br>
In einer robusteren Umgebung könnte man auch mehrere kleine Server zu einem Wings-Cluster bilden. Da wären mind. 3 Server ideal.
Hier haben wir aber nur einen Server zur Verfügung, also müssen wir keine Cluster erstellen. Das würde sich nicht lohnen.
Folgendes sind die Serverresourcen von den zwei Hosts:
`@netcup` (alter Server, panel.sangelo.space):
| Hardware | Specs |
| ----------- | ------------------------------------------------------------ |
| **CPU** | Host: AMD EPYC 7702P<br>VPS: 10 vCores @ 2GHz, max. 3.35 GHz |
| **RAM** | 32 GB |
| **Storage** | 1TB VHD on SSD |
| **OS** | Debian 11 + YunoHost |
`@kubelo` (neuer Server, lunivity.com):
| Hardware | Specs |
| ----------- | ---------------------------------------------------------------------------------------- |
| **CPU** | Intel Xeon E3-1275 v6<br>4 Cores, 8 Threads @ 3.80GHz |
| **RAM** | 64 GB |
| **Storage** | 2x Samsung SM963 512 GB<br>1x Samsung PM9A1/PM9A3/980PRO 512 GB<br>Usable: 1 TB (RAID 5) |
| **OS** | Proxmox 8.1.4 |
Wie man sieht, hat der neue Server zwar weniger nutzbare Cores/Threads, dafür aber hat er doppelt so viel RAM wie der Letzte.<br>
Der Grossteil der Gameserver, die migriert werden, sind Minecraft Server. Dieses Spiel ist dafür bekannt, single-threaded zu laufen und RAM-hungrig zu sein.
Es werden nicht alle Server gleichzeitig laufen, maximal einen oder zwei aufs Mal. Das heisst, dass CPU in diesem Fall kein grosses Downgrade sein sollte, und fast unbemerkbar ist. Die höhere Clockspeed der CPU vom neuen Server wäre sogar ein Upgrade in einigen Bereichen vom Spiel.
Bezüglich RAM ist mein jetziger Fussabdruck auf dem `@kubelo` Node noch nicht zu gross, also sollte für die Wings-VM 20GB oder sogar 32GB gut möglich sein. Das würde ich in Zukunft wenn nötig entweder runterskalieren (und im Endeffekt einfach weniger Gameserver parallel online halten), oder ich würde dann mehr RAM einbauen.
2024-07-02 18:35:35 +00:00
## Entscheiden
Dieses Kapitel dient zur Zeiteinteilung, wir *entscheiden*, wer was wann macht. Unten ist eine Tabelle die das genau einteilt und einplant.
2024-07-04 16:23:53 +00:00
| Aufgabe | Tag | Zeiteinschätzung | Wer? |
| ------------------------------ | --- | ----------------------------- | ------------------ |
| **<u>Panel</u>** | | **-h** | |
| Setup LXC Container | 4 | 30min | Stelian |
| Docker Image erstellen | 4 | 5h (mit Troubleshooting) | Milena |
| Deployment Panel | 5 | 1.5h | Aleksander |
| Reverse Proxy | 5 | 20min | Aleksander |
| 2FA | 5 | 5min | Stelian |
| **<u>Wings</u>** | | **-h** | |
| Setup VM | 4 | 1h | Stelian |
| Installation Wings | 6 | 2.5h | Milena |
| Daemonizing | 6 | 30min | Stelian |
| **<u>Gameservermigration</u>** | | **3h + 5h (server-transfer)** | |
| Vom alten Node migrieren | 5-6 | 5h (im Hintergrund) | Stelian |
| Gameserver testen | 6 | 2h | Aleksander |
| Altes Node auflösen | 7 | 1h | Milena |
| **<u>Restliche Sachen</u>** | | | |
| Dokumentation | - | 5h | Aleksander, Milena |
| **<u>Total</u>** | | **-h** | |
2024-07-02 18:35:35 +00:00
2024-07-12 12:29:12 +00:00
### Neue Zeitplanung
| Aufgabe | Tag | Zeiteinschätzung | Wer? |
| ------------------------------------ | --- | ----------------------------- | ------------------ |
| **<u>Panel</u>** | | **-h** | |
| Setup LXC Container | 4 | 30min | Stelian |
| Docker Image erstellen | 4 | 5h (mit Troubleshooting) | Milena |
| Deployment Panel | 5 | 1.5h | Aleksander |
| Reverse Proxy | 5 | 20min | Aleksander |
| 2FA | 5 | 5min | Stelian |
| **<u>Wings</u>** | | **-h** | |
| Setup VM | 4 | 1h | Stelian |
| Installation Wings | 6 | 2.5h | Milena |
| Daemonizing | 6 | 30min | Stelian |
| **<u>Gameservermigration</u>** | | **3h + 5h (server-transfer)** | |
| alte Server kopieren und migrieren | 5-6 | 5h | Stelian |
| Gameserver testen | 6 | 2h | Aleksander |
| Altes Node auflösen | 7 | 1h | Milena |
| **<u>Restliche Sachen</u>** | | | |
| Dokumentation | - | 5h | Aleksander, Milena |
| **<u>Total</u>** | | **-h** | |
2024-07-02 18:35:35 +00:00
## Realisieren
2024-07-04 16:23:53 +00:00
Dieser Teil der Dokumentation wurde zur Lesbarkeit in verschiedene Dateien aufgeteilt. Folgend ist eine Liste mit diesen Kapiteln.
TODO: update this table of contents once docs are finished
- [Panel](panel/)
- [Setup LXC Container](panel/README.md#setup-lxc-container)
- [Docker Image erstellen](panel/README.md#docker-image-erstellen)
- [Deployment Panel](panel/README.md#deployment-vom-panel)
- [2FA](panel/README.md#2fa)
- [Wings](wings/)
- [Setup VM](wings/README.md#setup-vm)
- [Installation Wings](wings/README.md#installation-wings)
- [Daemonizing](wings/README.md#daemonizing)
- [Gameservermigration](migration/)
- [Vom alten Node migrieren](migration/README.md#vom-alten-node-migrieren)
- [Altes Node auflösen](migration/README.md#altes-node-auflösen)
2024-07-12 12:29:12 +00:00
### Planänderung
Als wir bei der Migration der einzelnen Gameserver angelangt sind, haben wir gemerkt, dass unsere ursprüngliche Überlegung zur Migration nicht funktionieren wird. Die Metadata der Server, also die Konfigurationen, werden jeweils in der MariaDB des Panels gespeichert und wir wollen das Panel nicht migrieren, da wir denken dass sich die Panelmigration wenig lohnt. Diese hat (zumindest in der Version auf dem alten Server) sehr viel Hard-coded Werte hat.<br>
Unser neuer Plan war auf der neuen Node "Skelettserver" zu erstellen, bei denen wir manuell die gleiche Konfiguration einrichten. Danach wollen wir manuell die Volumes der neuen Gameserver durch die der alten austauschen. Diese Methode könnte zuerst komplizieter tönen, aber im Endeffekt dauert es weniger als manuell Datenbankwerte zu finden und richtig zu updaten.
Wir haben diese Problematik leider zu spät realisiert und mussten deswegen die schwierige Entscheidung treffen, das Migrationsprojekt nach dem Modulabschluss zu beenden.
2024-07-02 18:35:35 +00:00
## Kontrollieren
### Testen
2024-07-11 20:16:49 +00:00
| ID | Testaspekte | Testbeschreibung | Erwartetes Resultat | Tatsächliches Resultat |
|-----|-----------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------|
| 1.1 | Panel (Admin), Reverse Proxy, 2FA | Der Zugriff auf das Panel mit einem Administratorenkonto soll versucht werden. | Der Zugriff sollte problemlos funktioneren und es sollte nach dem OTP fragen. Zusätzlich sollten alle Administratorfunktionen verfügbar sein. | |
| 1.2 | Panel (non Admin), Reverse Proxy, 2FA | Der Zugriff auf das Panel mit einem normalen Konto soll versucht werden. | Der Zugriff sollte problemlos funktionieren und es sollte nach dem OTP fragen. Zusätzlich sollten keine Administratorfunktionen verfügbar sein. | |
| 2.1 | Wings als Backend, Reverse Proxy | Der Zugriff auf Wings sollte nur über das Panel funktionieren. Im Browser soll man den Namen von Wings aufrufen. | ```$ curl https://nest.sangelo.space:2080 {"error":"The required authorization heads were not present in the request."}``` | ```[milena@mb-laptop ~]$ curl https://nest.sangelo.space:2080 {"error":"The required authorization heads were not present in the request."}``` |
| 2.2 | Wings als Backend, Reverse Proxy | Der Zugriff auf Wings sollte nur über das Panel funktionieren. Im Panel soll man kontrollieren, ob die Node verbunden ist. | Im Panel sollte die Node auffindbar sein. | |
| 2.3 | Wings als Backend, dedizierte IPv4 | Wings sollte über die dedizierte IPv4-Adresse mit curl antworten. | ```$ curl http://167.235.4.32:2080 Client sent an HTTP request to an HTTPS server.``` | ```[milena@mb-laptop ~]$ curl http://167.235.4.32:2080 Client sent an HTTP request to an HTTPS server.``` |
| 2.4 | Minecraft Server, Reverse Proxy | Der Zugriff auf Wings sollte über einen Game Launcher funktionieren. In einem Minecraft Launcher sollte man den Namen von Wings aufrufen. | Es sollte ein Minecraft Server auffrufbar sein unter dem Namen von Wings. | |
| 3.1 | Minecraft Server, Migration | Die fehlerfreie Übertragung der Minecraft Welten sollte erfolgreich abgeschlossen sein. Mit einem Laden einer ausgewählten Welt kann dies nachvollzogen werden. | Die übertragenen Welten des Minecraft Servers sollten ohne Schaden migriert sein. | |
2024-07-11 07:57:20 +00:00
2024-07-02 18:35:35 +00:00
## Auswerten
2024-07-12 12:47:40 +00:00
Wir haben unserer Meinung nach bei diesem Projekt sehr viel erreicht. Die Planung verlief sehr gut und wir haben Wege gefunden die Arbeit gut aufzuteilen, was wir uns zu Beginn schwieriger vorgestellt haben. Wir hatten jeweils ein gutes Fortschrittstempo, wenn wir gearbeitet haben und hatten selten Probleme, ausser das eine grosse.
Die Theorieblöcke waren für uns nicht viel neues, aber es war eine gute Repetition für dieses Projekt.
### Aleksander
2024-07-12 12:53:04 +00:00
Ich fand dieses Projekt ziemlich interessant da ich schon an mehreren von Stelian Server beteiligt war und mich schon öfters gewundert habe wie es im Hintergrund aussieht. Etwas was ziemlich anders war im gegensatz zu anderen Modulen, war das wir keine genaue Anweisungen hatten und die Probleme die uns über den weg gekommen sind selber lösen mussten und oft selber brainstormen. Ich denke auch das ich viel gelernt habe und vieles ganz gut elredigen konnte.
2024-07-12 12:47:40 +00:00
### Milena
2024-07-12 14:15:15 +00:00
Das Projekt war sehr interessant für mich, da wir keine genauen Anweisungen haben und selbst einen Lösungsweg finden mussten. Meiner Meinung nach haben wir uns sehr gut geschlagen und haben auch gute Überlegungen gemacht. Ich konnte meine Teile des Projekts gut erledigen. Wir haben noch sehr viel mehr Zeit als in der Zeitplanung verwendet, was mich nicht überrascht hat. Meistens mussten wir einfach viel besprechen und unser vorgehen vergleichen.
2024-07-12 13:00:15 +00:00
Ich bin zufrieden mit meiner Leistung, auch wenn wir das Projekt nicht auf die geplant umsetzen konnten. Die Erfahrung war sehr interessant und ich fühle mich nun besser auf solche Migrationsprojekte vorbereitet, da ich den Planungsablauf nun kenne.
2024-07-12 12:47:40 +00:00
2024-07-12 14:15:15 +00:00
### Stelian
Für mich war dieses Projekt eine perfekte Möglichkeit, endlich mal einen meiner letzten Services zu meinem neuen Server zu migrieren, da meine gesetzte Frist längst um ist.<br>
Diese Migration ist auch einer der am besten verlaufenden gewesen, eine die am wenigsten Probleme gemacht hat.<br>
Ich finde ich habe eine gute Leistung geleistet, vor allem wenn man unseren Zeitdruck in anderen Modulen und Fächern miteinberechnet. Das beiseite aber finde ich ist dieses Projekt gut gelungen, und ich bin sehr zufrieden damit.