This solution is almost the same as using reverse proxies, but between the nginx and the Rack/Camping app you don't need HTTP traffic, just FastCGI. That means you can save one layer in the application, you don't need a http server (thin, mongrel, etc.) that point. Rack is a native FastCGI speaker. However this is the only difference, in other ways it's the same as using reverse proxy. The webserver (nging) knows about the virtual hosts, and maps them into host:port pairs, where the appropriate FastCGI server (the Rack itself) listens for connections. You can call this "reverse proxying" too if you want, but in this case there are different protocols on the client side (http) and the server side (fcgi).
On Sat, Mar 31, 2012 at 4:51 PM, david costa <[email protected]> wrote: > Thanks for this but how would it run for multiple users on the same port > (80) like yourname.camping.io yourname2.camping.io without having nginx > or apache as a reverse proxy ? > > > On Sat, Mar 31, 2012 at 4:44 PM, Nokan Emiro <[email protected]> wrote: > >> Hi, >> >> I run a few Camping apps in production with Rack's FastCGI handler. >> This way it is completely separable from the webserver, which can be >> nginx, apache, lighttpd, or anything else that implements the FastCGI >> protocol. On top of that it's more scalable, because you can run these >> processes on different machines -- if you feel so. >> >> ...just an idea to think about, but better than using reverse proxies. >> >> >> >> On Sat, Mar 31, 2012 at 4:29 PM, david costa <[email protected]>wrote: >> >>> Hello Jenna ! >>> I think that run rack applications the most efficient way seems to be >>> phusion passenger that works with apache and nginx. It might work with >>> other setups but it is not documented. >>> The other alternative to serve a camping application is to use a >>> standard ruby webserver (thin, unicorn, etc.) and use either apache or >>> nginx as reverse proxy. This should be more resource consuming as you would >>> have both a thin/unicorn instance running and nginx. The setup of >>> passenger + apache seems to be very easy as you just drop the file with the >>> camping app and it works. It can't really get more easier than this. >>> >>> The camping file has to be called config.ru >>> http://www.modrails.com/documentation/Users%20guide%20Apache.html#_campingand >>> this is the only way it works on my tests but I am sure that there is >>> an easy way to work with several files or in a different way. >>> >>> Now if we want to use webdav apache has the module and with a digest >>> authentication over ssl should be fairly secure. It also allows to limit >>> the upload file size which could be useful (e.g. if someone is obviously >>> trying to upload not a camping file !). >>> >>> This is what I found so far as a possible solution but I am open to >>> anything. I did try also an image that was using git/capistrano for remote >>> deployment but somehow seemed an overkill to me and it didn't really work. >>> All I am doing is highly experimental so I am more than happy to see other >>> idea/possibilities and see how far I can go with it. >>> >>> I did think about webdav based on your idea which I think would make >>> this different than heroku etc. like some beginners would not know git and >>> might just like a little tent for their shiny camping app ! >>> >>> David >>> >>> >>> >>> >>> On Sat, Mar 31, 2012 at 3:43 PM, Jenna Fox <[email protected]> wrote: >>> >>>> Apache? What are your thoughts on that choice I am curious? :) >>>> >>>> — >>>> Jenna >>>> >>>> On Sunday, 1 April 2012 at 12:27 AM, david costa wrote: >>>> >>>> Thank you :D as soon as the DNS will propagate it should be live. >>>> Some updates: now added the design from camping.io (working on the >>>> fonts) and I have narrowed down the probably easiest/best way to do it: >>>> using Webdav module on apache. So there will be no issue with creating >>>> real server users and it should really be easily accessible by anyone, >>>> anywhere. Working on some securities configurations to be sure that it >>>> works fine! >>>> >>>> >>>> On Sat, Mar 31, 2012 at 2:52 PM, Jenna Fox <[email protected]> wrote: >>>> >>>> @David - sorted, both those subdomains now point to your machine. :) >>>> >>>> — >>>> Jenna >>>> >>>> On Saturday, 31 March 2012 at 4:10 PM, david costa wrote: >>>> >>>> BTW if you want to point a run.camping.io or host.camping.io or >>>> anything you like to 66.116.108.12 will then be able to show an >>>> (hopefully) working demo using the official domain ;) >>>> >>>> On Sat, Mar 31, 2012 at 7:08 AM, david costa <[email protected]>wrote: >>>> >>>> oh sure ! for me is not a problem - love camping.io as a domain ! >>>> >>>> first worry is to have a working system that is fairly stable and >>>> usable albeit it might be launched as alpha/beta anyway :) >>>> >>>> >>>> On Sat, Mar 31, 2012 at 6:33 AM, Jenna Fox <[email protected]> wrote: >>>> >>>> We can just use a *.camping.io catchall entry >>>> >>>> >>>> On 31/03/2012, at 3:30 PM, david costa wrote: >>>> >>>> Hello Jenna, >>>> we could use host.camping.io or anything.camping.io for the frontend >>>> but if the server has to allow users to create myfancyapp.camping.ioit >>>> would be complicated as I would need to run the >>>> camping.io DNS on the hosting server to create the sub domains on the >>>> fly. I started working on it more details on a separate email. >>>> >>>> I love your idea about the key-value database how can we implement this >>>> ? >>>> Thanks >>>> David >>>> >>>> >>>> On Sat, Mar 31, 2012 at 12:21 AM, Jenna Fox <[email protected]> wrote: >>>> >>>> Those both sound like brilliant servers! I'm not laughing at all. If my >>>> mac mini is good enough for sky rim, it's good enough for web hosting for >>>> sure! >>>> >>>> Can we just use camping.io? >>>> >>>> I think starting simple is a good idea. Databases are pretty cool among >>>> web developers for various reasons, but I think are totally unnecessary for >>>> most smaller experimental applications. For a beginner, I'm inclined to >>>> have key-value databases. A really simple key-value database would work >>>> like this: >>>> >>>> sections = key.hash.to_s(36).scan(/.{0,3}/) >>>> sections.delete "" >>>> Dir.mkdir sections[0…-1].join('/') >>>> File.open(sections.join('/') + '-value', 'w') do |file| >>>> file.write JSON.generate(value) >>>> end >>>> >>>> add in some file locking, and everything is pretty cool. It splits up >>>> the kevin to a series of about four directories and then a file, and >>>> conveniently "fff" in base36 is 19995, which is a very nice maximum number >>>> of things you'd ever want to put in a single directory if using something >>>> like EXT4 or HFS+. Of course, if using a B-Tree filesystem like reiser, >>>> btrfs, zfs there is no such limitation so you can skip the scanning joining >>>> thing and just open "database/#{key.hash}" and put a value in that. >>>> >>>> Pretty cool, no? It's really easy to turn something like that in to >>>> what seems from the outside to be a persistent hash. >>>> >>>> I was working on another thing called ForeverHash, which was the same >>>> sort of idea, but used flat files. If people are interested I'd be curious >>>> enough to revive that project with more of a CouchDB inspired design. >>>> >>>> I like all these filesystem based solutions (sqlite, crazy hash in >>>> folders, flat file key-value db's) because they can be backed up and >>>> restored via webdav or sftp or whatever, and you don't need to do any weird >>>> stuff of configuring which ports and usernames and passwords in your >>>> database abstraction. I prefer the idea of having a little key-value >>>> filesystem db written in clear straight forward ruby code, because it means >>>> kids learning can see how it works and hack at it - as nice as sqlite is, >>>> it is in no way transparent. You at least have to learn SQL if you want to >>>> play with it's innards, and possibly C. >>>> >>>> On 31/03/2012, at 3:22 AM, david costa wrote: >>>> >>>> Hello all, >>>> I am opening a separate topic just to brainstorm the idea of a free, >>>> simple camping deployment/hosting option. >>>> Now this is not about re-inventing the wheel as heroku already supports >>>> camping apps too. So this would be the ground idea: >>>> >>>> a) This would be entirely free - no paid plans to upgrade etc.; >>>> b) Eventually users should be able to deploy a camping application by >>>> launching something like camping-fly myapp in the command line and it would >>>> simply work (through a git push or similar) and make it available live in a >>>> custom domain like camping.sh or ruby.am e.g. myfancyapp.camping.sh or >>>> myfancyapp.ruby.am >>>> c) Database fanciness should also be available or at least sqlite/mysql >>>> >>>> Suggestion and ideas on how to achieve this are welcome (or >>>> professionals with the expertise willing to do a simple project based on >>>> this ) >>>> servers I can make available for this: >>>> >>>> Debian 6 >>>> Intel Core i7 3930K (6 x 3,20 GHz) >>>> RAM 64 GB >>>> 3000 GB HD + 256 MB SSD drive (very useful for databases, much faster) >>>> >>>> OR (don't laugh) >>>> >>>> Mac mini >>>> 2.0GHz quad-core Intel Core i7 >>>> 8GB memory >>>> 2X256GB Solid State Drive >>>> >>>> of course we would need to limit this to screened applicants to avoid >>>> any spammers/troublemakers >>>> >>>> Best Regards >>>> David >>>> _______________________________________________ >>>> Camping-list mailing list >>>> [email protected] >>>> http://rubyforge.org/mailman/listinfo/camping-list >>>> >>>> >>>> >>>> _______________________________________________ >>>> Camping-list mailing list >>>> [email protected] >>>> http://rubyforge.org/mailman/listinfo/camping-list >>>> >>>> >>>> _______________________________________________ >>>> Camping-list mailing list >>>> [email protected] >>>> http://rubyforge.org/mailman/listinfo/camping-list >>>> >>>> >>>> >>>> _______________________________________________ >>>> Camping-list mailing list >>>> [email protected] >>>> http://rubyforge.org/mailman/listinfo/camping-list >>>> >>>> >>>> >>>> _______________________________________________ >>>> Camping-list mailing list >>>> [email protected] >>>> http://rubyforge.org/mailman/listinfo/camping-list >>>> >>>> >>>> >>>> _______________________________________________ >>>> Camping-list mailing list >>>> [email protected] >>>> http://rubyforge.org/mailman/listinfo/camping-list >>>> >>>> >>>> _______________________________________________ >>>> Camping-list mailing list >>>> [email protected] >>>> http://rubyforge.org/mailman/listinfo/camping-list >>>> >>>> >>>> >>>> _______________________________________________ >>>> Camping-list mailing list >>>> [email protected] >>>> http://rubyforge.org/mailman/listinfo/camping-list >>>> >>> >>> >>> _______________________________________________ >>> Camping-list mailing list >>> [email protected] >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >> >> >> _______________________________________________ >> Camping-list mailing list >> [email protected] >> http://rubyforge.org/mailman/listinfo/camping-list >> > > > _______________________________________________ > Camping-list mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/camping-list >
_______________________________________________ Camping-list mailing list [email protected] http://rubyforge.org/mailman/listinfo/camping-list
