Heroku deploy button? - Githubissues

jezdez commented 8 years ago

I was wondering if there is interest in adding a "Deploy to Heroku" button for uMap (using the app.json format)?

Since January this year there is support for PostGIS on the Hobby tiers of Heroku's Postgres databases which would mean a version of uMap could run without cost if the number of database rows stay below 10k (hobby-dev), and for $9/month you get 10M rows (hobby-basic).

The "free" dyno to host the webapp will "sleep" after 30 mins of no request against it and has a daily quota, but maybe that'd be still useful for small/personal instances of uMap. Again, upgrading to a "Hobby" dyno for $7/month would lift that ban, making a non-small instance of uMap on Heroku effectively start at $16/month.

I don't know if that is an attractive option for you and whether there is interest in the larger OSM community to do that. Just thought I'd ask you about it.

yohanboniface commented 8 years ago

Well, the more options to deploy easily, the better :) Just curious: is the app.json format a standard in a way or another? I mean is this specific to heroku or are there other hosting services that use it? Can this be factorized with younohost or such diy hosting services?

jezdez commented 8 years ago

Despite its generic name it seems to have started as proprietary for Heroku, but is slowly adopted by others, e.g. Dokku (http://dokku.viewdocs.io/dokku/deployment/deployment-tasks/, for post deploy scripts only), Modulus. I don't think it's even close to being a standard, which is why I have second thoughts about it myself. Other big PaaS organizations have all their own app.json equivalent as well. I guess what we could do is hosting the Heroku specific bits (Heroku specific settings, requirements file with some deps to make it work, custom scripts to pull in leaflet.storage as in the Fabfile) in a separate repo so uMap's code isn't tainted by Heroku specific bits. What do you think?

yohanboniface commented 8 years ago

I guess what we could do is hosting the Heroku specific bits (Heroku specific settings, requirements file with some deps to make it work, custom scripts to pull in leaflet.storage as in the Fabfile) in a separate repo so uMap's code isn't tainted by Heroku specific bits. What do you think?

Two things here:

Leaflet.Storage should be included in django-leaflet-storage releases, so we should not deal with the javascript lib itself in a normal install; I'm dealing with it in the fabfile because I wanted to have an easier way to update it in the instances I'm maintaining without neading to repackage all the stack (umap + django-leaflet-storage), which is quite a pain; but I guess on a "click to deploy" workflow one only wants stable releases
about a separate repo, I'm fine with that; but if it's only one file, we certainly can include it here directly, because keeping different repositories in sync is always more work and then more stress for the maintainers (I know you know what I mean ;) ); the other way we can say that if it's a separate repo it can have a separate maintainer. Anyway, I'd arbitrate this saying that if it's only one file we could have it here (as we could have a Dockerfile); if we need also custom orchestration scripts then let's have a separate repository, yep.

jezdez commented 7 years ago

Some news from me, I've moved on from Heroku :D

But! I've moved to Dokku which gives Heroku-like deployments based on Docker. As part of that, I've created a Dokku setup here: https://github.com/jezdez/umap-dokku/

Since that includes a working Dockerfile that could be helpful for others (e.g. #80) I was wondering if you'd be interested in packaging uMap up as a Docker image automatically when you tag a new release? That basically would simplify the deployment a lot for whoever wants to use Docker. I could port the Docker specific things from my Dokku setup to this repo and add a Travis-CI config to build and push new tags to Docker Hub. The ongoing work needed from you would be to keep the Docker specific local settings file up-to-date whenever you change local.py.

yohanboniface commented 7 years ago

I was wondering if you'd be interested in packaging uMap up as a Docker image automatically when you tag a new release?

For sure!

I could port the Docker specific things from my Dokku setup to this repo and add a Travis-CI config to build and push new tags to Docker Hub. The ongoing work needed from you would be to keep the Docker specific local settings file up-to-date whenever you change local.py.

Deal! :)

jezdez commented 7 years ago

@yohanboniface Huzzah, see #456 :)

umap-project / umap

Heroku deploy button? #307