Dashboard should have settings for host and port

[iorlas]

Since I use docker containers for development via boot2docker, it is common to force application host to 0.0.0.0. Since mrq-dashboard runs just like...

run_simple('', int(os.environ.get("PORT", 5555)), app)

It is imposible to even look at dashboard for me. Yea, I can create container with proxy setup like nginx, but really, dude.

[sylvinus]

So, we use boot2docker too and we can access the dashboard without issues.

Steps to reproduce:

$ boot2docker ip
192.168.59.103
$ cd mrq/
$ make docker
$ make ssh
(then in the container)
# make stack

This will start redis, mongo & the dashboard and you should be able to open http://192.168.59.103:5555 in your browser.

Let me know if that works!

[iorlas]

Oh I got it. You use EXPOSE in Dockerfile, which will open port forwarding to VM port networking interface - not a localhost. But why it works like expected? Because your ssh makefile target runs docker command with PUBLISH(-p flag) which actually maps ports to host.

I use docker-compose file, like so:

mrqdash:
  build: .
  command: mrq-dashboard
  volumes:
    - .:/code
  ports:
    - "5555:5555"
  links:
    - redis
    - mongodb
    - db

And here ports parameter works just as expose, without publishing. And it is desired behavior. So, to expose it from container, application should listen "real" networking interface - eth0. So 0.0.0.0 is better.

[sylvinus]

Okay, can you confirm it works now?

[iorlas]

Oh no-no-no, dude. You should not do this! Take it from ENV, like PORT.

[sylvinus]

Are you thinking of security reasons? This way of calling the dashboard is only relevant in local development IMHO (plus, it is forced in debug mode...). See https://github.com/pricingassistant/mrq/blob/master/mrq/dashboard/uwsgi-heroku.ini for the recommended way to host it on heroku for instance. You should really use a server like uwsgi or gunicorn in production

[iorlas]

Yea. I do, gunicorn. uWSGI has(had?) strange problems with psycopg2 with django 1.7, meh.
But what is a problem - we expose port to every interface so if we leave it on production... It does not matter how we expose app - we leave app port as public and if we will not restrict connections to it from OS... we gonna have a bad time.

[sylvinus]

OK - I guess it's cleaner to have config options anyway!

[iorlas]

Ty! Better safe than sorry 👍