Re: What I've learned deploying pylons
On Sun, Mar 29, 2009 at 7:50 PM, Wichert Akkerman wich...@wiggy.net wrote: Previously Noah Gift wrote: On Sun, Mar 29, 2009 at 1:05 PM, Mike Orr sluggos...@gmail.com wrote: On Sat, Mar 28, 2009 at 4:42 PM, jose jj.gal...@gmail.com wrote: So this brings me to the heart of what I've learned, if you are going to deploy a long running app how do you do it? I put all my Pylons and Quixote apps under Supervisord, with Apache mod_proxy. I want to try nginx when I have a chance. Some people prefer mod_wsgi because it runs everything under Apache processes, but I like being able to supervisor stop and supervisor start individual applications for maintenance and debugging, plus seeing them under their own names in the ps listing. This recently came up at work, at one other gotcha is that you have to write your own init script. Is there a recipe on the Pylons wiki for this? You can do three things: - start supervisord using init by adding an entry in /etc/inittab. This requires root and is for the very paranoid: even if supervisord dies (which never happens) it will be restarted. - use an init script to start supervisord at system boot. Requires root. - Start supervisord using an @reboot crontab entry in a normal account. Does not require root. Works on all Linux distributions, I'm not sure is other cron implementation support this. The last one is my preferred method: it is trivial to setup and can be done by any normal user. thanks for the advice guys! Will put to use on Monday. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. -- Cheers, Noah --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: What I've learned deploying pylons
Hi jj, On Sun, Mar 29, 2009 at 00:42, jose jj.gal...@gmail.com wrote: I can certainly sympathize here. ;) I have tried various deployment solutions as well for my work on developers.org.ua project. I used to use supervisord plus mod_proxy + paster serve (cherrypy wsgi). To start supervisord on boot time I wrote simple /etc/event.d/supervisor script, I think I posted this solution to pylons wiki. It worked nicely but then I discovered mod_wsgi and I was hooked. It was considerably simpler setup compared to superisor/paster/http_proxy. It run ok for about 4-5 months and then I switched deployment again. I had experienced strange Apache behaviour where it would cease to serve incoming requests even though on the surface everything seems just fine. I struggle for a couple of weeks and then gave up. I am not sure it was mod_wsgi fault or something eniterly different. Anyway, I switched back to paster (cherrypy WSGI) but I used monit instead of supervisor (I already used it to monitor apache and other system resources and it was trivial task to add paster monitor checks). And I also set up nginx as a front-proxy. And it all works amazingly good right now. I run three identical paster servers which are proxied by nginx, using round-robin load balancing. nginx also serves all static content and works as a proxy to apache. Apache now has far fewer modules, mainly mod_php for our PHP pages. See also http://unblog.developers.org.ua/2009/03/nginx.html If you are interested I guess I could post relevant configs here or to Pylons wiki -- Max.Ischenko // twitter.com/maxua --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: What I've learned deploying pylons
On Mar 29, 7:52 pm, Max Ischenko ische...@gmail.com wrote: Hi jj, On Sun, Mar 29, 2009 at 00:42, jose jj.gal...@gmail.com wrote: I can certainly sympathize here. ;) I have tried various deployment solutions as well for my work on developers.org.ua project. I used to use supervisord plus mod_proxy + paster serve (cherrypy wsgi). To start supervisord on boot time I wrote simple /etc/event.d/supervisor script, I think I posted this solution to pylons wiki. It worked nicely but then I discovered mod_wsgi and I was hooked. It was considerably simpler setup compared to superisor/paster/http_proxy. It run ok for about 4-5 months and then I switched deployment again. I had experienced strange Apache behaviour where it would cease to serve incoming requests even though on the surface everything seems just fine. I struggle for a couple of weeks and then gave up. I am not sure it was mod_wsgi fault or something eniterly different. Don't know if that was related to zombie issue you asked about on mod_wsgi list back in November or not. You were asked to supply some more specific information but you never responded. Bit hard to solve what ever problem it was when you don't followup about it. -( Anyway, all indications suggest it was something about your specific application, environment or configuration, as no general problem with mod_wsgi has come up which would explain such behaviour and no one else has reported anything like it. I do find though that a lot of problems people have are because they use embedded mode, especially with prefork, and do not bother to properly configure the Apache MPM settings to appropriate values for fat Python web applications. I have blogged about this previously in relation to mod_python, but also relevant to mod_wsgi embedded mode. http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html Graham Anyway, I switched back to paster (cherrypy WSGI) but I used monit instead of supervisor (I already used it to monitor apache and other system resources and it was trivial task to add paster monitor checks). And I also set up nginx as a front-proxy. And it all works amazingly good right now. I run three identical paster servers which are proxied by nginx, using round-robin load balancing. nginx also serves all static content and works as a proxy to apache. Apache now has far fewer modules, mainly mod_php for our PHP pages. See alsohttp://unblog.developers.org.ua/2009/03/nginx.html If you are interested I guess I could post relevant configs here or to Pylons wiki -- Max.Ischenko // twitter.com/maxua --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: What I've learned deploying pylons
On Sun, Mar 29, 2009 at 12:35, Graham Dumpleton graham.dumple...@gmail.comwrote: Don't know if that was related to zombie issue you asked about on mod_wsgi list back in November or not. You were asked to supply some more specific information but you never responded. Bit hard to solve what ever problem it was when you don't followup about it. -( You're absolutely right of course. I should have troubleshooted it better. I am 99% sure it's not mod_wsgi fault. After all, even now it leaks memory like there is no tomorrow so monit have to restart it about once in 4-6 days. The thing is, I am not such a great programmer, I don't have tons of admin expertise (nor I am too keen to get it) and there are pressing concerns (as always) such as site being not available to users. I was looking for the easiest/fastest route possible and nginx/http proxy worked for me. PS: as for automatic code reloading, we did used it, on production too. May be we shouldn't be. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: What I've learned deploying pylons
On Sun, Mar 29, 2009 at 10:35 PM, Graham Dumpleton graham.dumple...@gmail.com wrote: On Mar 29, 7:52 pm, Max Ischenko ische...@gmail.com wrote: Hi jj, On Sun, Mar 29, 2009 at 00:42, jose jj.gal...@gmail.com wrote: I can certainly sympathize here. ;) I have tried various deployment solutions as well for my work on developers.org.ua project. I used to use supervisord plus mod_proxy + paster serve (cherrypy wsgi). To start supervisord on boot time I wrote simple /etc/event.d/supervisor script, I think I posted this solution to pylons wiki. It worked nicely but then I discovered mod_wsgi and I was hooked. It was considerably simpler setup compared to superisor/paster/http_proxy. It run ok for about 4-5 months and then I switched deployment again. I had experienced strange Apache behaviour where it would cease to serve incoming requests even though on the surface everything seems just fine. I struggle for a couple of weeks and then gave up. I am not sure it was mod_wsgi fault or something eniterly different. Don't know if that was related to zombie issue you asked about on mod_wsgi list back in November or not. You were asked to supply some more specific information but you never responded. Bit hard to solve what ever problem it was when you don't followup about it. -( Anyway, all indications suggest it was something about your specific application, environment or configuration, as no general problem with mod_wsgi has come up which would explain such behaviour and no one else has reported anything like it. I do find though that a lot of problems people have are because they use embedded mode, especially with prefork, and do not bother to properly configure the Apache MPM settings to appropriate values for fat Python web applications. I have blogged about this previously in relation to mod_python, but also relevant to mod_wsgi embedded mode. http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html To be honest, I am a pretty big fan of Apache, and I have used mod_wsgi with success. Finding out about how to automatically reload apps is a nice find. I agree that when I am developing, I want to run on the actual server that will be running my code in production. It sounds like someone needs to write the definitive guide to mod_wsgi :) I would read it Graham Anyway, I switched back to paster (cherrypy WSGI) but I used monit instead of supervisor (I already used it to monitor apache and other system resources and it was trivial task to add paster monitor checks). And I also set up nginx as a front-proxy. And it all works amazingly good right now. I run three identical paster servers which are proxied by nginx, using round-robin load balancing. nginx also serves all static content and works as a proxy to apache. Apache now has far fewer modules, mainly mod_php for our PHP pages. See alsohttp://unblog.developers.org.ua/2009/03/nginx.html If you are interested I guess I could post relevant configs here or to Pylons wiki -- Max.Ischenko // twitter.com/maxua -- Cheers, Noah --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: What I've learned deploying pylons
On 3/28/09, Jose Galvez jj.gal...@gmail.com wrote:
Here is my supervisord init script. not sure if its the best but its
working
This script looks like it's for Red Hat; here's one for Ubuntu. Start
works and stop works, but restart doesn't for some reason, so I have
to start it again after restarting.
As for supervisord spontaneously crashing and needing to be
relaunched; I've never seen it happen.
By the way, the easiest way to make an init script is to copy an
existing minimal one.
===
#! /bin/bash -e
# /etc/init.d/supervisor: start and stop the Supervisor daemon manager
#SUPERVISORD=/usr/local/bin/supervisord
#SUPERVISORCTL=/usr/local/bin/supervisorctl
SUPERVISORD=/usr/local/venv-supervisor/bin/supervisord
SUPERVISORCTL=/usr/local/venv-supervisor/bin/supervisorctl
PIDFILE=/var/run/supervisord.pid
OPTS=-c /etc/supervisord.conf
test -x $SUPERVISORD || exit 0
. /lib/lsb/init-functions
export PATH=${PATH:+$PATH:}/usr/local/bin:/usr/sbin:/sbin
start () {
log_begin_msg Starting Supervisor daemon manager...
$SUPERVISORD $OPTS || log_end_msg 1
log_end_msg 0
}
stop () {
log_begin_msg Stopping Supervisor daemon manager...
$SUPERVISORCTL shutdown || log_end_msg 1
log_end_msg 0
}
case $1 in
start)
start
;;
stop)
stop
;;
restart|reload|force-reload)
stop
start
;;
esac
exit 0
===
--
Mike Orr sluggos...@gmail.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: repoze.what-pylons working sample project
Hello, Andrius! I've just finished the sample application, which is available for download here: http://bitbucket.org/Gustavo/whatpylonsproject/overview/ Now it shows how to test the protected areas with repoze.who and repoze.what. I've also updated the HOWTO on the Pylons Wiki to mention this sample application: http://wiki.pylonshq.com/display/pylonscookbook/Authorization+with+repoze.what I'll try to updated the repoze.what-pylons docs to also explain how to configure the functional test suite. I hope you'll enjoy it! Please feel free to ask if you have further questions! Cheers, =Gustavo On Thursday March 26, 2009 14:30:47 Audrius Kažukauskas wrote: On Fri, 2009-03-13 at 01:45:35 +0100, Gustavo Narea wrote: Hello, I'm sorry about the delay, but I've been very busy this week. I've started a project at http://bitbucket.org/Gustavo/whatpylonsproject/overview/ The only thing it misses is a test suite using repoze.who-testutil. I'm stuck with a weird DB problem; I'll ask for help if I'm not able to fix it. I also wish to add more comments to it. Once it's finished, I'll update the HOWTO and post a message on this ML to let you know. I understand that right now is not the proper time to ask (PyCon and such), but I was wondering what's the progress with test suite? I'd like to use repoze.who-testutil, unfortunately the documentation regarding setting it up via repoze.what is missing (marked as TODO), and it's not clear to me how to do it properly. I would be very grateful for any help with that. -- Gustavo Narea xri://=Gustavo. | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons Book - SimpleSite 2 (Chapter 14) create error
Thank you Michael, that pointed me in the right direction. I had a section=['section'], rather than a section=values['section'] in a query, and your answer allowed me to follow the right path. I am wondering if I was getting the same result from the downloaded code because of my unfamiliarity with paster - (yet another stupid question coming up). I haven't found a satisfactory way to stop paster and then restart it. If I break the current paster serve and issue the command paster serve --stop (or --stop-daemon) I receive a 'no PID file exists in paster.pid' message. If I restart paster serve, I get a SocketServer error that the address is already in use. I'm currently having to kill the entire shell process to really do a reload of paster, and perhaps that is contributing to some of my issues. Anyways, thank you for helping the newbie.. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: What I've learned deploying pylons
That would be great I would love to the configs Jose Max Ischenko wrote: Hi jj, On Sun, Mar 29, 2009 at 00:42, jose jj.gal...@gmail.com mailto:jj.gal...@gmail.com wrote: I can certainly sympathize here. ;) I have tried various deployment solutions as well for my work on developers.org.ua http://developers.org.ua project. I used to use supervisord plus mod_proxy + paster serve (cherrypy wsgi). To start supervisord on boot time I wrote simple /etc/event.d/supervisor script, I think I posted this solution to pylons wiki. It worked nicely but then I discovered mod_wsgi and I was hooked. It was considerably simpler setup compared to superisor/paster/http_proxy. It run ok for about 4-5 months and then I switched deployment again. I had experienced strange Apache behaviour where it would cease to serve incoming requests even though on the surface everything seems just fine. I struggle for a couple of weeks and then gave up. I am not sure it was mod_wsgi fault or something eniterly different. Anyway, I switched back to paster (cherrypy WSGI) but I used monit instead of supervisor (I already used it to monitor apache and other system resources and it was trivial task to add paster monitor checks). And I also set up nginx as a front-proxy. And it all works amazingly good right now. I run three identical paster servers which are proxied by nginx, using round-robin load balancing. nginx also serves all static content and works as a proxy to apache. Apache now has far fewer modules, mainly mod_php for our PHP pages. See also http://unblog.developers.org.ua/2009/03/nginx.html If you are interested I guess I could post relevant configs here or to Pylons wiki -- Max.Ischenko // twitter.com/maxua http://twitter.com/maxua --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: What I've learned deploying pylons
so is upstartn going to replace System V eventually? Max Ischenko wrote: On Sun, Mar 29, 2009 at 16:55, Mike Orr sluggos...@gmail.com mailto:sluggos...@gmail.com wrote: On 3/28/09, Jose Galvez jj.gal...@gmail.com mailto:jj.gal...@gmail.com wrote: Here is my supervisord init script. not sure if its the best but its working This script looks like it's for Red Hat; here's one for Ubuntu. Start works and stop works, but restart doesn't for some reason, so I have to start it again after restarting. If you're using Ubuntu, I'd suggest using their newer upstartn system. Here is my /etc/event.d/supervisor script exec supervisord --nodaemon start on runlevel 2 console output That's it. Worked quite nicely. For more info see http://upstart.ubuntu.com/getting-started.html And if you want to monitor the supervisord and restart if it fails (never happened to me) I can recommend monit, available via apt-get. Max. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: What I've learned deploying pylons
Wow this discussion has been really great, I've learned quite a bit just following the different threads. Like I said I think there is room in the wiki for us to post better real world howto's with end to end config files. For example I could post my: 1) init script for supervisord (although I think the one Mike posted is better then mine so I'll most likely edit mine 2) the section in my supervisord.conf file 3) the sections in my apache conf files I would like to see the same thing from Max on how he did it with nginx and monit, and how Graham is serving his stuff with mod_wsgi. As mentioned in one of the posts mod_wsgi could use some better documentation and this might be a good way to do that. Max also mentions upstartn, whats the advantage to that over using the system V script? Jose jose wrote: HI all, Just thought I would share what I've learned deploying pylons on both windows and linux loxes. First let me say right off the bat I absolutely love pylons I think hands down its the absolutely best web development environment out there. Having said that the biggest issue I see with pylons and wsgi apps in general, really has nothing to do with their ability to function as a framework, but its deployment. Now before anyone goes all read the wiki read the docs on me, I have so the rest of this is just my experience setting up pylons to run with Apache on both windows and linux (Ubuntu specifically). Now I love choices and if you want to connect your new pylons app to run under apache you do have several, mod_wsgi, fastcgi, scgi, mod_python, and the ever present mod_proxy, and I've tried them all. For my money, both in terms of simplicity and in terms of development cycles mod_proxy is by far the easiest and I would venture to say the most stable. I did use mod_wsgi for a while, and will most likely use it on a limited project where running a pylons long running appp will be problematic, but mod_proxy just offers so much in the way of flexibility. Not to mention the fact that I just hate restarting apache just because I've made some minor change to one of my controllers. So this brings me to the heart of what I've learned, if you are going to deploy a long running app how do you do it? On Windows the best solution I've come up with is my own Bourbon project, which I admit has all but died (I would love to give the code to someone to run with, I just really don't have the time to maintain it any longer). The reason I wrote it in the first place was allow give me a single windows service to manage all my running pylons apps without having to give each and every one its own windows service, which is a pain. Bourbon works pretty good, but at the moment you can't turn off or restart a single app, its all or nothing, which isn't very good. On Linux its a different story, there are a tun of ways to get a long running application up and running, and to some extent it depends on what distro you are using as to which is the best. On ubuntu I initially thought of writing rc init scripts for each app, but this quickly turned into a task that I didn't want to deal with, so I turned to mod_wsgi, which as I stated above for philosophical reasons I just didn't like. The I found, ok more likely stumbled upon after reading the wiki, supervisord. Finally something that makes sense (at least to me it really does). Now, after writing only a single rc init script to get supervisord running my pylons apps (and almost anything else I might have to start as a a daemon for that matter) is easily configured to run under the supervisord.conf file. I just love that thing. I know a best practices section goes against the grain for the pylons community because it is all about flexibility, but what about a series of deployment scenario's, where people could write how they are actually doing this stuff. I know its already all there if you look for it, but this has taken me while to put together for myself and I'm sure there are others out there who could learn from our growing pains --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: What I've learned deploying pylons
On Mar 30, 7:17 am, Jose Galvez jj.gal...@gmail.com wrote: Wow this discussion has been really great, I've learned quite a bit just following the different threads. Like I said I think there is room in the wiki for us to post better real world howto's with end to end config files. For example I could post my: 1) init script for supervisord (although I think the one Mike posted is better then mine so I'll most likely edit mine 2) the section in my supervisord.conf file 3) the sections in my apache conf files I would like to see the same thing from Max on how he did it with nginx and monit, and how Graham is serving his stuff with mod_wsgi. As mentioned in one of the posts mod_wsgi could use some better documentation and this might be a good way to do that. Do you mean better mod_wsgi documentation as part of the Pylons documentation, or that mod_wsgi itself needs better/more documentation? There is already quite a lot of documentation on mod_wsgi. It could be a bit better indexed but if one follows the main entry points from the mod_wsgi main page, it will get you to most stuff. http://code.google.com/p/modwsgi/wiki/InstallationInstructions http://code.google.com/p/modwsgi/wiki/DeveloperGuidelines The index of everything is at: http://code.google.com/p/modwsgi/w/list The main ones pertinent to Pylons are: http://code.google.com/p/modwsgi/wiki/IntegrationWithPylons http://code.google.com/p/modwsgi/wiki/VirtualEnvironments There is also some information in the online Pylons book, although that does have at least one mistake in claiming that EvalException cannot be used with mod_wsgi. You just need to make sure you are running daemon mode with a single process. That is also mentioned in documentation: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Browser_Based_Debugger Graham Max also mentions upstartn, whats the advantage to that over using the system V script? Jose jose wrote: HI all, Just thought I would share what I've learned deploying pylons on both windows and linux loxes. First let me say right off the bat I absolutely love pylons I think hands down its the absolutely best web development environment out there. Having said that the biggest issue I see with pylons and wsgi apps in general, really has nothing to do with their ability to function as a framework, but its deployment. Now before anyone goes all read the wiki read the docs on me, I have so the rest of this is just my experience setting up pylons to run with Apache on both windows and linux (Ubuntu specifically). Now I love choices and if you want to connect your new pylons app to run under apache you do have several, mod_wsgi, fastcgi, scgi, mod_python, and the ever present mod_proxy, and I've tried them all. For my money, both in terms of simplicity and in terms of development cycles mod_proxy is by far the easiest and I would venture to say the most stable. I did use mod_wsgi for a while, and will most likely use it on a limited project where running a pylons long running appp will be problematic, but mod_proxy just offers so much in the way of flexibility. Not to mention the fact that I just hate restarting apache just because I've made some minor change to one of my controllers. So this brings me to the heart of what I've learned, if you are going to deploy a long running app how do you do it? On Windows the best solution I've come up with is my own Bourbon project, which I admit has all but died (I would love to give the code to someone to run with, I just really don't have the time to maintain it any longer). The reason I wrote it in the first place was allow give me a single windows service to manage all my running pylons apps without having to give each and every one its own windows service, which is a pain. Bourbon works pretty good, but at the moment you can't turn off or restart a single app, its all or nothing, which isn't very good. On Linux its a different story, there are a tun of ways to get a long running application up and running, and to some extent it depends on what distro you are using as to which is the best. On ubuntu I initially thought of writing rc init scripts for each app, but this quickly turned into a task that I didn't want to deal with, so I turned to mod_wsgi, which as I stated above for philosophical reasons I just didn't like. The I found, ok more likely stumbled upon after reading the wiki, supervisord. Finally something that makes sense (at least to me it really does). Now, after writing only a single rc init script to get supervisord running my pylons apps (and almost anything else I might have to start as a a daemon for that matter) is easily configured to run under the supervisord.conf file. I just love that thing. I know a best practices section goes against the grain for the pylons community because it is all about flexibility, but what
Re: What I've learned deploying pylons
Graham Dumpleton wrote: On Mar 30, 7:17 am, Jose Galvez jj.gal...@gmail.com wrote: Wow this discussion has been really great, I've learned quite a bit just following the different threads. Like I said I think there is room in the wiki for us to post better real world howto's with end to end config files. For example I could post my: 1) init script for supervisord (although I think the one Mike posted is better then mine so I'll most likely edit mine 2) the section in my supervisord.conf file 3) the sections in my apache conf files I would like to see the same thing from Max on how he did it with nginx and monit, and how Graham is serving his stuff with mod_wsgi. As mentioned in one of the posts mod_wsgi could use some better documentation and this might be a good way to do that. Do you mean better mod_wsgi documentation as part of the Pylons documentation, or that mod_wsgi itself needs better/more documentation? I guess I mean better or more complete example is probably a better choice of words rather then documentation because as you already mentioned mod_wsgi has good docs There is already quite a lot of documentation on mod_wsgi. It could be a bit better indexed but if one follows the main entry points from the mod_wsgi main page, it will get you to most stuff. http://code.google.com/p/modwsgi/wiki/InstallationInstructions http://code.google.com/p/modwsgi/wiki/DeveloperGuidelines The index of everything is at: http://code.google.com/p/modwsgi/w/list The main ones pertinent to Pylons are: http://code.google.com/p/modwsgi/wiki/IntegrationWithPylons http://code.google.com/p/modwsgi/wiki/VirtualEnvironments There is also some information in the online Pylons book, although that does have at least one mistake in claiming that EvalException cannot be used with mod_wsgi. You just need to make sure you are running daemon mode with a single process. That is also mentioned in documentation: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Browser_Based_Debugger Graham Max also mentions upstartn, whats the advantage to that over using the system V script? Jose jose wrote: HI all, Just thought I would share what I've learned deploying pylons on both windows and linux loxes. First let me say right off the bat I absolutely love pylons I think hands down its the absolutely best web development environment out there. Having said that the biggest issue I see with pylons and wsgi apps in general, really has nothing to do with their ability to function as a framework, but its deployment. Now before anyone goes all read the wiki read the docs on me, I have so the rest of this is just my experience setting up pylons to run with Apache on both windows and linux (Ubuntu specifically). Now I love choices and if you want to connect your new pylons app to run under apache you do have several, mod_wsgi, fastcgi, scgi, mod_python, and the ever present mod_proxy, and I've tried them all. For my money, both in terms of simplicity and in terms of development cycles mod_proxy is by far the easiest and I would venture to say the most stable. I did use mod_wsgi for a while, and will most likely use it on a limited project where running a pylons long running appp will be problematic, but mod_proxy just offers so much in the way of flexibility. Not to mention the fact that I just hate restarting apache just because I've made some minor change to one of my controllers. So this brings me to the heart of what I've learned, if you are going to deploy a long running app how do you do it? On Windows the best solution I've come up with is my own Bourbon project, which I admit has all but died (I would love to give the code to someone to run with, I just really don't have the time to maintain it any longer). The reason I wrote it in the first place was allow give me a single windows service to manage all my running pylons apps without having to give each and every one its own windows service, which is a pain. Bourbon works pretty good, but at the moment you can't turn off or restart a single app, its all or nothing, which isn't very good. On Linux its a different story, there are a tun of ways to get a long running application up and running, and to some extent it depends on what distro you are using as to which is the best. On ubuntu I initially thought of writing rc init scripts for each app, but this quickly turned into a task that I didn't want to deal with, so I turned to mod_wsgi, which as I stated above for philosophical reasons I just didn't like. The I found, ok more likely stumbled upon after reading the wiki, supervisord. Finally something that makes sense (at least to me it really does). Now, after writing only a single rc init script to get supervisord running my pylons apps (and almost anything else I might have to start as a a daemon for that matter) is easily
Re: What I've learned deploying pylons
On Mar 29, 4:52 am, Max Ischenko ische...@gmail.com wrote: I run three identical paster servers which are proxied by nginx, using round-robin load balancing. nginx also serves all static content and works as a proxy to apache. Apache now has far fewer modules, mainly mod_php for our PHP pages. FWIW, I found a considerable performance upgrade over Apache's mod_php by switching to php-cgi through nginx, and then running an opcode cache ( either APC or eAccelerator ) made it even faster. There are some benchmarks out there on this; unless you need something within apache itself ( i often do for mod_perl ) , it might be worth discarding completely. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
