2012-03-13 18 views
8

Cuando intento de desplegar mi aplicación con Capistrano, voy a conseguir este error:Capistrano - no puede desplegar mi database.yml

failed: "sh -c 'cp /var/www/my_app/releases/20120313115055/config/database.staging.yml /var/www/my_app/releases/20120313115055/config/database.yml'" on IP_ADDR

Mi database.yml es decir, vacía, database.staging .yml:

production: 
    adapter: mysql2 
    encoding: utf8 
    reconnect: false 
    database: my_db 
    pool: 15 
    username: my_user_name 
    password: my_pass 
    host: localhost 

en el /confing/desplegar son archivos "producción" "puesta en escena"

¿Qué me falta aquí/dónde debo buscar una falla? Las credenciales de la base de datos en el servidor deberían ser correctas.

EDITAR - aquí está mi implementar

set :application, "my_app" 
set :repository, "https://IP_ADDR/svn/my_app" 

set :scm, :subversion 
set :scm_username, 'my_name' 
set :scm_password, 'my_pass' 

default_run_options[:pty] = true 

set :user, "my_name" 
set :domain, 'IP_ADDR' 

set :deploy_to, "/var/www/my_app" 

set :use_sudo, false 
set :deploy_via, :remote_cache 
#set :keep_releases, 1 

set :rails_env, 'production' 

role :web, domain 
role :app, domain 
role :db, domain, :primary => true # This is where Rails migrations will run 

namespace :deploy do 

    task :build_gems, :roles => :app do 
     desc "Building gems" 
     run "cd #{release_path} && bundle install --deployment" 
    end 

    task :migrations do 
     desc "Migrating database" 
     run "cd #{release_path} && rake db:migrate RAILS_ENV=production" 
    end 

    [:start, :stop].each do |t| 
     desc "#{t} task is a no-op with passenger" 
     task t, :roles => :app do ; end 
    end 

    desc "Restarting passenger with restart.txt" 
    task :restart, :roles => :app, :except => { :no_release => true } do 
     run "touch #{release_path}/tmp/restart.txt" 
    end 

    after "deploy:update_code", "deploy:build_gems", "db:copy_configuration", "config:copy", "deploy:migrations", "deploy:cleanup" 
    after "deploy:update", "bluepill:copy_config", "bluepill:restart" 
end 

namespace :db do 
    task :copy_configuration do 
     run "cp #{release_path}/config/database.staging.yml #{release_path}/config/database.yml" 
    end 
end 

namespace :config do 
    task :copy do 
     run "cp #{release_path}/config/config.staging.yml #{release_path}/config/config.yml" 
    end 
end 

namespace :bluepill do 
    desc "Restart bluepill process" 
    task :restart, :roles => [:app] do 
    run "#{release_path}/script/delayed_job stop" 
    sudo "/etc/init.d/bluepill.sh restart" 
    end 

    #desc "Load bluepill configuration and start it" 
    ##task :start, :roles => [:app] do 
    # sudo "/etc/init.d/bluepill.sh start" 
    #end 

    desc "Prints bluepills monitored processes statuses" 
    task :status, :roles => [:app] do 
    sudo "bluepill status" 
    end 

    desc "Copy config" 
    task :copy_config, :roles => [:app] do 
    run "cp #{release_path}/config/bluepill/configuration.rb /srv/script/bluepill.rb" 
    end 
end 

El problema:

cp: cannot stat `/var/www/my_app/releases/20120313144907/config/database.staging.yml': No such file or directory 
+0

¿Qué sucede cuando ejecuta el comando cp manualmente en esa máquina? –

+1

.yml o .ymp? Si tiene .ymp su archivo se llama incorrecto – DGM

+0

.yml, mi mal ... – user984621

Respuesta

21

No estoy seguro de cómo resolver su problema. Parece que database.staging.yml no se está implementando, por lo que no hay nada para copiar.

Creo que hay un mejor flujo de trabajo. Cosas como la configuración y la configuración de la base de datos no suelen cambiar entre las implementaciones, por lo que esas cosas pueden ir en la carpeta compartida de todas las versiones de Capistrano. Por lo general, no desea que su database.yml esté en su repositorio tampoco, ya que es información confidencial. Puede satisfacer estas dos cosas al excluir config/database.yml en su .gitignore.

Esto requiere que realice una configuración única en sus servidores. Necesita crear un database.yml al your_app_path/shared/config. Shared es un hermano al corriente y versiones.

Su deploy.rb debe tener una tarea que enlace simbólicamente el database.yml de la nueva versión implementada al estado en el directorio compartido. De esta manera:

before "deploy:assets:precompile" do 
    run ["ln -nfs #{shared_path}/config/settings.yml #{release_path}/config/settings.yml", 
     "ln -nfs #{shared_path}/config/database.yml #{release_path}/config/database.yml", 
     "ln -fs #{shared_path}/uploads #{release_path}/uploads" 
    ].join(" && ") 
end 

Esto significa que tu repositorio no contendrá database.yml archivos. Dado que probablemente ya estén en su repositorio. Tendrás que git rm ellos, confirmar. Agrégalos al .gitignore y confirma eso.

+1

lo hicimos, pero incluimos un database.yml.example en config, que los desarrolladores pueden usar para iniciarse localmente sin tener que adivinar las configuraciones de database.yml – tehfoo

+0

Creo que current/config/database.yml es vinculado a shared/config/database.yml Si falta shared/config/database.yml, le dará 'No such file or directory'. Podemos crearlo manualmente en shared/config/database.yml y desplegarlo. Esto funciona aquí. – vajapravin

+0

Disculpe, ¿por qué su script 'deploy.rb' menciona' settings.yml'? – Matthias

0

Si no es necesario "objetos de aplicación de referencia o métodos" (1) durante la precompilación entonces se podría estar bien con el establecimiento de config.assets.initialize_on_precompile a false en config/application.rb

8

En Capistrano 3, que une los archivos que lleva incorporado. La respuesta de Juan es simplemente:

  • En la carpeta shared/ crear config/database.yml
  • En config/deploy.rb uso de esta línea

    set :linked_files, fetch(:linked_files, []).push('config/database.yml') 
    

Esto lo decía Juan.

+0

Esto es todo. Gracias – Francisco

+0

¿Cómo resolvemos esto para la última versión, 3.8.0? –

Cuestiones relacionadas