Передача пользовательской информации в начало mongrel_rails - PullRequest
0 голосов
/ 08 апреля 2010

Одна вещь, которую я действительно не понимаю, это то, как я могу передать пользовательские параметры запуска экземпляру mongrel.

Я вижу, что общий подход - это использование переменных среды, но в моей среде это не сработает, потому что мое приложение rails обслуживает множество разных клиентов. Большая часть кода распределяется между клиентами, но есть также много различий, которые я реализую, создавая подклассы контроллеров и представлений, чтобы перегрузить или расширить существующие функции или внедрить новые. Чтобы все это работало, я просто добавляю пути к специфическим для клиента модулям путь загрузки модуля ($:).

Чтобы запустить приложение для определенного клиента, я мог бы теперь использовать переменную окружения, например, TARGET = AMAZONE. К сожалению, в некоторых системах я использую несколько беспорядочных кластеров, каждый из которых обслуживает своего клиента. Некоторые из этих систем работают под Windows, и для запуска mongrel я установил mongrel_services. Ясно, что это делает мою переменную среды неподходящей.

Передача этого дополнительного бита данных в приложение оказывается реальной проблемой. Для начала, mongrel_rails service_install отклонит любые [пользовательские] параметры командной строки, которые не задокументированы. Я не слишком обеспокоен тем, что установка служб с помощью программы установки тривиальна.

Однако даже если мне удастся установить mongrel_services таким образом, чтобы при запуске он передавал пользовательский параметр командной строки --target to mongrel_rails start, я получаю сообщение об ошибке, поскольку mongrel_rails не распознает переключатель.

Итак, вот что я посмотрел:

  1. Передать дополнительный параметр:

    mongrel_rails start - цель XYZ ...

  2. используйте файл конфигурации и добавьте цель: XYZ, затем выполните:

    mongrel_rails start -C x: \ myapp \ myconfig.yml

  3. изменить файл:

    Рубин \ Lib \ рубин \ самоцветы \ 1.8 \ самоцветов \ дворняга-1.1.5-x86-mswin32-60 \ Lib \ беспородных \ command.rb

  4. Возможно, я могу использовать опцию --script, но все документы, которые я там нашел, были для Unix

1 и 2 просто не работают. Я играл с 4, но так и не смог ничего сделать. Так что у меня не было выбора, кроме как идти с 3. Хотя это относительно просто, я ненавижу менять код библиотеки ruby.

Особенно разочаровывает то, что 2 не работает. Я имею в виду, что такого неразумного в добавлении других [пользовательских] опций в файл конфигурации? На самом деле, я думаю, что это фундаментальная вещь, которая отсутствует в рельсах. Каким-то образом приложение должно иметь возможность регистрировать и получать доступ к ожидаемым аргументам командной строки.

Если у кого-нибудь есть хорошая идея, как сделать это более элегантно, используя существующую инфраструктуру, у меня есть шоколадная рыбка, которую нужно отдать !!!

1 Ответ

0 голосов
/ 08 апреля 2010

Возможно, нет необходимости передавать что-то дворняге.Может быть возможно использовать существующий механизм, который обеспечит гибкость, которую вы ищете.Давайте начнем с того, что попытаемся быть очень четкими об ограничениях.

Перефразируя, похоже, что действуют следующие условия.

  • Та же самая база кода (или очень похожая база кода)) используется для обслуживания нескольких клиентов
  • Идентификаторы, которые влияют на выполнение приложения, необходимы при запуске приложения (или перед выполнением) для определения поведения приложения
  • В одной системе можно использовать несколько наборов беспородных кластеровс каждым кластером, выделенным для одного клиента
    • Это означает, что все процессы кластера обслуживают одну и ту же кодовую базу с одинаковыми значениями конфигурации
  • Некоторые клиентыхотите работать на серверах Windows, что исключает использование некоторой среды стиля Unix и поведения сценариев.

Одно предположение, которое следует проверить, состоит в том, что каждая база кода находится в отдельном каталоге.Если это так, тогда может быть очень простое решение.

Если каждый клиент находится в своем собственном каталоге, например так:

/src
  /customer1
  /customer2
  /customer3

И если вы запустите свои процессы mongrel с чем-то вроде:

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

Тогда у вас может быть файл customer_config.yml, который читается при запуске системы (в вашем environment.rb), в который вы можете поместить значение настройки вашего клиента.Итак, если вам нужно передать «Amazone» в качестве целевого значения, тогда ваш файл yaml может выглядеть следующим образом:

target:
  Amazone

Затем каждый клиент получает свой собственный файл customer_config.yml, который находится только в егодиректории, и у вас есть только один файл для изменения поведения при добавлении нового клиента.

Изменение вашего environment.rb для поиска файла с определенным именем YAML будет вполне приемлемым.Разобрать файл YAML довольно просто, и он дает большую гибкость для управления настройкой каждого клиента.

...