Very cool stuff ..

The Rails deployment stack just made a big leap ahead!

I wrote some nginx tasks

ec2onrails:server:nginx_start/stop
ec2onrails:server:nginx_configure

nginx to frontend 10 mongrel clusters

ps: there is a fair mode nginx version.
it uses round robin technique instead.
http://brainspl.at/articles/2007/11/09/a-fair-proxy-balancer-for-nginx-and-mongrel

source:
http://git.localdomain.pl/?p=nginx.git;a=tree;hb=upstream_fair-0.6

Let me know what other unexplained behaviour you’re seeing and I’ll see if I can find an explanation for you! :-)

which php returns nothing.
php –version doesn’t give any info either.

and yet PHP pages are being processed (at least when specifically addressed with a full URL including the page name)… if anyone has any ideas I’m all ears.

Also, trying out the rmagick stuff now.

For the base feisty, there are quite a few feisty images out there, so never know which one to start with. I’d like a trustworthy feisty that
- feisty server
- bundling script
- tasksel install lamp

pretty much a snapshot of what you have but at an earlier stage of building up.

But now that you’ve explained my concerns, I’ll just stick with this…

still want/need my libxml-ruby gem though !!!!!!!!!!!!!

Actually the normal location for gems on Ubuntu (when rubygems is installed using the Ubuntu/Debian package management) is /var/lib/gems/1.8/gems, you can verify that by looking at the list of files for the libgems-ruby1.8 package.

rmagick is installed using the Ubuntu/Debian package management system (which is also quite “normal”), and the reason it’s better to install it that way rather than using “gem install” is that it relies on native libraries (libmagick), and this way they will be kept in sync.

I’m not sure what you mean by “you should have a base feisty up there with your bundling scripts”.

gem install -y libxml-ruby

with my “normal” vmware installation, that just works

normal for ubuntu is here: /usr/lib/ruby/gems/1.8/gems/

how did you install rmagick, again “normal” is via: gem install -y rmagick

don’t get me wrong, love it, but just wished somethings were different…

you should have a base feisty up there with your bundling scripts, so others can have a going at rail enabling…

thanks for all the work

rsync -rlvzcC –rsh=”ssh -l root -i privkey” files/ “#{hostname}:/”

I know it’s a bit of a workaround but you could also have a Capistrano task that does something like this:

ssh -l root@hostname adduser app admin

Which will give the app user sudoers access, this only needs to be done once.

I admit these are workarounds. I’m open to further discussion about it, join the mailing list and bring this topic up there.

But try as I might i couldn’t get Capistrano to selectively with doing some things as one user (”app”) and some other things as another (”root”).

Is there a good way of doing this?

I have been actually testing the performance of Swiftiply and some app servers full of mongrels - dynamically starting + stopping app servers and mongrels without balancer reconfiguration.

My first goal was to find out IF it is possible to add app-server instances under load. The result is: it IS possible. I really liked Swiftiply + swiftiplied_mogrels: good performance and easy to set up (though I lost some time then found + fixed a bug in the Swiftiply 0.6.1-gem which did not allow distributed mongrels connect to an other host than localhost). I think I will make some more tests with NginX + Swiftiply.

Though I must say: I am a bit dissapointed of the EC2-processor performance:

I tried to outperform a single hardware server (Opteron 1210, Dual 1,8 Ghz, 1GB RAM) with a bunch of EC2-Instances. I needed at least 4 of them to have a comparable performance (dynamic Rails requests, without DB load). If I benchmark requests with an excessive DB usage - the results are even more dissappointing. If you are interested, I can post some more details… Did you do any performance tests? Maybe its our application, that is so CPU-intensive….?

My further goal would be to write cap/capazon tasks to start/stop multiple app-server-instances all dynamically connecting to a given running load-balancer + DB-server. And another bunch of tasks setting up the DB-server + load balancer - which is not THAAAT complicated…

Unfortunately my company has decided NOT to take EC2 as primary deployment platform, because of the relatively high costs and the poor performance: but we might use EC2 as a supplementary and/or backup solution.

Therefore I think I will not work on the EC2-specific deployment part part any longer. But I will let you know, if I have any new details…

Actually I am working on a clone of your image with Swiftiply + Mongel(in eventmode)+ Capistrano 2.0 + Capazon. It will be able to run multiple instances of the same Image in different roles and on the fly add/remove app-server instances. I think it will take some weeks, till it’s production ready..

I keep you posted if you are interested.

Greetz from Berlin

You raise a good point about the rebundle script cleaning up after itself. It just runs the Amazon tools which leave the image part files, but it might be nice to delete those after.

Just a warning to others - although the mongrel start script is in root’s home path, these scripts should NOT be run as root. This also applies to all other start scripts. You will need to chown or delete your log files and/or the indexes if you do this.

Perhaps these scripts should be in app’s home directory?