2011-06-07 24 views
7

Parece que Capistrano no funciona bien con AmazonRDS. He buscado por todos lados información sobre cómo configurar esto correctamente, pero no he encontrado ninguno. En este momento, cuando yo cap deploy, el proceso expira.Capistrano agota el tiempo de implementación con Amazon RDS

Esta es mi deploy.rb:

set :deploy_to, "/opt/bitnami/apps/annarbortshirtcompany.com/cms/" 
set :scm, :git 
set :repository, "ssh://[email protected]/~/repo/cms.git" 
set :deploy_via, :remote_cache 

set :user, "user" 
ssh_options[:keys] = [File.join(ENV["HOME"], "EC2", "admin.pem")] 
ssh_options[:forward_agent] = true 
set :branch, "master" 
set :use_sudo, true 

set :location, "ec2-webserver.compute-1.amazonaws.com" 
role :web, location 
role :app, location 
role :db, "cmsinstance.c7r8frl6npxn.us-east-1.rds.amazonaws.com", :primary => true 

# If you are using Passenger mod_rails uncomment this: 
namespace :deploy do 
    task :start do ; end 
    task :stop do ; end 
    task :restart, :roles => :app, :except => { :no_release => true } do 
    run "#{try_sudo} touch #{File.join(current_path,'tmp','restart.txt')}" 
    end 
end 

El nombre de usuario para la instancia de base de datos RDS difiere del nombre de usuario SSH establecido aquí, sino que se define en mi database.yml. Me imagino que esto probablemente no está siendo leído por capistrano, pero no tengo idea de cómo hacer que eso suceda.

Cuando "desplegar la tapa":

[email protected]:~/RailsApps/cms$ cap deploy 
    * executing `deploy' 
    * executing `deploy:update' 
** transaction: start 
    * executing `deploy:update_code' 
    updating the cached checkout on all servers 
    executing locally: "git ls-remote ssh://[email protected]/~/repo/cms.git master" 
    command finished in 1590ms 
    * executing "if [ -d /app-directory/shared/cached-copy ]; then cd /app-directory/shared/cached-copy && git fetch -q origin && git fetch --tags -q origin && git reset -q --hard ffc4ec7762566f801c4a9140aa3980dc71e3d06f && git clean -q -d -x -f; else git clone -q ssh://[email protected]/~/repo/cms.git /app-directory/shared/cached-copy && cd /app-directory/shared/cached-copy && git checkout -q -b deploy ffc4ec7762566f801c4a9140aa3980dc71e3d06f; fi" 
    servers: ["ec2-webserver.compute-1.amazonaws.com", "dbinstance.us-east1.rds.amazonaws.com"] 
*** [deploy:update_code] rolling back 
    * executing "rm -rf /app-directory/releases/20110607161612; true" 
    servers: ["ec2-webserver.compute-1.amazonaws.com", "dbinstance.us-east1.rds.amazonaws.com"] 
** [deploy:update_code] exception while rolling back: Capistrano::ConnectionError, connection failed for: dbinstance.us-east1.rds.amazonaws.com (Errno::ETIMEDOUT: Connection timed out - connect(2)) 
    connection failed for: dbinstance.us-east1.rds.amazonaws.com (Errno::ETIMEDOUT: Connection timed out - connect(2)) 

¿Por qué se quiere "actualizar la caja en caché en todos los servidores"? El servidor DB aún no debería ser necesario en este punto. Estoy perplejo sobre cómo solucionar esto. ¡Espero que alguien pueda señalarme en la dirección correcta!

+0

aclarar, todo funciona muy bien cuando se apunta a la base de datos ': location' en lugar de la instancia RDS –

Respuesta

25

Tuve exactamente este problema y luché con él por lo que me da vergüenza decir que fue un buen 5 o 6 horas. Al final, cuando me di cuenta de cuál era el problema, tuve ganas de pegarme porque sabía esto una vez, pero lo había olvidado. Aquí está el quid de la cuestión, a partir de esta parte de deploy.rb:

set :location, "ec2-webserver.compute-1.amazonaws.com" 
role :web, location 
role :app, location 
role :db, "cmsinstance.c7r8frl6npxn.us-east-1.rds.amazonaws.com", :primary => true 

Al definir las funciones de la máquina de Capistrano, usted no está realmente identificar qué equipos jugarán un papel particular ... más bien, está identificando en qué máquinas se ejecutará el código de Capistrano al aplicar una receta de implementación para un rol. Por lo tanto, cuando define el rol: db, desea apuntar a su instancia de EC2, , no a, la instancia de RDS. No puede ingresar a la máquina RDS, por lo que es imposible que Capistrano ejecute una receta allí. En su lugar, el punto: db a la misma máquina que usted está señalando: web y: aplicación, es decir

set :location, "ec2-webserver.compute-1.amazonaws.com" 
role :web, location 
role :app, location 
role :db, location, :primary => true 

¿Cómo funciona la máquina de RDS a continuación tienen ninguna participación? Bueno, es el archivo database.yml el que dicta qué máquina está realmente ejecutando el RDBMS donde el SQL necesita ser ejecutado. Sólo tiene que asegurarse de que está configurando el host: el valor de datos de destino, por ejemplo .:

production: 
    adapter: mysql2 
    encoding: utf8 
    reconnect: false 
    database: <your_db>_production 
    pool: 5 
    username: <username> 
    password: <password> 
    host: cmsinstance.c7r8frl6npxn.us-east-1.rds.amazonaws.com 

sentido?

Espero que esto salve a alguien más la frustración que experimenté.

  • David
+2

David, esto es exactamente lo! Espero que alguien más evite nuestra trampa debido a su respuesta. –

+0

De hecho, configure el grupo de seguridad para que la instancia RDS lo acepte en el puerto MySQL. –

+0

David, seguí tus consejos ... gracias, muy claro ... sin embargo tengo un problema en la implementación, en la tarea db: migrate ... > Mysql2 :: Error: Acceso denegado para el usuario 'root'@'172.31. 11.0 '(usando la contraseña: NO) parece que no tiene en cuenta la base de datos.yml acredita ... tratando de acceder al RDS db con el usuario root @ la' instancia ec2 ' – erwin

Cuestiones relacionadas