91 lines
3.6 KiB
Markdown
91 lines
3.6 KiB
Markdown
# 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](/all-in-one/) 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](/deploy/all-in-one-traefik/) 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](/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.
|