0

A rubber deployment as per quick start instruction using the latest 3.1.0 version reaches the stage of fetching and installing the gems (the last one loaded is pg), for an m1.small instance. I see no mention of therubyracer in the scroll of gems...

The process successfully completes deploy:setup, rubber:collectd:bootstrap, deploy:setup, deploy:update_code, but upon deploy:finalize_update the callback being triggered is bundle:install

Invariably, the process stalls at this point. The /etc/hosts/ file does refer to the proper configurations (52.25.135.252 production.foo.com ec2-52-25-135-252.us-west-2.compute.amazonaws.com ip-172-[...]).

One oddity is that trying to ssh into the the instance

ssh -i aws-eb production.foo.com

or via the ec-2 user

ssh -i aws-eb ec2-user@ec2-52-25-135-252.us-west-2.compute.amazonaws.com

the access is

Permission denied (publickey).

for a key that I was using with elastic beanstalk until a few days ago and had inserted into the confg/rubber/rubber.yml file.

I will attempt with a new key pair, but how can a key be now deemed public and unusable?

update setting up a new keypair does not alter any behaviour. Process stuck at same point, cannot ssh into the instance. The production.foo.com does properly return, what is configured to this point, the nginx on ubuntu welcome page

Jerome
  • 5,583
  • 3
  • 33
  • 76

1 Answers1

0

As far as I can tell, having iterated about 10 times over this, memory of the instance is the issue.

The smallest instance that has not choked at this point is image_type: m3.medium. AMIs per instance type can be found here

The automatic suggestion of an m1.small in the vulcanization of the application is optimistic in my opinion.

Jerome
  • 5,583
  • 3
  • 33
  • 76