baseline: OpenMU upstream b5a0961 (fresh source)

deploy/README.md

@@ -0,0 +1,90 @@
+# 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.