RailsCasts Pro episodes are now free!

Learn more or hide this

Scott Carleton's Profile

GitHub User: ScotterC

Site: http://www.artsicle.com/

Comments by Scott Carleton

Avatar

Thanks Ryan.

Could someone elaborate on 'view_context' for me and why it doesn't need to hit the db to lookup the current user? Is this ActionView's context? Does it then have to run through the whole ActionView layer? I feel that this could be made more explicit or simplified.

Thanks.

Avatar

I've done all these things in the past year so I'll pitch in.

The best part of using ec2's is you can get your servers to a stateless point. Where you can drop your existing servers at the drop of the hat if they have redundancies.

If you were to have a web, app, db server. to split that up you'd start by setting up a new db server where it's solely db and dump your current db over there. I personally love using RDS so I always have a separate db setup to host and I never have to worry about it. Alternatively, you could setup a slave on a separate server and then promote it later.

You can then set up more separate app servers, which become part of the network so they'll be managing some load but still working with the web role on the original server.

Finally, you can pull out the web role into it's own and the two web servers will work fine and you can drop one seamlessly.

Auto scaling is a bit different. Amazon does have ways of flashing your current image and they'll start up a new one if certain requirements are met. I haven't played with this as much. As long as you're paying attention, you can scale yourself really quickly in rubber without any new configuratio.

Staging environment is just like any rails env. set up a new staging.rb file in the environments and when you do cap rubber:create_staging, prefix it with RUBBER_ENV=staging cap rubber:create_staging so it setups up an entire rubber configuration within that environment. Separates out the instance yaml's and everything.

Avatar

Yea! That's my favorite part of rubber, it doesn't abstract anything away from you.

tunneling in, use your ec2 keypair and ssh root@name, i.e.: ssh -i ~/.ec2/gsg-keypair root@app01.foo.com

Once you're in, you can find all your config files where they're supposed to be or your app in the /mnt directory.

Avatar

There's a much better way.

First off, make sure you have rmagick in your gemfile.

Then in your rubber.yml file there should be a setting for 'packages'. Somewhere around line 189. You can simply add aptitude packages in this array.

Add to the array, 'imagemagick' and possibly libmagick9-dev. Simply cap rubber:bootstrap your instance and it will install these packages for you along with the new gem in your gemfile. Paperclip and other image processing should be good to go.

Also. There's a wealth of rubber information on the google discussion group from the last few years. http://groups.google.com/group/rubber-ec2

Note, you can also install packages on a template by template basis. Like only installing imagemagick when you are using passenger etc. The rubber.yml packages line will install it on all your severs.

Avatar

The best way would be to add a rubber template to the mix. You can check out the existing templates here: https://github.com/wr0ngway/rubber/tree/master/templates

Another method would be to simply spin up a server with rubber, ssh in and setup faye manually.

Avatar

This is a big topic.

The simple aspect that my experience lends is just a very scalable system. With rubber, I have roles for each aspect of my application and spinning up a new server to handle more application resources takes minutes. Interfacing ec2's with other amazon services is ridiculously easy. Scaling horizontally and vertically is simplified especially with tools like Rubber.

Avatar

Yes. Rubber hooks into capistrano and installs all the packages that are needed for the given template. Adding more aptitude packages is easy and all contained within the Rubber config files.

Avatar

splitting up the web app and db instances in rubber is more about how Rubber handles 'roles'. There can also be a redis role, a resque role, a sphinx role etc. It allows rubber to be very modular and scalable. You can place different roles on different hardware for instance.

Avatar

I've been using Rubber for a bit over a year now and absolutely love it. Version 2.0 is a huge improvement as well.