Moving around an EIPA with Rubber

3 views
Skip to first unread message

Matthew Conway

unread,
Dec 9, 2009, 5:43:34 PM12/9/09
to rubbe...@googlegroups.com
This is sounds very similar to what happens when one creates an instance.
Take a look at the create_instance method in rubber/lib/rubber/recipes/rubber/instances.rb. You should also probably look at rubber/lib/rubber/recipes/rubber/static_ips.rb to see what the setup_static_ips task does. The setup_(local|remote|dns)_aliases tasks are defined in rubber/lib/rubber/recipes/rubber/setup.rb and handle local-etc-host, remote-etc-hosts, and dns-cnames respectively.

logger.info "Instance running, fetching hostname/ip data"
instance_item.external_host = instance[:external_host]
instance_item.external_ip = instance[:external_ip]
instance_item.internal_host = instance[:internal_host]
instance_item.zone = instance[:zone]
rubber_instances.save()

# setup amazon elastic ips if configured to do so
setup_static_ips

# Need to setup aliases so ssh doesn't give us errors when we
# later try? to connect to same ip but using alias
setup_local_aliases

# re-load the roles since we may have just defined new ones
load_roles() unless env.disable_auto_roles

# Connect to newly created instance and grab its internal ip
# so that we can update all aliases

task :_get_ip, :hosts => instance_item.external_ip do
instance_item.internal_ip = capture(print_ip_command).strip
rubber_instances.save()
end

# even though instance is running, sometimes ssh hasn't started yet,
# so retry on connect failure
begin
_get_ip
rescue ConnectionError
sleep 2
logger.info "Failed to connect to #{instance_alias} (#{instance_item.external_ip}), retrying"
retry
end

# Add the aliases for this instance to all other hosts
setup_remote_aliases
setup_dns_aliases



From baldowl on github:

Greetings,

It's been a while since I started to try out Rubber. I almost persuaded one of my customers to switch to AWS's EC2 with Rubber to gain in flexibility.

What I still cannot do is transfering an Elastic IP Address from a VM to another. I tried, without much success, to write a Capistrano task to automate the move; what is blocking me is the "synchronization" of VMs data stored ininstance-<env>.yml and the other files.

Conceptually, it should not be too difficult to move an EIPA:

• ask the user two aliases;
• if the first VM really has an EIPA then detached it;
• wait for the first VM to get a new external IP from AWS's slow DHCP service;
• attach the free EIPA to the second VM.
Among these steps, I think the code should somehow manage to "fix" the addresses in the local /etc/hosts, in~/.ssh/know_hosts and in instance-<env>.yml, but I'm stuck: I cannot seem to find the right spot, the right way to "sync" these data (I'm usually left unable to connect to the first VM but, depending on the various prototypes, sometimes the EIPA is transferred and sometimes some of the data get half-synced).

May I ask you for some help?

Thanks for your time and for Rubber.
Reply all
Reply to author
Forward
0 new messages