openmu/deploy

Deployment

The recommended way to deploy OpenMU is through Docker. Depending on the scale you need, we have multiple ways to do that.

All-in-one

The all-in-one deployment is recommended, if you want to host on a small machine with a low amount of players. In this case, all kinds of OpenMU subsystems (ConnectServer, GameServer, LoginServer, AdminPanel, ...) are running in one process.

Pros

• No communication overhead between subsystems, therefore slightly faster
• Simpler deployment
• Smaller memory footprint. Since we run all in one process, we don't have the overhead of multiple processes, runtimes and can share data.
• Easier to observe and debug, no additional tools required  

Cons

• Harder to scale - only by scaling up your single machine
• Lower resiliency. If one subsystem crashes the process, the whole thing goes down
• It's a more or less self-contained system which is harder to extend

All-in-one with Traefik as Reverse Proxy

The all-in-one with traefik deployment is recommended, if you want to host on a small machine with a low amount of players and want to host your MuOnline Website on the same machine.

Once Traefik works as a Reverse Proxy, you can handle miltiple website without change the default port to HTTP/HTTPS connections.

Addin a few labels to your container, you will tell Traefik how to handle incoming requests and he will redirect to the correct website.

Pros

• No communication overhead between subsystems, therefore slightly faster
• Simpler deployment
• Smaller memory footprint. Since we run all in one process, we don't have the overhead of multiple processes, runtimes and can share data.
• Easier to observe and debug, no additional tools required
• You can have multi websites with auto renew SSL Certificates
• Expose only 80 and 443 ports for websites and admin panel. Traefik knows what to do  

Cons

• Harder to scale - only by scaling up your single machine
• Lower resiliency. If one subsystem crashes the process, the whole thing goes down
• It's a more or less self-contained system which is harder to extend

Distributed

!!! CURRENTLY BROKEN AND UNSUPPORTED, DOCS ARE OUT OF DATE !!!

It's also possible to host OpenMU in a distributed way. However, this introduces a lot more complexity and you should know what you're doing. The communication between the subsystems is handled with Dapr.

Warnings:

• It's currently unsupported due to several issues we have to resolve first. Feel free to contribute for the following issues: https://github.com/MUnique/OpenMU/issues?q=is%3Aissue%20state%3Aopen%20label%3Adistributed-deployment
• This way of hosting OpenMU is more complex and requires a good understanding of distributed systems.
• This deployment requires more resources (CPU, RAM, Disk, Network).

Pros

• Easier to scale. For example, if you need additional game servers you simply add more containers.
• Higher resiliency. If one subsystem crashes, the others are not affected.
• It's easier to add more subsystems, even custom ones.   For example, one could subscribe on already published events like guild messages or letters. Such a subsystem could forward messages to other systems (E-Mail, Discord, etc.).

Cons

• Communication overhead between subsystems.
• Higher memory footprint, since we run multiple docker containers   (each with their own .net runtime) which can't share some data.
• Harder to observe and debug. We added some stuff to compensate that (Loki, Grafana, Prometheus, Zipkin), but they require additional resources, too.