using anyserver.py in production

329 views
Skip to first unread message

Lewis

unread,
Jun 2, 2015, 2:02:25 PM6/2/15
to web...@googlegroups.com
I am afraid that the documentation for anyserver.py is a bit scant for my meager skills.

My site runs on linode vm.

Doc says just run python anyserver.py -s cherrypy -i 127.0.0.1.

So, on my server I would cd to the directory containing web2py.  I assume I would replace 127.0.0.1 (which is localhost) with the url or numeric web address of the actual site.  

I did that and I cannot reach the web server across the internet. 

Clearly, I am missing something very obvious here.  What is really needed?

Thanks.

Niphlod

unread,
Jun 2, 2015, 7:38:34 PM6/2/15
to web...@googlegroups.com
use -i 0.0.0.0 to listen on all available interfaces. 

BTW#1: the default webserver (rocket) and cherrypy (what you seem to want using) have nearly the same performances

BTW#2: unless you have some specific requirements, for an internet-facing server is ALWAYS recommended to use a real webserver as a frontend (i.e. nginx or apache), even if you use more performant python-webservers (i.e. gunicorn or tornado)


Lewis

unread,
Jun 3, 2015, 1:06:00 PM6/3/15
to web...@googlegroups.com
This worked:  python anyserver.py -s cherrypy -i 0.0.0.0 -p 80 > logfile &

I get the reverse proxy thing.   Currently, I have uwsgi behind nginx which works. However, uwsgi's settings are twiddly; seem to change between versions; the documentation, while extensive, is challenging; and I don't need its features.  It seems Roberto, a frequent contributor here, promotes uwsgi as both a web server in its own right and a load balancer. All fine, but increases complexity.  

I am looking for the most minimal wsgi "shim" instead of the more robust uwsgi.  For this experimental site performance is not such a big deal.

I have found Digital Ocean's documentation for many, many useful configurations.  It provides a really great starting point.  Here:  https://www.digitalocean.com/community/tags/python?type=tutorials

Lewis

unread,
Jun 3, 2015, 1:09:47 PM6/3/15
to web...@googlegroups.com
I should point out this minimal approach doesn't support https, so the admin console can't be reached.  Login also can't be used without https and ssl.  The digital ocean article shows how to enable ssl for cherrypy.  Hopefully, I can interpolate a bit and actually use nginx to do the https routing with ssl (as it works for uwsgi).

Niphlod

unread,
Jun 3, 2015, 5:53:37 PM6/3/15
to web...@googlegroups.com
anyone is free to do whatever he/she wants. 
Few things to consider: uwsgi is by far the most complete piece of production-ready "thingy" to run your app into. 
Given that a frontend IMHO is required, when you set a reverse proxy to anyserver.py (vs setting uwsgi) if you don't have specific requirements to run outside uwsgi, you're absolutely NOT cutting any "cogs" in your system. frontend-thingy-app.
"specific requirements to run outside uwsgi" IMHO are : twisted, tornado, maybe gevent. 

Running rocket,waitress,cherrypy,paste,wsgiref (i.e. threaded webservers) is a NO-GO if you have uwsgi at your disposal.

Hoping that a software doesn't break even between major releases is hoping for the best (I assume you had some passing from uwsgi 1.x to 2.x), but these 19 lines didn't change from Jan 2013. 
If you don't want anything to change, don't update your system in the first place. If you want new features / bugs fixed / etc, you HAVE to deal with some discrepancies.

note for everybody: I'm not at all involved in uwsgi development/marketing at all, but I strongly feel that what Roberto did needs to be highly considered. He's passionate, replies quickly and politely all the times and listens to the community very carefully.

Lewis

unread,
Jun 3, 2015, 8:41:18 PM6/3/15
to web...@googlegroups.com
Those 19 lines had been in place from before 2013 (probably 2011!), which is why I missed the change.   That site is not really "production" except for the fact that it faces the public internet.  Probably has no visitors except me;  I just want to learn how to configure and manage something that is a sensible production environment.

I realize I am not cutting any cogs, just substituting cogs.

Why would you rule out Cherrypy?  I am not a big proponent of one over the other, just curious about your strong recommendation in favor of twisted, tornado, gevent. Simply looking for something reasonably well-supported, reliable, easier to manage, and adequate in performance (whatever that means).

Thanks.

Niphlod

unread,
Jun 4, 2015, 3:55:45 AM6/4/15
to web...@googlegroups.com
cherrypy or rocket may sustain an average of 50 concurrent users (again, on an average linode server, etc etc etc). no multiprocess usage. no defense against common attacks like slowloris. 

I'm not advocating at all twisted, tornado or gevent 'cause your app needs to be rewritten to use what they offer. Once done, they can sustain easily thousands of concurrent users.

nginx+uwsgi can very well sustain 1k concurrent users without hassles on a linode server. you get (at the very least) multiprocessing, automatic recycle of workers, fine grained stats, defense against pretty much anything (as always against DDoS there's really not much you can do).

Lewis

unread,
Jun 4, 2015, 11:57:36 AM6/4/15
to web...@googlegroups.com
What about gunicorn as a wsgi server to simply stand between nginx and web2py?

Here is what I am going to do:
1. script (Bash) my config so that it is repeatable.  This will be similar to the existing scripts supplied with web2py, but with small changes.  test it in a new deployment on a clean VM. 
2. Port this to either fabric or ansible to enable repeatable, remote deployment.  Can either reuse the Bash script or do it the fabric way.
3. Try either gunicorn or tornado as a stand-in wsgi shim as an alternative to uwsgi to see what is involved.  Won't improve performance or feature set--just a way to see if config is any more manageable.

I do think anyserver.py is a convenient accompaniament to using rocket locally.  Let's the test server run remotely.  Is there any way to get anyserver to support ssl for the admin ui?

Thanks

Niphlod

unread,
Jun 4, 2015, 3:20:10 PM6/4/15
to web...@googlegroups.com


On Thursday, June 4, 2015 at 5:57:36 PM UTC+2, Lewis wrote:
What about gunicorn as a wsgi server to simply stand between nginx and web2py?

gunicorn behind nginx is a popular config, but usually is to have several gevented processes to bind on a single socket. There are several "workers" available, and I'm not saying that is not useful otherwise, but it's where it shines (and was born for (note the "g")). I'm not counting to continously bash your proposal, but it doesn't seem that gunicorn parameters (and docs) are less intuitive than the one for running a wsgi app inside uwsgi (nor more "stable").
 

Here is what I am going to do:
1. script (Bash) my config so that it is repeatable.  This will be similar to the existing scripts supplied with web2py, but with small changes.  test it in a new deployment on a clean VM. 
2. Port this to either fabric or ansible to enable repeatable, remote deployment.  Can either reuse the Bash script or do it the fabric way.
3. Try either gunicorn or tornado as a stand-in wsgi shim as an alternative to uwsgi to see what is involved.  Won't improve performance or feature set--just a way to see if config is any more manageable.

perfect plan, but again, I'm fighting hard to see the point (searching for a "stabler" config syntax). BTW: Tornado isn't suited AT ALL useful if you plan to run a web2py app in 95% of the cases. 
 

I do think anyserver.py is a convenient accompaniament to using rocket locally.  Let's the test server run remotely.  Is there any way to get anyserver to support ssl for the admin ui?


Nope, for two simple reasons:
 - not every webserver supports ssl
 - you're not supposed to run any of them without a frontend: in any case it can take care of SSL termination way better than pure python solutions  

Lewis

unread,
Jun 7, 2015, 10:51:06 PM6/7/15
to web...@googlegroups.com
Thanks for all this.

So, the world seems to back UWSGI as the preferrred solution.  I'll get over it.  I see that you are saying that once when one does need performance tuning with multiple workers, uwsgi is both more performant and more tunable.

I think having a fabric deploy script will solve my problems.

Someday I'll try unusable.

Enough for now.

Lewis

unread,
Jun 9, 2015, 12:53:44 PM6/9/15
to web...@googlegroups.com
Someday, I'll try ansible.  Spelling correction to the rescue.
Reply all
Reply to author
Forward
0 new messages