Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Installation Logic #36

Open
hyena opened this issue Mar 18, 2019 · 3 comments
Open

Design Installation Logic #36

hyena opened this issue Mar 18, 2019 · 3 comments

Comments

@hyena
Copy link
Collaborator

hyena commented Mar 18, 2019

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
Copy link
Member

zelerin commented Mar 19, 2019

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
Copy link
Collaborator Author

hyena commented Mar 20, 2019

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
Copy link
Collaborator Author

hyena commented Mar 22, 2019

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants