|
|
|
|
|
by sudont
5201 days ago
|
|
I've had a bunch of weirdness deploying a Flask app to the service. Defining requirements in a yml is nice for auto-install, but the scripts tend to break for me worse than "hand installing" via pip. The reason I'm moving the app to a micro EC2 instance is that dotCloud actively masks the debug interface, so I can't exactly tell why my app is breaking on their servers, but not my local machine. Plus the fact that dotCloud/Heroku is largely overkill for small, team-focused apps. I can't really justify dropping 99/mo for something only 50 people will be using. Otherwise, it was an incredibly smooth experience. EDIT: requirements.txt, not YML |
|
First, which requirements are you putting in your dotcloud.yml? In general, pip-installable requirements should just go in a standard requirements.txt file, and dotcloud.yml should be used to describe the higher-level structure of your application (ie which service types you need).
Also, I'm not sure what you mean about "masking the debug interface", but all your Flask/WSGI and nginx logs are available with the "dotcloud logs" command, and you can also log into your service instance directly to debug using "dotcloud ssh" (in which case logs can be found in the /var/log directory). You can also certainly use Flask in debug mode, by setting "application.debug = True" in your wsgi.py
It is true that you may have trouble using the interactive, browser-based debugger with the default setup on dotCloud, then but this is a Flask limitation, not a dotCloud one. From http://flask.pocoo.org/docs/quickstart/#debug-mode: "the interactive debugger does not work in forking environments (which makes it nearly impossible to use on production servers)"
Hope that helps, and if you have any other questions, drop us a line: support@dotcloud.com