Not yet. I keep putting it off, as I've got a monkeypatch that works for now, and I am wanting to actually support variable things like reset!, as well as role concepts like splitting the definition:
role :foo 'foo.com' role :foo 'bar.com' find_servers :role => :foo # returns foo.com and bar.com All with a minimum of impact on the rest of the system (so I'd have to implement the 'roles' accessor). I am working on it now, though. Haha, just noticed that the above snip wouldn't work in the simplest case. It'd have to be something like: role :db do [ServerDefinition.new(find_servers(:role => :app)[0], :primary => true)] end And that's without selecting a random one, rather than just the first one. Obviously needs a bit of sugar! On 2/8/08, Jamis Buck <[EMAIL PROTECTED]> wrote: > > 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 that > > box 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 -~----------~----~----~----~------~----~------~--~---
