On Feb 8, 2008, at 12:26 PM, David Masover wrote:
Thanks, I've got it now. Until now, I could just set all of them to the same server, but as I'm dynamically generating these now, I needed a solid understanding of what they do.I actually wasn't going to comment on wastefulness. With an SVN cache, and 160 gigs disk space minimum per EC2 instance, it's almost moot. As I shift more and more into actual Rails development, I am having to silence the part of me that constantly screams things like "Class names as strings in the database? On every row???" Ah, the joys of being both the developer and the dba...One more question: Is there any particular reason for the migrations to be run "closer" to the DB server? From what I can tell, they are mostly going to be things like ALTER TABLE, which could run equally well from an app server. Given that, I'm even thinking something like this:role :db do [(find_servers :role => :app)[0]] end
No reason at all, in general, unless you're dealing with a migration that reads large amounts of data and then writes it back to the database in some way. And even then, most intra-firewall networks will be more than fast enough for most of what you need there.
I'm growing to like your dynamic role definition syntax more and more, David. Forgive me for asking (I'm getting muddled in my "old age"), but did you submit a patch for that?
- Jamis
On 2/8/08, Jamis Buck <[EMAIL PROTECTED]> wrote: As I said, :web is where your webserver is installed. How you use thatbox is up to you. If your webserver runs on the same box as your app servers, then you'll have your app servers defined in both the :web and :app roles. If your webserver runs on a separate box than your app servers, then the code that gets deployed to it will probably never actually run. But :web still needs to be deployed to, because (presumably) your 500.html and index.html and CSS files and JS files and so forth are all under source control. Wasteful? Perhaps. But it's a lot more convenient for everyone involved if you assume that you blast the entire app to all servers. If that bothers you (and it might bother some people, and might even bother them for valid reasons), then you are, of course, welcome to write your own deployment tasks that pick and choose what gets deployed where. Capistrano can make that easy. As for the :db role: anything in a :db role will be deployed to. Why? Because you might have batch processes that run on your db slave servers (we do). You don't? Well, no worries, then. Just don't define your slaves in your deploy.rb. :) If your database servers are off-limits, simply define one of your app servers to be :primary => true in the :db role and be done with it. A lot of people do it this way. I fully acknowledge that questions like these come up because of the lack of documentation for Capistrano. I really, really apologize for that. If I could take the next month off and catch up on all the projects I'm juggling, I'd do it in a heartbeat, but that's not possible. For now, the Capistrano documentation effort is making slow- but-steady progress, and I'm as anxious as the next guy to see what comes of it. :) Cheers, - Jamis On Feb 8, 2008, at 10:05 AM, David Masover wrote: > Still doesn't answer how :web is actually used. Would code be loaded > to it, but never run? That would kind of make sense, given most > webservers will be able to serve static files out of that tree. > > And so long as they weren't run simultaneously, I'm not sure > migrations from multiple servers would be an issue, as the version > is stored in the database. But I suppose one of the major features > of cap is to run these things concurrently. > > But in that case, what's the rest of :db used for? Does deploy do > anything with a non-primary :db? > > On 2/8/08, Jamis Buck <[EMAIL PROTECTED]> wrote: Yup, you're right > on all three counts. :app is for where the mongrel > or fastcgi listeners will be running. :web is where your webserver > is. :db is where your migrations will be run from. Specifically, :db > with :primary => true -- you should only run your migrations from a > single server, or things will get nasty. > > - Jamis > > On Feb 7, 2008, at 6:11 PM, David Masover wrote: > > > How are each of the Rails deploy roles used? (:app, :web, and :db) > >> > I imagine :app is where the application code is pushed to, and where> > Rails is actually run. > > > > Is :db where the migrations are run from? (Or are they run from > > everywhere in :app? I'd assume they would work from there...) > >> > Does :web do anything out of the box? (Could put nginx on a separate > > machine from the actual app servers. In this case, is :web the nginx> > machine?) > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
smime.p7s
Description: S/MIME cryptographic signature
