search

mutgos / mutgos_server

MUTGOS, a modern MUD MUCK MUSH MOO MU* text game engine
MIT License
4 stars 2 forks source link

Design Installation Logic #36

Open hyena opened 5 years ago

hyena commented 5 years ago

Decide how mutgos should be installed/deployed in production and design and test a suitable build target.

FuzzBall installed itself in /usr/games and several other locations. I always found this awkward but perhaps it's familiar.

Another way is to make a dockerfile deployment the defacto installation style. This is fairly modern but will require some thought around how to store/backup the database - keeping it inside the container itself is too risky as those are usually assumed to be ephemeral.

One thing to be aware of here is dependencies here. mutgos uses a lot of shared libraries including the third_party software.

zelerin commented 5 years ago

I would prefer allowing both. Docker might be the 'average' and easiest use case, but it should still support running outside of docker. Running outside of Docker might be useful for low resource systems or people who just don't want to pull docker stuff in, etc. In short, I don't want to make it required to run inside of Docker, but it might be the recommended path for those new to MUTGOS (or impatient).

We should be able to design it to support both, even if the out-of-docker variant requires a bit more manual work on the user's part (or just running a script that sets most everything up). For me personally, I'm running inside of CLion (the integrated debugger, valgrind, performance tools, etc are nice) and I wouldn't want to switch to docker and potentially lose some of that or make it a pain.

hyena commented 5 years ago

Docker isn't very good for development work right now for various reasons. I'm not using it either. I think it will be a good option for running as a service eventually (modulo what I wrote above re: protecting the db).

So we should support both. For now I think running it out of its own directory is fine.

hyena commented 5 years ago

On reflection about this, I think that a good approach for people capable of hosting docker containers will be a volume mounted data directory and an entrypoint into the container that permits some basic tasks (e.g. generating certificates and loading the prototype DB.)