Pourquoi conserver une copie d'une application sur l'hôte DB?

Question

Un grand nombre de recettes exemple Capistrano comprennent un rôle :db. Par défaut, la tâche de déploiement exporte le code de l'application vers tous les hôtes de tous les rôles. Cela suggère donc que les gens conservent une copie de leur application sur l'hôte de la base de données. En outre, dans distribué deploy.rb recette de Capistrano, :deploy:migrate ressemble à ceci:

task :migrate, :roles => :db, :only => { :primary => true } do 
    # ... 
end 

Ma question est, pourquoi est-il fait comme ça? Ne serait-il pas plus propre de garder le code de l'application hors de l'hôte de la base de données (qui pourrait même ne pas avoir installé Ruby) et d'exécuter les migrations à partir de la boîte de production?

Answer 1

Le serveur db exécute des migrations car il est responsable de la ou des bases de données.

On pourrait également imaginer des politiques de sécurité qui permettent uniquement de créer/supprimer/modifier des tables à partir du serveur de base de données lui-même.

Il peut même y avoir de légers gains de performance si des données sont chargées lors d'une migration, même si c'est une mauvaise idée pour commencer.

Si vous avez besoin de faire référence à votre hôte de base de données et ne pas besoin d'une copie du code sur elle, vous pouvez utiliser quelque chose comme ceci:

role :db, 'dbhost', :no_release => true 

Exemple de code pour exécuter la migration sur un serveur d'applications:

role :app, 'apphost', :runs_migrations => true 
task :migrate, :roles = :app, :only => {:runs_migrations => true } do 
    #... 
end