Umstieg von CloudNet, TimoCloud und SimpleCloud
Ein bestehendes CloudNet-4-, TimoCloud- oder SimpleCloud-Netzwerk mit einem Befehl auf MuteCloud umziehen, ohne die alte Installation anzufassen.
MuteCloud liest eine Installation von CloudNet 4, TimoCloud 5 oder 6 oder selbst gehostetem SimpleCloud 3 ein und übernimmt sie, ohne sie zu verändern. Um welches System es sich handelt, erkennt der Befehl selbst.
./mutecloud migrate --from /opt/cloudnet --dry-run
./mutecloud migrate --from /opt/cloudnet--dry-run zeigt, was übernommen würde, ohne etwas zu ändern. Die Migration liest nur, die
bestehende Installation bleibt vollständig erhalten und lauffähig.
CloudNet
| CloudNet | MuteCloud |
|---|---|
local/tasks/*.json | Gruppen unter groups/ |
local/groups/*.json | zusätzliche Vorlagen pro Gruppe |
local/templates/... | Vorlagen unter layers/ |
local/services/... | Arbeitsverzeichnisse dauerhafter Server unter static/ |
| SyncProxy-Konfiguration | MOTD, Tablist und Wartung in network.toml |
| Bridge-Konfiguration | Fallback-Gruppe, also fallback |
Die Ports werden auseinandergezogen, damit nichts kollidiert. Der Weiterleitungsmodus zwischen Proxy und Servern richtet sich nach der ältesten Version im Netzwerk, und eine eigene Server-Jar bleibt erhalten, wenn CloudNet eine verwendet hat.
TimoCloud
--from zeigt auf den Ordner, der core und base enthält, oder direkt auf core.
| TimoCloud | MuteCloud |
|---|---|
core/configs/serverGroups.json | Server-Gruppen unter groups/ |
core/configs/proxyGroups.json | Proxy-Gruppe, MOTD und Spielerzahl in network.toml |
core/templates/server/Global, proxy/Global | Vorlagen global-server und global-proxy |
core/templates/server/<Group>_<Map> | Vorlage <group>-<map>, die erste ist aktiv |
base/static/server/<Group> | dauerhafter Server <Group>-1 unter static/ |
bases.json oder ram der Base | Speicherpool |
fallbackGroup des TimoCloud-Plugins | Fallback-Gruppe |
Die Java-Parameter, die TimoCloud von sich aus setzt, fallen weg, eigene werden übernommen. Aus einem BungeeCord-Proxy wird Velocity.
Die Felder einer Server-Gruppe werden so übertragen:
| TimoCloud | MuteCloud |
|---|---|
online-amount | scale.min und scale.keep_free |
max-amount | scale.max, das Vierfache von online-amount, wenn es keine Grenze gibt |
ram | memory |
static | persistent, also ein dauerhafter Server |
javaParameters | jvm_flags |
Bei Proxy-Gruppen ergibt sich die Zahl der Proxys aus max-players geteilt durch
players-per-proxy, mindestens aber min-amount. MOTD und Spielerzahl der ersten Proxy-Gruppe
gelten dann für das ganze Netzwerk. Weitere Proxy-Gruppen behalten ihre Einstellungen, aber nicht
ihre MOTD.
Hat eine Gruppe mehrere Maps, also Vorlagen wie BedWars_Desert und BedWars_Ice, wechselt
TimoCloud reihum zwischen ihnen. MuteCloud übernimmt sie alle als eigene Vorlagen, aktiviert aber
nur die erste und listet die übrigen auf. Welche Map läuft, entscheidet danach die layers-Liste
der Gruppe.
Die Fallback-Gruppe stammt aus dem TimoCloud-Plugin auf dem Proxy. Ist sie dort nicht gesetzt,
wird eine Gruppe namens Lobby oder Hub verwendet. Liefen die Gruppen auf mehreren Bases,
startet MuteCloud sie vorerst alle auf dieser Node. Für mehrere Rechner gibt es den
Verbund.
SimpleCloud
Gemeint ist selbst gehostetes SimpleCloud 3 mit groups/*.yml. Die aktuelle Plattform unter
simplecloud.app hält die Gruppen online, in dem Fall sagt der Befehl das und bricht ab.
SimpleCloud 2 wird ebenfalls erkannt, aber nicht übernommen.
| SimpleCloud | MuteCloud |
|---|---|
groups/<name>.yml | Gruppe, Version aus server-url oder minecraft-version |
template-id: static | dauerhafter Server, Arbeitsverzeichnis aus running/static/ |
templates/every, every_<type>, every_<software>, templates/<name> | Vorlagen, die allgemeinste gewinnt wie in SimpleCloud |
max-players des Proxys | Spielerzahl in network.toml |
Die Felder einer Gruppe werden so übertragen:
| SimpleCloud | MuteCloud |
|---|---|
min-online-count | scale.min, bei Proxys mindestens 1 |
max-online-count | scale.max |
max-memory, sonst min-memory | memory |
start-port | Beginn von port_range |
server-software oder server-url | Serversoftware |
Paper, Purpur, Folia, Leaf, Pufferfish, Velocity, Waterfall und BungeeCord werden als solche
erkannt. Aus Spigot wird Paper in derselben Version, aus einem BungeeCord-Proxy wird Velocity.
Zeigt server-url auf etwas anderes, lädt MuteCloud die Jar weiterhin von dort.
Fallback-Gruppe wird die Gruppe namens Lobby oder Hub. Gibt es keine, weist der Lauf darauf
hin, und du setzt sie mit groups <name> set fallback true.
Was nicht übernommen wird
Die Plugins der bisherigen Cloud bleiben beim Kopieren der Vorlagen draußen: die CloudNet-Bridge,
TimoCloud.jar und die Plugins von SimpleCloud wie connection-paper, sign-paper oder
cloud-api-velocity. Ebenso fehlen Server-Jars, die MuteCloud selbst herunterlädt, bei TimoCloud
außerdem BungeeCord.jar und proxy.jar. Deine eigenen Plugins und Welten kommen vollständig mit.
Alles, was der Lauf nicht eindeutig übernehmen kann, steht am Ende als Hinweis, zum Beispiel eine
Version, die er nicht erkennt, ein dauerhafter Server ohne Arbeitsverzeichnis oder Ports, die er
verschieben musste. Die Hinweise erscheinen auch mit --dry-run und sind die eigentliche
Checkliste für den Umstieg.
Nach dem Umstieg
groupsdurchgehen, Arbeitsspeicher und Grenzen prüfen- Die bisherige Cloud stoppen, bevor MuteCloud startet, sonst streiten sich beide Systeme um dieselben Ports
servicebeobachten, bis überallläuftsteht
Zurück geht es, indem du MuteCloud stoppst und die bisherige Cloud wieder startest. Entfernt wurde nichts.
Begriffe
| CloudNet | MuteCloud |
|---|---|
| Task | Gruppe |
| Template | Vorlage, hier in Schichten |
| Node | Node |
| Module | eingebaut oder ein Addon, siehe addon |
cloudnet.json | mutecloud.toml |