Transmettre des informations personnalisées à mongrel_rails start

Question

Une chose que je ne comprends vraiment pas, c'est comment je peux passer des options de démarrage personnalisées à une instance de mongrel.

Je vois qu'une approche commune est l'utilisation des variables d'environnement, mais dans mon environnement cela ne va pas fonctionner parce que mon application rails sert de nombreux clients différents. Une grande partie du code est partagée entre les clients, mais il existe également de nombreuses différences que j'implémente en sous-classant les contrôleurs et les vues pour surcharger ou étendre les fonctionnalités existantes ou en introduire de nouvelles. Pour que tout cela fonctionne, j'ajoute simplement les chemins aux modules spécifiques au client le chemin de chargement du module ($ :).

Afin de démarrer l'application pour un client particulier, je pourrais maintenant utiliser une variable d'environnement comme say, TARGET = AMAZONE. Malheureusement, sur certains systèmes, j'utilise plusieurs clusters mongrels, chaque cluster servant un client différent. Certains de ces systèmes fonctionnent sous Windows et pour démarrer mongrel j'ai installé mongrel_services. Clairement, cela rend ma variable d'environnement inadaptée. Passer ce bit supplémentaire de données à l'application s'avère être un vrai défi. Pour commencer, mongrel_rails service_install rejettera tous les paramètres de ligne de commande [personnalisés] qui ne sont pas documentés. Je ne suis pas trop inquiet car installer les services en utilisant le programme d'installation est trivial.

Cependant, même si je parviens à installer mongrel_services de sorte que lorsque l'exécuter passe l'option de ligne de commande personnalisée --target à mongrel_rails commencer, je reçois une erreur, car mongrel_rails ne reconnaît pas l'interrupteur.

Voici donc étaient les choses que je regardais à:

1. passer un paramètre supplémentaire:

   mongrel_rails commencent --target XYZ ...

2. utiliser un fichier de configuration et ajouter cible : XYZ, puis faire:

   mongrel_rails commencent à C x: \ MyApp \ myconfig.yml

3. modifier le fichier:

   Ruby \ lib \ Ruby \ gemmes \ 1.8 \ gemmes \ bâtarde-1.1.5-x86-mswin32-60 \ lib \ bâtarde \ command.rb

4. Je pourrais peut-être utiliser l'option --script, mais tous les docs que j'ai trouvés dessus étaient pour Unix

1 et 2 ne fonctionnent tout simplement pas. J'ai joué avec 4 mais je n'ai jamais réussi à faire quoi que ce soit. Donc je n'avais pas d'autre choix que d'aller avec 3. Alors que c'est relativement simple, je déteste changer le code de la bibliothèque ruby.

Particulièrement décevant est que 2 ne fonctionne pas. Je veux dire ce qui est si déraisonnable à propos de l'ajout d'autres options [personnalisées] dans le fichier de configuration? En fait, je pense que c'est une pièce fondamentale qui manque dans les rails. D'une manière ou d'une autre, l'application devrait pouvoir s'enregistrer et accéder aux arguments de ligne de commande qu'elle attend.

Si quelqu'un a une bonne idée de comment faire cela plus élégamment en utilisant l'infrastructure actuelle, j'ai un poisson au chocolat à donner !!!

Answer 1

Il n'est peut-être pas nécessaire de laisser passer quelque chose au métis. Il peut être possible d'utiliser un mécanisme existant qui offrira la flexibilité que vous recherchez. Commençons par essayer d'être très clair sur les contraintes.

Pour paraphraser, il semble que les conditions suivantes sont en vigueur.

• La même base (ou base de code très similaire) le code est utilisé pour desservir plusieurs clients
• Identifiers qui influent sur l'exécution de l'application sont nécessaires au démarrage de l'application (ou avant l'exécution) pour définir le comportement de l'application
• ensembles multiples des grappes de batards peuvent être utilisés sur un seul système avec chaque groupe dédié à un seul client
  • Cela implique qu'un groupe de processus sont tous au service de la même base de code avec la même valeur de configuration (s)
• Certains clients souhaitent s'exécuter sur des serveurs Windows, ce qui évite l'utilisation de l'environnement de style Unix et du comportement de script.

Une hypothèse qui devrait être validée est que chaque base de code se trouve dans un répertoire distinct. Si oui, alors il peut y avoir une solution très simple.

Si chaque client est dans son propre répertoire, comme ceci:

/src 
    /customer1 
    /customer2 
    /customer3 

Et si vous commencez vos processus métissés avec quelque chose comme:

[/src/customer1]$ mongrel_rails cluster::start 

Ensuite, vous pourriez avoir un fichier customer_config.yml que est lu au démarrage du système (dans votre environnement.rb) dans lequel vous pouvez placer la valeur de personnalisation de votre client. Donc, si vous devez passer dans « Amazone » comme valeur cible, votre fichier YAML pourrait ressembler à:

target: 
    Amazone 

Ensuite, chaque client obtient leur propre fichier customer_config.yml, qui ne réside que dans leur répertoire, et vous n'avez qu'un seul fichier à modifier pour changer de comportement lorsque vous ajoutez un nouveau client.

Modifier votre environnement.rb pour rechercher un fichier YAML spécifiquement nommé serait parfaitement acceptable. Il est plutôt facile d'analyser un fichier YAML, et cela donne beaucoup de flexibilité pour gérer la personnalisation de chaque client.