engineyard-metadata

Presents a simple interface to get metadata about your EngineYard AppCloud instances running on Amazon EC2.

Purpose

To define a simple interface to useful metadata (passwords, IP addresses, etc.) that is otherwise buried deep inside EngineYard’s chef config files and various API calls.

Examples

Get a dynamically updated list of all running app servers so that you can pool memcached over all of them. (EY.metadata.app_servers)
Get the current database password so that you can write a script that connects to it. (EY.metadata.database_password)

Here’s the current method list:

EY.metadata.app_master EY.metadata.app_name EY.metadata.app_servers EY.metadata.app_slaves EY.metadata.current_path EY.metadata.database_host EY.metadata.database_name EY.metadata.database_password (only works from cloud instances) EY.metadata.database_username EY.metadata.db_master EY.metadata.db_servers EY.metadata.db_slaves EY.metadata.environment_name EY.metadata.mysql_command (only works from cloud instances) EY.metadata.mysqldump_command (only works from cloud instances) EY.metadata.present_instance_id (only works from cloud instances) EY.metadata.present_instance_role (only works from cloud instances) EY.metadata.present_public_hostname (only works from cloud instances) EY.metadata.present_security_group (only works from cloud instances) EY.metadata.repository_uri EY.metadata.shared_path EY.metadata.solo EY.metadata.ssh_aliases EY.metadata.ssh_password (only works from cloud instances) EY.metadata.ssh_username EY.metadata.stack_name EY.metadata.utilities

Use

See the rdoc at the engineyard-metadata rdoc.

When you’re executing this gem from INSIDE the cloud

When you’re executing the gem from your instances, you don’t have to configure anything. Just require the gem.

When you’re executing this gem from OUTSIDE the cloud

You must…

have ~/.eyrc or set EY.metadata.ey_cloud_token= or set ENV['EY_CLOUD_TOKEN'].
execute the gem from the local copy of your application’s repo or set EY.metadata.environment_name= or set ENV['EY_ENVIRONMENT_NAME'].

Where the methods are defined

Metadata getters are defined directly on EY.metadata (which in turn delegates out to various adapters). Even if EngineYard changes the structure of the config files or Amazon EC2’s API changes, these methods will stay the same.

[...]
>> require 'rubygems'
[...]
>> require 'engineyard-metadata'
[...]
>> EY.metadata.database_host
=> "external_db_master.compute-1.amazonaws.com"
>> EY.metadata.app_servers
=> [ 'app_1.compute-1.amazonaws.com' , 'app_master.compute-1.amazonaws.com' ]
>> EY.metadata.db_servers
=> [ 'db_master.compute-1.amazonaws.com', 'db_slave_1.compute-1.amazonaws.com' ]
[...and many more...]

SSH alias helper

You can put the output of ey_ssh_aliases into ~/.ssh/config:

$ EY_ENVIRONMENT_NAME=my_env ey_ssh_aliases Host my_env-app_master Hostname ec2-11-11-111-11.compute-1.amazonaws.com User deploy StrictHostKeyChecking no

Host my_env-db_master Hostname ec2-111-11-11-11.compute-1.amazonaws.com User deploy StrictHostKeyChecking no

Known issues

Doesn’t work with multiple apps per environment. [FIXED!]
It’s not always clear what environment you’re running in. For example, you say EY.metadata.something and you’re just supposed to know what environment you’re in. You can use .environment_name=, but you might not remember.
There are no factory methods. If we fully fleshed this out, it might be like my_env = EY::Environment.find('my_env') and my_app_master = my_env.app_master. Not sure that complexity would add a lot of value.

History

This is the second generation of rubygems.org/gems/ey_cloud_awareness.