3 ms·
I ended up writing a lot of similar functionality for the higut.com team. It was setup to auto deploy Tornado apps instead of Django but its probably not too m
by thegoleffect 17y ago
I ended up writing a lot of similar functionality for the higut.com team. It was setup to auto deploy Tornado apps instead of Django but its probably not too much of a stretch to do WSGI in general. Didn't know there'd be interest. I could factor it out and release it?
It did deploy on commit/push, bundled eggs, worked with mysql or sqlite and redis. Dunno if that sounds interesting to others though.
- njl 17y agoIf you haven't had a chance to mull over Heroku's architecture, I'd suggest giving it a look. http://heroku.com/how/architecture http://heroku.com/how/architecture Basically, nginx fronts a bunch of Varnish caches, which are then in front of a "routing mesh", which queues up requests for individual "dynos". A dyno is a single-threaded instance of your application. When one dies or is migrated, another is deployed in its place. Multiple dynos are automatically spread across multiple machines. It's a very neat solution to automatically scaling hundreds or thousands of apps. In other words, bundling the apps and pushing them out is just the beginning of a pretty fascinating architecture.
- thegoleffect 17y agoYeah, I meant those were additional features. We used a similar setup on Rackspace Cloud, though not as refined (or as secure imo). Tornado really lends itself well to a dyno type arrangement. We used nginx for load balancing and automatic frontend resolution, probably in a similar way as Heroku. Thanks for the tip though, interesting read. Talking to some other Pythonistas, there didn't seem to be much desire for a Heroku-equivalent system though - most ppl enjoy rolling their own deployments.