Loomio

Running loomio on a Digital Ocean droplet

Rodolfo Saccani PublicSeen by 37

I've read this guide:
https://github.com/loomio/loomio/wiki/Setup-Loomio-production

and I have a few practical questions.

1) at the current stage, if I run my own loomio production environment, how often should I expect to perform a database migration and how time consuming is it?

2) the guide mentions postgresql. Should I expect to work fine also with mariadb/mysql?

3) the guide suggests setting up a 2GB swap on a 512MB droplet, where all this memory is spent (database, application?)

4) what's the correct procedure to keep the production environment up to date with the new features?

thanks a lot
Rodolfo

mix irving

Hey @rsaccani glad to hear you've had a look at that guide. It's coming together, but can definitely be improved, so your questions are great.

some answers :

  1. DB migrations with dokku are easy. It's a single command, and should only take 5 mins (or an hour if you have a million users)

  2. I don't think it will work out of the box without postgresql - there are probably a couple of functions which assume postgres is being used. Also not the gems (ruby libraries) would probably need to be changed. To be honest I found the PG setup part of the tutorial pretty straightforward in case that's a concern.

  3. not exactly sure. It think it's taken up largely by running 4 workers (instances of the app which are spun up so that many requests can be dealt with simultaneously). If you're interested in knowing exactly I suggest ssh'ing into the running server and run htop (you may need to install it sudo apt-get install htop). Note if you want you could just straight spend money on a more resourced droplet.

  4. you'll need to have a local git repo, then pull the latest code in from github, then push it to your server like you did the first time you deployed it. Dokku takes care of the rest. Processionally a new feature will require a database migration, or some extra settings if there is added connectivity to a third party service. We don't currently have a clear place we communicate these changes, but would love to hear how might suit best for you.

Robert Guthrie

Thanks @rsaccani and @mixirving. I'll clarify with some answers too.

Most migrations run very quickly, and we'll include progress indicators on slow migrations. Would recommend you have a clone environment to test migtations before you run them on production.

Postgresql is a firm requirement. We use many pg specific features.

The guide recommends the 2GB swap for compilation of gems. Ruby will eat as much memory as it can (it also never frees memory) but the 2GB thing is so that compiling the C extensions in gems does not crash.

Pulling code and running migrations is the normal way. I recommend you run a clone environment so you can test your migrations before they run on production. If you like, start a loomio in production user group and we can start to formalise a comms pathway for those users.

mc0e

Re communicating about updates, it would be good if the app itself would check for updates, distinguish between those that are security-critical or not, and report to the site owner via email, and through a message in the /admin interface.

mc0e

Add to my last comment that it would be helpful if there was a command line test which could be run to see if there are outstanding updates against either the loomio app, or the OS packages, and to distinguish security vs non-security updates. I.e. a test suitable for use by a scripted system which automatically rebuilds the container when required.

This secuirty updates issue is a generic problem with docker containers, and makes the notion that the docker host sysadmin doesn't need to know much about the content of the containers little more than a myth. I wish the docker folks would define some standard expected interface so that compliant containers could provide a standard interface to such a test.