Preventing parallel execution on the same host (under two names)

[Christian van der Leeden]

Hi,

we're deploying on EC2 and to keep the setup clean we've defined host
aliase names.
E.g. app1 and app2 for the app servers, lb1 for loadbalancer 1 etc.

Even though the names are different the hosts are sometimes the same.
E.g. load balancer
is also hosting the app server 1. On a deploy the code deploy would
now run in parallel
on the same host (lb1 and app1 who are identical).

I'm looking for ideas on how to patch (or configure) capistrano to
prevent this situation.

I imagine something along the lines of resolving the hostnames before
running a command
and then filtering out the duplicates. Is there an easy way to do
accomplish this?

Thanks

Christian

[Jamis Buck]

My recommendation: keep the host names distinct, and just use roles to
indicate different purposes of identical hosts. Thus, you'd have
"host1" in both the app and loadbalancer roles.

Personally, I've used the fact that Capistrano does NOT resolve host
names early. It's great for testing recipes, demoing (and debugging)
Capistrano, etc. I'd hate to see that go away.

- Jamis

[Lee Hambley]

Christian,

I agree with Jamis, there're ways to do what you need that don't require altering anything about Capistrano's internals, it will just require you to rethink the structure of your tasks and role definitions a little; this might not fit well with the EC2 extensions/code/tasks you are using, but we'll all be more than HTH.

- Lee

2009/5/28 Jamis Buck <ja...@37signals.com>

[Christian van der Leeden]

Hi,

thanks for the input. Our setup on EC2 is structure so we can move services 

around. This is done by moving the IP and registering the host aliases in DNS (dyndns).

Normally the host names and IPs do not overlap. But there are times... And to

prevent capistrano from uploading and installing a release in parallel

on two hosts that are pointing to the identical address would be asking for trouble,

wouldn't it?

 I was looking for the code in capistraon where

a task collects all the hosts that the "run" command would be executing on.

My patch would then resolve the hostnames and remove the duplicates.

So the resoultion of the hostname would be just before ssh would do it.

I will look into the role model to see if I can make better use of this.

But could you sketch at what classes to look if I'd like to patch the "run" command

method so it will remove duplicates?

Thanks

Christian

[Adrien Montfort]

Hello,

I'm sorry to dig up such an old thread but I'm facing the same issue right now and I really don't know how to fix it.

I run a rails app on a bunch of servers.

capistrano/rails defines different roles : web, app, resque, scheduler...

and all my infrastructure is built with ansible which generates different hostname aliases depending on the roles : app-1, app-2, work-1, http-1...

But as it was the case for OP, the same server can have different roles and I wish I could use the alias instead of the hard hostname in my capistrano config. I don't want to duplicate my ansible configuration...

Would you have any suggestion ?

[Lee Hambley]

Depending which version of Capistrano you are using (but in theory, all of them will work)

just do this: 

server 'hostname', roles: [foo, bar, baz]

You should be able to build that list out of Ansible, you need to.

Lee Hambley

--

http://lee.hambley.name/

+49 (0) 170 298 5667

--

You received this message because you are subscribed to the Google Groups "Capistrano" group.

To unsubscribe from this group and stop receiving emails from it, send an email to capistrano+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/capistrano/0212a66e-3b7f-4566-96be-fbb5146a495d%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Adrien Montfort]

Thanks for you help!

If I understand correctly, though, it means that I must change my "app" project with my capistrano configuration every time I change my server repartition (in my "infra" project). I was hoping I would not have to do so. :)

In my case (and OP's as far as I can tell), early address resolution would probably make sense I think.