forward / capify-ec2

Capify-EC2 is used to generate Capistrano namespaces and tasks from Amazon EC2 instance tags, dynamically building the list of servers to be deployed to.

Capify-EC2

Capify-EC2 is used to generate Capistrano namespaces and tasks from Amazon EC2 instance tags, dynamically building the list of servers to be deployed to.

Note: Capistrano 3 is completely incompatible with Capistrano 2, and therefore Capify-EC2 will not function with Capistrano 3. If you are using Capistrano 3, you can use Cap-EC2, however note that the configuration (config/ec2.yml) is not compatible between Capify-EC2 and Cap-EC2.

Installation

gem install capify-ec2

or add the gem to your project's Gemfile.

Then, add the gem to your deploy.rb:

require "capify-ec2/capistrano"

Configuration

Create a YML configuration file (default path is ./config/ec2.yml) with the following contents:

:aws_access_key_id: "YOUR ACCESS KEY"
:aws_secret_access_key: "YOUR SECRET"
:aws_params:
  :region: 'eu-west-1'
:load_balanced: true
:project_tag: "YOUR APP NAME"

You can change the path to your ec2.yml by placing the following in your deploy.rb before calling ec2_roles:

set :ec2_config, 'location/of/my/ec2.yml'

Note: :aws_access_key_id and :aws_secret_access_key are required, unless you provide them via the two alternative methods detailed below under 'AWS Credentials' or have the :use_iam_profile option set to use IAM roles. :region is also required. Other settings are optional.

• :project_tag

  If this is defined, Capify-EC2 will only create namespaces and tasks for the EC2 instances that include a matching project in a comma separated list 'Project' tag. By default, all instances available to the specified AWS access key will be used.

  It is possible to include multiple projects simultaneously by using the :project_tags parameter, like so:

  :project_tags:
    - "YOUR APP NAME"
    - "YOUR OTHER APP NAME"

• :aws_project_tag

  Use this option to change which EC2 instance tag Capify-EC2 uses to determine instance project. Defaults to 'Project' if omitted.

• :aws_roles_tag

  Use this option to change which EC2 instance tag Capify-EC2 uses to determine instance roles. Defaults to 'Roles' if omitted.

• :aws_options_tag

  Use this option to change which EC2 instance tag Capify-EC2 uses to determine instance options. Defaults to 'Options' if omitted.

• :aws_stages_tag

  Use this option to change which EC2 instance tag Capify-EC2 uses to determine which instances belong to a stage. Should be used in conjunction with the Capistrano Multistage Extension. Defaults to 'Stages' if omitted.

• :load_balanced

  When ':load_balanced' is set to 'true', Capify-EC2 uses pre and post-deploy hooks to deregister the instance from an associated Elastic Load Balancer, perform the actual deploy, then finally reregister with the ELB and validated the instance health. Note: This options only applies to deployments made to an individual instance, using the command cap INSTANCE_NAME_HERE deploy - it doesn't apply to roles.

• :use_iam_profile

  Use this option to use IAM roles for authentication, rather than an access key id and secret access key.

• :aws_session_token

  If you are an IAM user that only has access to temporary credentials, you can provide your session token here to authenticate.

AWS Credentials

Via YML Configuration

By default, Capify-EC2 will attempt to use the credentials found in your ec2.yml configuration as detailed above.

Via Fog Configuration

If you wish, you can have Capify-EC2 use the AWS credentials found in your Fog configuration, instead of instead of specifying :aws_access_key_id and :aws_secret_access_key in the YML configuration file. Optionally, if you requires session tokens or federated users, you can set :aws_session_token. Refer to the Fog documentation for details on specifying AWS credentials.

Via Environment Variables

If you wish, you can define AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as environment variables, instead of specifying :aws_access_key_id and :aws_secret_access_key in the YML configuration file. Optionally, if you requires session tokens or federated users, you can set the environment variable AWS_SESSION_TOKEN.

Via AWS IAM Roles

If you have IAM roles set up on your box to allow querying EC2 information you tell Fog to use IAM roles and you will not need to provide any credentials at runtime. For more information on IAM roles read Amazon's IAM documentation.

If you are an IAM user that only has access to temporary credentials, you can use :aws_session_token: "YOUR TOKEN HERE" to authenticate.

Ordering

Capify-EC2 will attempt to load your AWS credentials first from the ec2.yml configuration file, then from your Fog configuration file, and finally from environment variables. It will display an error if no credentials are found by any of these methods.

EC2 Tags

You will need to create instance tags using the AWS Management Console or API, to further configure Capify-EC2. The following tags are used:

• Tag 'Project'

  Used with the :project_tag option in config/ec2.yml to limit Capify-EC2's functionality to a subset of your instances. This can also be a comma separated list of projects involving this machine.

• Tag 'Roles'

  A comma seperated list of roles that will be converted into Capistrano namespaces, for example 'app,workers', 'app,varnish,workers', 'db' and so on.

• Tag 'Options'

  A comma seperated list of options which will be defined as 'true' for that instance. See the 'Options' section below for more information on their use.

Usage

In our examples, imagine that you have three servers on EC2 named and tagged as follows:

'Name' Tag	'Roles' Tag	'Options' Tag
server-1	web	cron,resque
server-2	db
server-3	web,db,app

Single Roles

You need to add a call to ec2_roles in your deploy.rb, like so:

ec2_roles :name => :web

This will generate the following tasks:

task :server-1 do
  role :web, SERVER-1_EC2_PUBLIC_DNS_HERE, :cron=>true, :resque=>true
end

task :server-3 do
  role :web, SERVER-3_EC2_PUBLIC_DNS_HERE
end

task :web do
  role :web, SERVER-1_EC2_PUBLIC_DNS_HERE, :cron=>true, :resque=>true
  role :web, SERVER-3_EC2_PUBLIC_DNS_HERE
end

Note that there are no tasks created for 'server-2', as it does not have the role 'web'. If we were to change the ec2_roles definition in your deploy.rb to the following:

ec2_roles :name => :db

Then we will instead see the following tasks generated:

task :server-2 do
  role :db, SERVER-2_EC2_PUBLIC_DNS_HERE
end

task :server-3 do
  role :db, SERVER-3_EC2_PUBLIC_DNS_HERE
end

task :db do
  role :db, SERVER-2_EC2_PUBLIC_DNS_HERE
  role :db, SERVER-3_EC2_PUBLIC_DNS_HERE
end

Multiple Roles

If you want to create tasks for servers using multiple roles, you can call ec2_roles multiple times in your deploy.rb as follows:

ec2_roles :web
ec2_roles :db

Which would generate the following tasks:

task :server-1 do
  role :web, SERVER-1_EC2_PUBLIC_DNS_HERE, :cron=>true, :resque=>true
end

task :server-2 do
  role :db, SERVER-2_EC2_PUBLIC_DNS_HERE
end

task :server-3 do
  role :web, SERVER-3_EC2_PUBLIC_DNS_HERE
  role :db, SERVER-3_EC2_PUBLIC_DNS_HERE
end

task :web do
  role :web, SERVER-1_EC2_PUBLIC_DNS_HERE
  role :web, SERVER-3_EC2_PUBLIC_DNS_HERE
end

task :db do
  role :db, SERVER-2_EC2_PUBLIC_DNS_HERE, :cron=>true, :resque=>true
  role :db, SERVER-3_EC2_PUBLIC_DNS_HERE
end

Role Variables

You can define custom variables which will be set as standard Capistrano variables within the scope of the role you define them one, for example:

ec2_roles :name=>"web", :variables => {:rails_env => 'staging'}

In this case, instances that that are tagged with the 'web' role will have the custom variable 'rails_env' available to them in any tasks they use. The following tasks would be generated:

task :server-1 do
  role :web, SERVER-1_EC2_PUBLIC_DNS_HERE, :cron=>true, :resque=>true, :rails_env=>'staging'
end

task :server-3 do
  role :web, SERVER-3_EC2_PUBLIC_DNS_HERE
end

task :web do
  role :web, SERVER-1_EC2_PUBLIC_DNS_HERE, :cron=>true, :resque=>true, :rails_env=>'staging'
  role :web, SERVER-3_EC2_PUBLIC_DNS_HERE, :rails_env=>'staging'
end

Shorthand Role Definition

If you are defining a role with no options or variables, you can define it using the following shorthand:

ec2_roles :web

Options

Via EC2 Tags

As mentioned in the 'EC2 Tags' section, creating an 'Options' tag on your EC2 instances will define those options as 'true' for the associated instance. This allows you to refine your capistrano tasks. For example, if we had the following group of instances in EC2:

'Name' Tag	'Roles' Tag	'Options' Tag
server-A	web
server-B	web
server-C	web	worker

You could then create a task in your deploy.rb that will only be executed on the worker machine, like so:

task :reload_workers, :only=>{:worker=>true} do
  # Do something to a specific server with the 'worker' option in it's EC2 tags.
end

task :reload_workers, :roles => :app, :only=>{:worker=>true} do
  # Do something to a specific 'app' server with the 'worker' option in it's EC2 tags.
end

Via Role Definitions

As well as defining Options at an instance level via EC2 tags, you can define an Option in your deploy.rb at the same time as defining the role, as follows:

ec2_roles :name=>"web", :options=>{:worker=>"server-C"}

In this case, you set the value of :worker equal to the instance name you want to be a worker. The task definition remains the same:

task :reload_workers => :web, :only=>{:worker=>true} do
  # Do something to a specific server whose instance name is equal to the 'worker' option in the role definition.
end

Deploying

Once you have defined the various roles used by your application, you can deploy to it as you normally would a namespace, for example if you define the following in your deploy.rb:

ec2_roles :web
ec2_roles :app

You can deploy to just the 'web' instances like so:

cap web deploy

If you've defined multiple roles, you can deploy to them all by chaining the tasks, like so:

cap web app deploy

You can also deploy to individual instances by specifying their 'Name' tag, for example, with the sample servers above:

cap server-1 deploy

would deploy only to the instance named 'server-1'.

Default Deploys

You can set a role as the default so that it will be included when you run cap deploy without specifying any roles, for example in your deploy.rb:

ec2_roles :name=>"web", :options => {:default=>true}

Then run:

cap deploy

You can set multiple roles as defaults, so they are all included when you run cap deploy, like so:

ec2_roles :name=>"web", :options => {:default=>true}
ec2_roles :name=>"db", :options => {:default=>true}

Rolling Deployments

This feature allows you to deploy your code to instances one at a time, rather than simultaneously. This becomes useful for more complex applications that may take longer to startup after a deployment. Capistrano will perform a full deploy (including any custom hooks) against a single instance, optionally perform a HTTP healthcheck against the instance, then proceed to the next instance if deployment was successful.

After deployment a status report is displayed, indicating on which instances deployment succeeded, failed or did not begin. With some failures, further action may need to be taken manually; for example if an instance is removed from an ELB (see the 'Usage with Elastic Load Balancers' section below) and the deployment fails, the instance will not be reregistered with the ELB, for safety reasons.

Usage

To use the rolling deployment feature without a healthcheck, simple run your deployments with the following command:

cap rolling_deploy

You can restrict the scope of the rolling deploy by targetting one or more roles like so:

cap web rolling_deploy

cap web db rolling_deploy

Usage with Healthchecks

When defining a role with the ec2_role call, if you configure a healthcheck for that role as follows, it will automatically be used during the rolling deployment:

ec2_roles :name => "web",
          :variables => {
            :healthcheck => {
              :path   => '/status',
              :port   => 80,
              :result => 'OK'
            }
          }

In this example, the following URL would be generated:

http://EC2_INSTANCE_PUBLIC_DNS_HERE:80/status

And the contents of the page at that URL must match 'OK' exactly for the healthcheck to pass. If unsuccessful, the healthcheck is repeated every second, until a timeout of 60 seconds is reached, at which point the rolling deployment is aborted, and a progress summary displayed.

The result can also be specified as a regular expression, which gives more flexibility. For example:

ec2_roles :name => "web",
          :variables => {
            :healthcheck => {
              :path   => '/status',
              :port   => 80,
              :result => /^(OK|Success)$/
            }
          }

The result can also be specified as an array (of strings and/or regular expressions), in which case the result of the health check is successful if the response matches any of the items in the array. For example:

ec2_roles :name => "web",
          :variables => {
            :healthcheck => {
              :path   => '/status',
              :port   => 80,
              :result => ['OK', /^\s*Success/]
            }
          }

The default timeout of 60 seconds can be overridden by setting :timeout to a custom value in seconds. The protocol used defaults to 'http://', however you can switch to 'https://' by setting :https equal to 'true'. For example:

ec2_roles :name => "web",
          :variables => {
            :healthcheck => {
              :path   => '/status',
              :port   => 80,
              :result => 'OK'
              :https   => true,
              :timeout => 10
            }
          }

Sets a 10 second timeout, and performs the health check over HTTPS. Note: When performing the health check over HTTPS, SSL peer verification is turned off, as the EC2 instance public DNS will not match the SSL certificate, causing the health check to fail.

You can run multiple different healthchecks for a role by specifying the healthcheck as an array instead:

ec2_roles :name => "web",
          :variables => {
            :healthcheck => [{
              :path   => '/status',
              :port   => 80,
              :result => 'OK'
            }, {
              :path   => '/other_status',
              :port   => 81,
              :result => 'OK'
            }]
          }

By default, healthchecks are made using GET requests, but you make can use POST instead by specifying :via as either :post or 'POST' and adding ':data' attributes, as follows:

ec2_roles :name => "web",
          :variables => {
            :healthcheck => {
              :path    => '/status',
              :port    => 80,
              :result  => '{ json_response: as_string }'
              :https   => true,
              :timeout => 10,
              :via     => :post,
              :data    => '{ json_request: as_string }'
            }
          }

Usage with Elastic Load Balancers

You can have Capify-EC2 automatically deregister and reregister an instance from whichever ELB it is associated with, before and after the deployment, by setting :load_balanced to 'true' in the role definition, for example:

ec2_roles :name => "web",
          :variables => {
            :load_balanced => true
          }

In this example, when an instance with the role 'web' is deployed to, Capify-EC2 will attempt to find which ELB the instance is currently registered with and deregister it. The deploy will then proceed as usual. When it is complete, the instance will be reregistered with the same ELB, and the status verified as 'InService' before the deployment is deemed successful. Note: You can only use this feature with instances that are registered with a single ELB, if you have instances registered with multiple ELBs, you are advised not to use this feature.

You can also combine this feature with a Healthcheck like so:

ec2_roles :name => "web",
          :variables => {
            :healthcheck => {
                :path   => '/status',
                :port   => 80,
                :result => 'OK'
              }
            :load_balanced => true
          }

In this example, the instance will be deregistered from the ELB it is associated with and then deployed to. A healthcheck will then be performed, and providing this passes, the instance will be reregistered with the ELB and verified.

If an instance has been tagged with multiple roles, this behaviour will apply if :load_balanced is set to 'true' in at least one of those roles.

If an instance is not associated with any ELBs, then the behaviour will be skipped silently, even if :load_balanced is set to 'true'.

Viewing All Instances

The following command will generate a listing of all instances that match your configuration (projects and roles), along with their associated details:

cap ec2:status

Viewing CPU Utilisation

The following command will generate an enhanced listing of all instances that match your configuration (projects and roles) as with ec2:status, with the addition of CPU utilisation graphs powered by CloudWatch. You will need to ensure your IAM permissions allow this.

cap ec2:graph

Viewing ELBs

The following command will generate a listing of all ELBs with instances that match your configuration (projects):

cap ec2:elbs

Note: if no project tag is specified in your ec2.yml configuration, then all ELBs and their associated instances are shown when using this command.

Managing Load Balancers

You can use the following commands to deregister and reregister instances in an Elastic Load Balancer.

cap SERVER_NAME_HERE ec2:deregister_instance

cap SERVER_NAME_HERE ec2:register_instance -s loadbalancer=ELB_NAME_HERE

You need to specify the ELB when reregistering an instance, but not when deregistering. This can also be done automatically using the :load_balanced setting (see the 'Configuration' section above).

Connecting to an Instance via SSH

Using the cap ec2:ssh command, you can quickly connect to a specific instance, by checking the listing from ec2:status and using the instance number as a parameter, for example:

cap ec2:ssh 1

will attempt to connect to instance number 1 (as shown in ec2:status), using the public DNS address provided by AWS and the first SSH key listed in ssh_options[:keys].

Other Commands

Running the following command:

cap ec2:date

Will execute the 'date' command on all instances that match your configuration (projects and roles). You can limit this further by using a role, for example:

cap web ec2:date

Will restrict the 'date' command so it is only run on instances that are tagged with the 'web' role. You can chain many roles together to increase the scope of the command:

cap web db ec2:date

You can use the 'Name' tag of an EC2 instance to limit the scope of the command to an individual instance:

cap server-1 ec2:date

Cap Invoke

You can use the standard Capistrano invoke task to run an arbitrary command on your instances, for example:

cap COMMAND='uptime' invoke

Will run the 'uptime' command on all instances that match your configuration (projects and roles). As with the ec2:date command, you can further limit this by using a role, like so:

cap web COMMAND='uptime' invoke

You can also chain many roles together to increase the scope of the command:

cap web db COMMAND='uptime' invoke

As with ec2:date, you can use the 'Name' tag of an EC2 instance to limit the scope of the command to an individual instance:

cap server-1 COMMAND='uptime' invoke

Cap Shell

You can use the standard Capistrano shell task to open an interactive terminal session with your instances, for example:

cap shell

Will open an interactive terminal on all instances that match your configuration (projects and roles). You can of course limit the scope of the shell to a certain role or roles like so:

cap web shell

cap web db shell

Multistage

You can use the Capistrano Multistage Extension to manage deployments to multiple environments.

Configuration

You can set the tag name that Capify-EC2 will use to filter your server list by using the :aws_stages_tag. It defaults to 'Stages'.

Usage

In our examples, imagine that you have three servers on EC2 named and tagged as follows:

'Name' Tag	'Roles' Tag	'Options' Tag	'Stages' Tag
server-1	web	cron,resque	production
server-2	db		production
server-3	web,db		staging

And you have the following 2 stages setup using Capistrano Multistage.

production.rb

ec2_roles name: :web
ec2_roles name: :db

staging.rb

ec2_roles name: :web
ec2_roles name: :db

This will generate the following for production

namespace :production do
  task :server-1 do
    role :web, SERVER-1_EC2_PUBLIC_DNS_HERE, :cron=>true, :resque=>true
  end

  task :server-2 do
    role :db, SERVER-2_EC2_PUBLIC_DNS_HERE
  end

  task :web do
    role :web, SERVER-1_EC2_PUBLIC_DNS_HERE, :cron=>true, :resque=>true
  end

  task :db do
    role :db, SERVER-2_EC2_PUBLIC_DNS_HERE
  end
end

namespace :staging do
  task :server-3 do
    role :web, SERVER-3_EC2_PUBLIC_DNS_HERE
    role :db, SERVER-3_EC2_PUBLIC_DNS_HERE
  end

  task :web do
    role :web, SERVER-3_EC2_PUBLIC_DNS_HERE
  end

  task :db do
    role :db, SERVER-3_EC2_PUBLIC_DNS_HERE
  end
end

With the above config you can deploy to production using cap production deploy.

You will also need to add the environment when running other ec2 commands like ec2:status, for example: cap production ec2:status

Development

Source hosted at GitHub. Report Issues/Feature requests on GitHub Issues.

Note on Patches/Pull Requests

• Fork the project.
• Make your feature addition or bug fix.
• Add tests for it. This is important so I don't break it in a future version unintentionally.
• Commit, do not change the version, or changelog. (if you want to have your own version, that is fine but bump version in a commit by itself so I can ignore it when I pull)
• Send me a pull request. Bonus points for topic branches.

Copyright

Copyright (c) 2011, 2012, 2013, 2014 Forward. See LICENSE for details.

capify-ec2's Issues

Rolling deploy removes instances from ELB on a dry-run

Running cap rolling_deploy -n removes instances from its ELBs. When doing a dry-run I expect capistrano not to make any changes on the target system(s).

Documentation says [:aws_params][:regions] and [:project_tag] are optional, but the code seems to disagree

] cap -T
/Users/joemsak/.rvm/gems/ruby-1.9.3-p0@pdocs/gems/capify-ec2-1.1.16.pre.2/lib/capify-ec2.rb:15:in determine_regions': undefined method[]' for nil:NilClass (NoMethodError)

line 15 of capify-ec2.rb
region.nil? ? (ec2_config[:aws_params][:regions] || [ec2_config[:aws_params][:region]]) : [region]

Issue when having multiple roles and variables in each

If I define two roles:

ec2_roles   :name => :apiserver,
            :options => {:default=>true} ,
            :variables => {
                :domain => "apiserver.dev.instamotor.com",
                :thin_server_tag => "apiserver",
                :rackup_path => "apiserver/config.ru"
            }
ec2_roles   :name => :telegraph,
            :options => {:default=>true} ,
            :variables => {
                :domain => "telegraph.dev.instamotor.com",
                :thin_server_tag => "telegraph",
                :rackup_path => "telegraph/config.ru"
            }

And then have two tasks defined:

task :restart_apiserver, :roles => [:apiserver], :on_no_matching_servers => :continue do 
    thin_config_path = "#{current_path}/config/server/thin.#{domain}.yml"
    thin_rackup_path = "#{current_path}/#{rackup_path}"
    restart_thin  = "cd #{current_path} && bundle exec thin -C #{thin_config_path} -R #{thin_rackup_path} restart >> #{current_path}/log/#{thin_server_tag}.thin.log 2>&1"
    restart_nginx = "sudo service nginx restart" 

    run "#{restart_thin}"
    run "#{restart_nginx}"
end
task :restart_telegraph, :roles => [:telegraph] , :on_no_matching_servers => :continue do 
    thin_config_path = "#{current_path}/config/server/thin.#{domain}.yml"
    thin_rackup_path = "#{current_path}/#{rackup_path}"
    restart_thin  = "cd #{current_path} && bundle exec thin -C #{thin_config_path} -R #{thin_rackup_path} restart >> #{current_path}/log/#{thin_server_tag}.thin.log 2>&1"
    restart_nginx = "sudo service nginx restart" 

    run "#{restart_thin}"
    run "#{restart_nginx}"
end

When I call

cap integration telegraph apiserver deploy:restart

Only the apiserver variables get set in both the telegraph task and the apiserver task so both tasks end up calling the command

"cd /home/ubuntu/current && bundle exec thin -C /home/ubuntu/current/config/server/thin.apiserver.dev.instamotor.com.yml -R /home/ubuntu/current/apiserver/config.ru restart >> /home/ubuntu/current/log/apiserver.thin.log 2>&1"

Documentation says [:aws_params][:regions] and [:project_tag] are optional, but the code seems to disagree

] cap -T
/Users/joemsak/.rvm/gems/ruby-1.9.3-p0@pdocs/gems/capify-ec2-1.1.16.pre.2/lib/capify-ec2.rb:15:in determine_regions': undefined method[]' for nil:NilClass (NoMethodError)

line 15 of capify-ec2.rb
region.nil? ? (ec2_config[:aws_params][:regions] || [ec2_config[:aws_params][:region]]) : [region]

undefined method `to_sym' for nil:NilClass

I have a very simple configuration file for two EC2 instances running behind an ELB.

:aws_access_key_id: "(redacted)"
:aws_secret_access_key: "(redacted)"
:aws_params:
  :region: 'eu-west-1'
:project_tag: "foo"

Here's my deploy.rb:

require "capify-ec2/capistrano"

set :application, "(redacted)"
set :repository,  "(redacted)"

ec2_roles :web,
          :variables => {
            :load_balanced => true
          }

set :deploy_to, "/var/www"

Now, running cap ec2:status works fine as long as I don't have the :variables hash there, but as soon as I include it, I get:

/var/lib/gems/1.9.1/gems/capify-ec2-1.5.1/lib/capify-ec2/capistrano.rb:277:in `define_role_roles': undefined method `to_sym' for nil:NilClass (NoMethodError)
    from /var/lib/gems/1.9.1/gems/capify-ec2-1.5.1/lib/capify-ec2/capistrano.rb:249:in `ec2_role'
    from /var/lib/gems/1.9.1/gems/capify-ec2-1.5.1/lib/capify-ec2/capistrano.rb:231:in `block in ec2_roles'
    from /var/lib/gems/1.9.1/gems/capify-ec2-1.5.1/lib/capify-ec2/capistrano.rb:231:in `each'
    from /var/lib/gems/1.9.1/gems/capify-ec2-1.5.1/lib/capify-ec2/capistrano.rb:231:in `ec2_roles'
    from ./config/deploy.rb:10:in `load'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/configuration/loading.rb:93:in `instance_eval'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/configuration/loading.rb:93:in `load'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/configuration/loading.rb:180:in `load_from_file'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/configuration/loading.rb:89:in `load'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/configuration/loading.rb:86:in `block in load'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/configuration/loading.rb:86:in `each'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/configuration/loading.rb:86:in `load'
    from Capfile:4:in `load'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/configuration/loading.rb:93:in `instance_eval'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/configuration/loading.rb:93:in `load'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/configuration/loading.rb:180:in `load_from_file'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/configuration/loading.rb:89:in `load'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/configuration/loading.rb:86:in `block in load'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/configuration/loading.rb:86:in `each'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/configuration/loading.rb:86:in `load'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/cli/execute.rb:65:in `block in load_recipes'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/cli/execute.rb:65:in `each'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/cli/execute.rb:65:in `load_recipes'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/cli/execute.rb:31:in `execute!'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/cli/execute.rb:14:in `execute'
    from /var/lib/gems/1.9.1/gems/capistrano-2.15.5/bin/cap:4:in `<top (required)>'
    from /usr/local/bin/cap:19:in `load'
    from /usr/local/bin/cap:19:in `<main>'

My instances have the web roles defined:

I'm on Ubuntu 12.04 with Rails 1.9.3p0.

Cannot figure out syntax for registering and deregistering instances

Assuming the following setup:

ec2_roles ({ 
  :name => "web", 
  :variables => {
    :load_balanced => true
    },
   :options => {
    :default => true
   }
  })

… and this status:

Project: foo.
Num   Name        ID           Type        DNS                                                  Zone         Roles
00:   fooweb2   i-5bd3ef17   m1.medium   fooweb2.eu-west-1.compute.amazonaws.com     eu-west-1b   web
01:   fooweb1   i-dd824992   m1.medium   fooweb1.eu-west-1.compute.amazonaws.com   eu-west-1a   web

How would I go about deregistering either of those instances? I've tried cap ec2:deregister_instance, but it doesn't print anything other than the task name, or result in anything.

I've also tried – similar to the cap ec2:ssh syntax:

cap ec2:deregister_instance 0
  * 2013-11-11 10:06:43 executing `ec2:register_instance'
the task `0' does not exist

I've tried this.. but it tries to execute two tasks:

± % cap 'fooweb2' ec2:deregister_instance
  * 2013-11-11 10:09:42 executing `fooweb2'
  * 2013-11-11 10:09:42 executing `ec2:deregister_instance'

I use the latest stable Capistrano 2.15.5. (Not sure if I can just upgrade to 3.0. Don't want to risk anything breaking.)

Get the current instance name in deploy.rb?

Hey guys,

first, thank you very much for this great work!

I'm using Capistrano to deploy my application on EC2 and run a masterless puppet environment. The current problem is that i need the current EC2 Instance Name (displayed when you execute "cap ec2:status" in the name section) to provision my servers with puppet like this:

namespace :puppet do
   task :provision do
      sudo("puppet apply --node_name_value=#{ec2.instance_name} #{current_path}/puppet/manifests/site.pp")
   end
end

So is there any chance to get the name of the EC2 instance capify currently deploying?

Thanks a lot for your help
Stephan

List of servers

Is it possible to get a list of servers in a particular Role in some sort of variable?
As an example, I need to rsync something to all servers with the Role: web in a custom task. Currently I have 4 rsync run commands, one for each server - but obviously this isn't dynamic.

Fog dependency

Is there a particular reason fog is locked at 1.3.1 in the gemspec? That version is over a year old and the hard version lock will undoubtedly cause dependency resolution problems for people.

Can the required fog version be bumped up to something more recent, like, say, ~> 1.10.0?

Creating AMI

Hi,

have you thought about the issue of autoscaling?

What would be the correct procedure?

1. stop autoscaling
2. deploy
3. create new ami
4. re-enable autoscaling

Options doesn't seem to be working

Options tagged on the ec2 instance dno't seem to come through. I believe it may be down to the following in capistrano.rb:123

instance.tags["Options"].each do |option| 
  results = option.split(',')
  results.each {|result| new_options[result.to_sym] = true }
end rescue false

I don't believe instance.tags["Options"] is an array. I think this should be

instance.tags["Options"].split(',').each do |option|
  new_options[option.to_sym] = true
end

Not 100% sure as I'm running off the Gem which is behind the current code so is not using tags

-Mark

Task doesn't find servers by role (multistage)

I have this task:

namespace :ec2 do
  task :test_boot, roles: :boot do
    run "echo HELLO!"
  end
end

When I try to run it, I get the error

    triggering load callbacks
  * 2013-10-09 14:57:57 executing `staging'
    triggering start callbacks for `ec2:test_boot'
  * 2013-10-09 14:57:58 executing `multistage:ensure'
  * 2013-10-09 14:57:58 executing `ec2:test_boot'
`ec2:test_boot' is only run for servers matching {:roles=>:boot}, but no servers matched

Here's the output of cap ec2:status

    triggering load callbacks
  * 2013-10-09 15:00:07 executing `staging'
    triggering start callbacks for `ec2:status'
  * 2013-10-09 15:00:08 executing `multistage:ensure'
  * 2013-10-09 15:00:08 executing `ec2:status'
 Stages: staging.
Num   Name           ID    Type        DNS                               Zone         Stages    Roles
00:   Staging        i-*   m1.medium   ec2-***.compute-1.amazonaws.com   us-east-1b   staging   app
01:   staging_boot   i-*   m1.medium   ec2-***.compute-1.amazonaws.com   us-east-1b   staging   boot

And here's my staging.rb:

ec2_roles name: :boot

I know this is getting picked up because I can execute a "cap boot ec2:status", and if I remove the "ec2_roles :boot" line I get a missing task error on that. Am I missing something here? Thanks!

License missing from gemspec

Some companies will only use gems with a certain license.
The canonical and easy way to check is via the gemspec
via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Bundler now generates gems with a default 'MIT' license. There is even a License Finder
to help companies ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec.
Including a license in your gemspec is a good practice, in any case.

If you need help choosing a license, github has created a license picker tool

How did I find you?

I'm using a script to collect stats on gems, originally looking for download data, but decided to collect licenses too,
and make issues for gemspecs not specifying a license as a public service :)
So far it's going pretty well.
I've written a blog post about it

Assumes only one ELB per instance

Hiya,

We have an environment where individual instances are running multiple servers behind multiple load balancers (mostly for cost saving).

I think Capify-ec2 assumes that each instance only belongs to one load balancer.

For instance:
We have two environments, dev and staging. They both run on the same instance. This instance has two load balancers, one for dev and one for staging, pointing to different ports with different health checks.

During a deployment of staging the degreister_instance_from_elb_by_dns de-registered the instance from the dev ELB.

I have a couple of ideas on solutions, but imagine it could get pretty complicated pretty quick.

• The simplest would be to deregister from all ELBs, but that isn't quite right.
• An alternative would be to accept another parameter alongside :load_balanced which provides a regex or name of the ELB that can be deregistered from.
• A final idea would be to reuse the health check: i.e. get all ELBs that this instance is part of, and using the health checks from each role deregister it if there is a match between the ELB list and the health check list.

Let me know your thoughts - I'll see if I can prototype something when I get some time.

Cheers,
Ed

undefined local variable or method user

https://github.com/forward/capify-ec2/blob/master/lib/capify-ec2/capistrano.rb#L43

Where is user supposed to be set? (cap novice, not sure if it originates elsewhere)

nodename nor servname provided

thanks for the project. haven't been able to get it to work though. i created the ec2.yml file, and added the following to deploy.rb

require "capify-ec2/capistrano"
ec2_role :web

all i get is the following error:

/Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/excon-0.13.4/lib/excon/socket.rb:26:in getaddrinfo': getaddrinfo: nodename nor servname provided, or not known (Excon::Errors::SocketError) from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/excon-0.13.4/lib/excon/socket.rb:26:inconnect'
from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/excon-0.13.4/lib/excon/socket.rb:16:in initialize' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/excon-0.13.4/lib/excon/ssl_socket.rb:31:ininitialize'
from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/excon-0.13.4/lib/excon/connection.rb:326:in new' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/excon-0.13.4/lib/excon/connection.rb:326:insocket'
from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/excon-0.13.4/lib/excon/connection.rb:171:in request_kernel' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/excon-0.13.4/lib/excon/connection.rb:97:inrequest'
from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/fog-1.3.1/lib/fog/core/connection.rb:20:in request' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/fog-1.3.1/lib/fog/aws/compute.rb:320:inrequest'
from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/fog-1.3.1/lib/fog/aws/requests/compute/describe_instances.rb:75:in describe_instances' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/fog-1.3.1/lib/fog/aws/models/compute/servers.rb:64:inall'
from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/fog-1.3.1/lib/fog/core/collection.rb:131:in lazy_load' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/fog-1.3.1/lib/fog/core/collection.rb:18:ineach'
from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capify-ec2-1.2.8/lib/capify-ec2.rb:28:in block in initialize' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capify-ec2-1.2.8/lib/capify-ec2.rb:25:ineach'
from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capify-ec2-1.2.8/lib/capify-ec2.rb:25:in initialize' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capify-ec2-1.2.8/lib/capify-ec2/capistrano.rb:6:innew'
from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capify-ec2-1.2.8/lib/capify-ec2/capistrano.rb:6:in capify_ec2' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capify-ec2-1.2.8/lib/capify-ec2/capistrano.rb:74:inec2_role'
from ./config/deploy.rb:42:in load' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/lib/capistrano/configuration/loading.rb:93:ininstance_eval'
from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/lib/capistrano/configuration/loading.rb:93:in load' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/lib/capistrano/configuration/loading.rb:172:inload_from_file'
from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/lib/capistrano/configuration/loading.rb:89:in load' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/lib/capistrano/configuration/loading.rb:86:inblock in load'
from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/lib/capistrano/configuration/loading.rb:86:in each' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/lib/capistrano/configuration/loading.rb:86:inload'
from Capfile:8:in load' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/lib/capistrano/configuration/loading.rb:93:ininstance_eval'
from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/lib/capistrano/configuration/loading.rb:93:in load' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/lib/capistrano/configuration/loading.rb:172:inload_from_file'
from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/lib/capistrano/configuration/loading.rb:89:in load' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/lib/capistrano/configuration/loading.rb:86:inblock in load'
from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/lib/capistrano/configuration/loading.rb:86:in each' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/lib/capistrano/configuration/loading.rb:86:inload'
from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/lib/capistrano/cli/execute.rb:65:in block in load_recipes' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/lib/capistrano/cli/execute.rb:65:ineach'
from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/lib/capistrano/cli/execute.rb:65:in load_recipes' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/lib/capistrano/cli/execute.rb:31:inexecute!'
from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/lib/capistrano/cli/execute.rb:14:in execute' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/gems/capistrano-2.12.0/bin/cap:4:in<top (required)>'
from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/bin/cap:19:in load' from /Users/haider/.rvm/gems/ruby-1.9.3-p125@rails32/bin/cap:19:in

'

Doesn't work for Capistrano v3

The current gem does not work with Capistrano v3

Unable to use server name as task

When I try and use the auto-generated task from the server name, I get an error:

thunder:leaddyno-app machado$ cap web1 ec2:date
  * 2013-06-22 21:56:30 executing `web1'
/Users/machado/.rvm/gems/ruby-1.9.3-p392@leaddyno-app/gems/capify-ec2-1.4.11/lib/capify-ec2/capistrano.rb:216:in `block in ec2_roles': undefined method `[]' for nil:NilClass (NoMethodError)
    from /Users/machado/.rvm/gems/ruby-1.9.3-p392@leaddyno-app/gems/capistrano-2.15.4/lib/capistrano/configuration/execution.rb:138:in `instance_eval'
    from /Users/machado/.rvm/gems/ruby-1.9.3-p392@leaddyno-app/gems/capistrano-2.15.4/lib/capistrano/configuration/execution.rb:138:in `invoke_task_directly'
    from /Users/machado/.rvm/gems/ruby-1.9.3-p392@leaddyno-app/gems/capistrano-2.15.4/lib/capistrano/configuration/callbacks.rb:25:in `invoke_task_directly_with_callbacks'
    from /Users/machado/.rvm/gems/ruby-1.9.3-p392@leaddyno-app/gems/capistrano-2.15.4/lib/capistrano/configuration/execution.rb:89:in `execute_task'
    from /Users/machado/.rvm/gems/ruby-1.9.3-p392@leaddyno-app/gems/capistrano-2.15.4/lib/capistrano/configuration/execution.rb:101:in `find_and_execute_task'
    from /Users/machado/.rvm/gems/ruby-1.9.3-p392@leaddyno-app/gems/capistrano-2.15.4/lib/capistrano/cli/execute.rb:46:in `block in execute_requested_actions'
    from /Users/machado/.rvm/gems/ruby-1.9.3-p392@leaddyno-app/gems/capistrano-2.15.4/lib/capistrano/cli/execute.rb:45:in `each'
    from /Users/machado/.rvm/gems/ruby-1.9.3-p392@leaddyno-app/gems/capistrano-2.15.4/lib/capistrano/cli/execute.rb:45:in `execute_requested_actions'
    from /Users/machado/.rvm/gems/ruby-1.9.3-p392@leaddyno-app/gems/capistrano-2.15.4/lib/capistrano/cli/help.rb:19:in `execute_requested_actions_with_help'
    from /Users/machado/.rvm/gems/ruby-1.9.3-p392@leaddyno-app/gems/capistrano-2.15.4/lib/capistrano/cli/execute.rb:34:in `execute!'
    from /Users/machado/.rvm/gems/ruby-1.9.3-p392@leaddyno-app/gems/capistrano-2.15.4/lib/capistrano/cli/execute.rb:14:in `execute'
    from /Users/machado/.rvm/gems/ruby-1.9.3-p392@leaddyno-app/gems/capistrano-2.15.4/bin/cap:4:in `'
    from /Users/machado/.rvm/gems/ruby-1.9.3-p392@leaddyno-app/bin/cap:19:in `load'
    from /Users/machado/.rvm/gems/ruby-1.9.3-p392@leaddyno-app/bin/cap:19:in `'
    from /Users/machado/.rvm/gems/ruby-1.9.3-p392@leaddyno-app/bin/ruby_noexec_wrapper:14:in `eval'
    from /Users/machado/.rvm/gems/ruby-1.9.3-p392@leaddyno-app/bin/ruby_noexec_wrapper:14:in `'
thunder:leaddyno-app machado$ cap ec2:date
  * 2013-06-22 21:56:35 executing `ec2:date'
  * executing "date"
    servers: ["ec2-5x-1x-3x-1x.compute-1.amazonaws.com"]
    [ec2-5x-1x-3x-1x.compute-1.amazonaws.com] executing command
 ** [out :: ec2-5x-1x-3x-1x.compute-1.amazonaws.com] Sun Jun 23 04:56:38 UTC 2013
    command finished in 1383ms
thunder:leaddyno-app machado$ cap ec2:status
  * 2013-06-22 21:56:45 executing `ec2:status'
Project: leaddyno-app.
Num   Name   ID           Type        DNS                                        Zone         Roles     Options
00:   web1   i-xxxxx   m1.medium   ec2-5x-1x-3x-1x.compute-1.amazonaws.com   us-east-1b   app,web
thunder:leaddyno-app machado$

It looks like @ec2_config is not a valid instance variable in lib/capify-ec2/capistrano.rb. I tried to replace

@ec2_config[:aws_roles_tag]

with

capify_ec2.ec2_config[:aws_roles_tag]

But that results in the raw comma-separated list of roles, not an array, that line 216 is expecting. I didn't dig too deep, I assume there is an array version of the server's roles in one of the data structures, but I didn't go digging.

I am running version 1.4.11.

Being able to execute cap tasks on just a single server is super handy, so I hope this gets fixed soon! Thanks for the excellent gem, it makes my rolling deploys a breeze!

cap servername deploy isnt working when servername has multiple roles

The deploy:assets:symlink task fails when doing a single server deploy to a server that has multiple roles (including the role that matches assets_role).

At first my server had "Roles" set to "app,db" and got the below error. When I edited the "Roles" aws tag to only have 'app', the deploy worked. I have assets_role defined as :app. So it seems something is not registering the server under the 'app' role when it is listed as having multiple roles.

I made sure the following was also in my deploy.rb:

ec2_roles :name=>:app, :options => {:default=>true}
ec2_roles :name=>:db, :options => {:default=>true}

When running "cap server1 deploy", I get the following error:

*** [deploy:update_code] rolling back

• executing "rm -rf /home/ubuntu/apps/myapp/releases/20130918175119; true"
  servers: ["ecxxxxxxxx.compute-1.amazonaws.com"]
  [ecxxxxxxxx.compute-1.amazonaws.com] executing command
  command finished in 920ms
  `deploy:assets:symlink' is only run for servers matching {:roles=>#<Proc:0x007f9e648bdf08@/Users/machado/.rvm/gems/ruby-1.9.3-p392@leaddyno-app/gems/capistrano-2.15.5/lib/capistrano/recipes/deploy/assets.rb:42 (lambda)>, :except=>{:no_release=>true}}, but no servers matched

Error on deploy

What could cause this issue?

$cap staging deploy
  * 2014-08-28 18:07:22 executing `staging'
  * 2014-08-28 18:07:23 executing `multistage:ensure'
  * 2014-08-28 18:07:23 executing `deploy'
  * 2014-08-28 18:07:23 executing `ec2:deregister_instance'
  * 2014-08-28 18:07:23 executing `deploy:update'
 ** transaction: start
  * 2014-08-28 18:07:23 executing `deploy:update_code'
--> Updating code base with checkout strategy
*** [deploy:update_code] rolling back
 ** [deploy:update_code] exception while rolling back: Capistrano::NoMatchingServersError, `deploy:update_code' is only run for servers matching {:except=>{:no_release=>true}}, but no servers matched
`deploy:update_code' is only run for servers matching {:except=>{:no_release=>true}}, but no servers matched

Thanks.

Weired bug

I keep getting this message.

ec2:date' is only run for servers matching {}, but no servers matched

I have exactly followed your description.

Feature request: Enable Roles and Options separator config (instead of comma)

I'm using CLI from Amazon Auto Scaling Command Line Tool and it seems I can't create tag values with comma as separator. I have something like this with the CLI

$AWS_AUTO_SCALING_HOME/bin/as-create-auto-scaling-group WebAppScalingGroup --launch-configuration WebAppLaunchConfig --availability-zones us-east-1a --min-size 1 --max-size 20 --load-balancers LoadBalancer --tag "k=Name, v=MyProject-WebApp, p=true" --tag "k=Project, v=MyProject, p=true" --tag "k=Roles, v=web,app, p=true"

and the error is:

as-create-auto-scaling-group:  Malformed input-No value separator = found in app

The error seems to be here:
https://forums.aws.amazon.com/message.jspa?messageID=331304

If we can set it to different separator like | or other characters then it would be the best to overcome the issue of AWS CLI tools. What do you think?

Different path for ec2.yml

Is there a way to load ec2.yml from a different path that the default one config/ec2.yml?

Failure on execution of custom tasks with "Options" dependencies

When I place a options related task (same as in the documentation) in my deploy.rb:

task :reload_workers => :web, :only=>{:worker=>true} do
  # Do something to a specific server with the 'worker' option in it's EC2 tags.
end

After adding these lines I receive the following error (the role "web" exist and the option "worker" also):

.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/configuration/namespaces.rb:91:in `task': undefined method `to_sym' for {:reload_workers=>:web, :only=>{:worker=>true}}:Hash (NoMethodError)
    from ./config/deploy.rb:35:in `load'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/configuration/loading.rb:93:in `instance_eval'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/configuration/loading.rb:93:in `load'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/configuration/loading.rb:172:in `load_from_file'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/configuration/loading.rb:89:in `load'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/configuration/loading.rb:86:in `block in load'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/configuration/loading.rb:86:in `each'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/configuration/loading.rb:86:in `load'
    from Capfile:4:in `load'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/configuration/loading.rb:93:in `instance_eval'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/configuration/loading.rb:93:in `load'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/configuration/loading.rb:172:in `load_from_file'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/configuration/loading.rb:89:in `load'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/configuration/loading.rb:86:in `block in load'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/configuration/loading.rb:86:in `each'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/configuration/loading.rb:86:in `load'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/cli/execute.rb:65:in `block in load_recipes'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/cli/execute.rb:65:in `each'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/cli/execute.rb:65:in `load_recipes'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/cli/execute.rb:31:in `execute!'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/lib/capistrano/cli/execute.rb:14:in `execute'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/gems/capistrano-2.15.3/bin/cap:4:in `<top (required)>'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/bin/cap:19:in `load'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/bin/cap:19:in `<main>'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/bin/ruby_noexec_wrapper:14:in `eval'
    from /Users/ssalat/.rvm/gems/ruby-1.9.3-p392/bin/ruby_noexec_wrapper:14:in `<main>'

Any ideas?

"but no servers matched" for :db task

I've had this problem for awhile and have decided it's time to get to the bottom of it. Currently get the error:

`deploy:migrate' is only run for servers matching {:roles=>:db, :only=>{:primary=>true}}, but no servers matched

when I run cap production deploy:migrate

My deploy file has;

   ec2_roles :name => :db,           :options => { :default=>true }

and the db server shows up in cap production ec2:status and also when I do a puts roles.inspect from within a dummy task.

Any ideas?