2009-05-29 6 views
0

Je suis en train de déployer les mêmes rails app à deux endroits différents avec différents noms d'applications, logos différents, différentes feuilles de style, etc.Déploiement d'une application de rails à plusieurs endroits

J'ai le code de travail basé sur une variable APP_NAME et une variable HOST_NAME que je stocke dans les environnements/production.rb. Maintenant, je dois le déployer et j'ai besoin d'une meilleure solution que de modifier manuellement le fichier d'environnement sur la machine de production.

La seule façon que je peux voir pour le faire est de créer un nouvel environnement de production - par exemple. production_app2 - et définissez différemment APP_NAME et HOST_NAME. Y a-t-il un meilleur moyen?

Répondre

6

Non non non! Ne modifiez pas les fichiers d'environnement. Je veux dire, éditez-les comme vous devez pour les choses qui doivent être configurées le même pour chaque déploiement, mais pas pour les choses qui devraient être configurable entre les déploiements.

Pour cela, utilisez la configuration.

Throw un fichier YAML dans config qui ressemble à ceci:

development: 
    :app_name: App 1 
    :host_name: something.com 

test: 
    :app_name: App 1 
    :host_name: something.com 

production: 
    :app_name: App 1 
    :host_name: something.com 

Appelez cela comme logique. Disons settings.yml.

charger maintenant avec un initialiseur à config/initializers/settings.rb qui ressemble à ceci:

SETTINGS = YAML.load_file("#{RAILS_ROOT}/config/settings.yml")[RAILS_ENV] 

maintenant accès à la configuration comme ceci:

SETTINGS[:app_name] 

(Si vous ne voulez pas changer votre code existant à tout, à l'intérieur config/initializers/settings.rb ajouter des lignes qui définissent vos noms existants comme APP_NAME = SETTINGS[:app_name], etc.)

Notez qu'il s'agit d'un imp lementation de la configuration des paramètres, mais même si une autre approche est adoptée, elle doit être basée sur une configuration indépendante du déploiement. Cela peut être mis en place de manière beaucoup plus facile et maintenable pour persister entre les déploiements et les mises à niveau que le déblayage avec des fichiers d'environnement.

Encore une fois, pour récapituler:

  • fichiers d'environnement sont pour la configuration qui est la même dans tous les déploiements
  • fichiers de configuration sont pour la configuration qui peut changer entre les déploiements

Mise à jour

Pour les déploiements basés sur Capistrano, c'est ce que j'utilise pour symlink multi les fichiers de configuration PLE dans la nouvelle current à partir du répertoire shared (je pense qu'il est originaire d'une recette de Ezra EngineYard):

after "deploy:update_code","deploy:symlink_configs" 

namespace(:deploy) do 
    task :symlink_configs, :roles => :app, :except => {:no_symlink => true} do 
    configs = %w{ database settings } 
    configs.map! { |file| "ln -nfs #{shared_path}/config/#{file}.yml #{release_path}/config/#{file}.yml" } 
    run <<-CMD 
     cd #{release_path} && #{configs.join(' && ')} 
    CMD 
    end 
end 
+0

sens. Mais comment puis-je obtenir différents fichiers de paramètres sur chaque déploiement? – zaius

+1

On suppose qu'ils ont aussi différentes bases de données. Vous utilisez la même stratégie que vous utilisez pour leur donner différents fichiers config/database.yml. Sur les déploiements basés sur Capistrano, cela signifie généralement que les fichiers se trouvent dans le répertoire partagé. –

+0

Aha! C'est ce que je cherchais. Ainsi, chaque emplacement de déploiement aurait ses propres fichiers de paramètres, et j'utilise mon outil de déploiement de choix pour créer un lien symbolique. Parfait merci! – zaius

1

Je pense que c'est un très bon moyen.

Où nous nous définissons des environnements différents (par exemple, « mise en scène », « production », « production_backup » - nous donnant un staging.rb, production.rb, production_backup.rb où vous pouvez définir vos besoins spécifiques APP_NAMEs et HOST_NAMEs) et peut déployer à chacun d'eux en utilisant Capistrano. Cela fonctionne très bien.

Ceci est un bon lien sur elle: http://www.egtheblog.com/?p=8

1

Parce que vous déployez en fait à deux environnements différents, il semble préférable de créer deux fichiers d'environnement différents, chacun avec leurs propres paramètres. Assurez-vous de choisir des noms descriptifs pour vos fichiers d'environnement, pas seulement production2.

Vous pouvez également stocker cette information dans la base de données, mais je ne sais pas si vous êtes prêt à accepter une telle dépendance. Je suppose que l'utilisation d'une base de données n'aurait de sens que si le nombre de déploiements est trop important pour pouvoir gérer facilement avec quelques fichiers d'environnement.

Questions connexes