Capistrano expire lors du déploiement avec Amazon RDS

Question

Je n'arrive pas à faire en sorte que Capistrano fonctionne correctement avec AmazonRDS. J'ai regardé partout pour toutes les informations sur la mise en place correctement, mais n'en ai pas trouvé. En ce moment, quand je cap deploy, le processus expire.

Ceci est mon deploy.rb:

set :deploy_to, "/opt/bitnami/apps/annarbortshirtcompany.com/cms/" 
set :scm, :git 
set :repository, "ssh://user@ec2-repository.compute-1.amazonaws.com/~/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 

Le nom d'utilisateur pour l'instance de base de données RDS est différent du nom d'utilisateur SSH défini ici, mais il est défini dans mon database.yml. Je me dis que Capistrano ne l'a probablement pas lu, mais je ne sais pas comment y arriver.

Quand je "deploy cap":

ubuntu@ubuntu-VirtualBox:~/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://user@ec2-repository.compute-1.amazonaws.com/~/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://user@ec2-repository.amazonaws.com/~/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)) 

Pourquoi faudrait-il vouloir "mettre à jour la caisse en cache sur tous les serveurs"? Le serveur de base de données ne devrait même pas être nécessaire à ce stade. Je suis perplexe sur la façon de résoudre ce problème. J'espère que quelqu'un peut me diriger dans la bonne direction!

Answer 1

J'ai eu ce problème exactement et lutté avec lui pour ce que je suis gêné de dire était un bon 5 ou 6 heures. En fin de compte, quand j'ai réalisé quel était le problème, j'avais envie de me claquer parce que je le savais une fois mais que je l'avais oublié. Voici le nœud du problème, à commencer par cette partie 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 

Lorsque vous définissez les rôles de la machine pour Capistrano, vous n'êtes pas d'identifier réellement les machines à jouer un rôle particulier ... plutôt, vous identifiez sur quelles machines le code Capistrano s'exécutera lors de l'application d'une recette de déploiement pour un rôle. Ainsi, lorsque vous définissez le rôle: db, vous souhaitez pointer vers votre instance EC2, et non l'instance RDS. Vous ne pouvez pas entrer dans la machine RDS, il est impossible pour Capistrano d'y exécuter une recette. Au lieu de cela, le point: db à la même machine que vous pointez: web et: l'application, à savoir

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

Comment la machine RDS puis ont toute implication? Eh bien, c'est le fichier database.yml qui dicte quelle machine exécute réellement le SGBDR où le SQL doit être exécuté. Vous avez juste besoin d'être sûr que vous définissez l'hôte: valeur pour la base de données cible, par exemple:

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 

Avez-vous un sens?

J'espère que cela sauvera quelqu'un d'autre la frustration que j'ai éprouvée.

• David