Как обрабатывать конфигурацию приложения для конкретной среды в масштабах всей организации? - PullRequest
12 голосов
/ 10 июня 2010

Проблема

В вашей организации имеется множество отдельных приложений, некоторые из которых взаимодействуют друг с другом (образуя «системы»).Вам необходимо развернуть эти приложения в отдельных средах для облегчения поэтапного тестирования (например, DEV, QA, UAT, PROD).Данное приложение должно быть настроено немного по-разному в каждой среде (например, каждая среда имеет отдельную базу данных).Вы хотите, чтобы эта перенастройка осуществлялась каким-то автоматическим механизмом, чтобы менеджерам выпусков не приходилось вручную настраивать каждое приложение каждый раз, когда оно развертывается в другой среде.

Желаемые функции

Я бы хотел разработать конфигурационное решение для всей организации со следующими свойствами (в идеале):

  • Поддерживает развертывание "одним щелчком мыши" (требуется указать только среду, и не нужно повторно настраивать вручную).-конфигурация во время / после развертывания должна быть необходимой).
  • Должна быть одна «система записи», в которой указывается общее свойство, зависящее от среды (например, строка подключения к базе данных, которая используется многими приложениями).
  • Поддерживает переконфигурирование развернутых приложений (в случае, если свойство среды необходимо изменить), в идеале без необходимости повторного развертывания приложения.
  • Позволяет приложениюзапускаться на той же машине, но в diffРазличные среды (запуск экземпляра PROD и экземпляра DEV одновременно).

Возможные решения

Я вижу два основных направления, в которых может пойти решение:

  1. Сделайте все приложения "осведомленными об окружающей среде".Вы должны передать имя среды (DEV, QA и т. Д.) В командной строке приложению, а затем приложение станет достаточно «умным», чтобы выяснить значения конфигурации для конкретной среды во время выполнения.Приложение может извлекать значения из плоских файлов, развернутых вместе с приложением, или из централизованной службы настройки.
  2. Приложения не являются «умными», как в # 1, а просто выбирают конфигурацию по имени свойства из configфайлы, развернутые с приложением.Значения этих свойств вводятся в файлы конфигурации во время развертывания программой / скриптом установки.Этот сценарий установки берет имя среды и извлекает все соответствующие значения конфигурации из службы централизованного конфигурирования.

Вопрос

Как бы вы достигли / нашли решение для конфигурации, которое решает эти проблемы и поддерживаетэти желаемые функции?Я нахожусь на цели с двумя возможными решениями?У вас есть предпочтения между этими решениями?Кроме того, пожалуйста, не стесняйтесь сказать мне, что я думаю о проблеме все неправильно.Любая обратная связь будет принята с благодарностью.

Ответы [ 4 ]

2 голосов
/ 17 июня 2010

Мы все сталкивались с такими вещами, особенно в крупных организациях.Я думаю, что в первую очередь важно управлять своими собственными ожиданиями, а также спросить, действительно ли * необходимо сказать каждой системе и подсистеме в данном блоке "перейти в режим DEV" или "перейти в режим PROD".Моя личная рекомендация такова:

  1. Назначить отдельные ящики ответственными за другой этап - то есть «это ящик DEV» и «это ящик PROD».

  2. Соберите как можно больше конфигурации, которая отличается от коробки к коробке, в одном месте, даже если для ее распечатки требуются программные ссылки или сценарии, которые собирают информацию.

    A.Таким образом, вы можете легко «сбросить конфигурацию этого ящика» в двух местах и ​​посмотреть, что отличается, например, после нового развертывания.

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

  3. Тогда все должно основываться на конфигурациина что-то / где-то, что не запечено или жестко запрограммировано - просто убедитесь, что собрали и задокументировали это в одном месте.Почти не имеет значения, что это за механизм, и это хорошо, потому что некоторые системы просто не хотят, чтобы их заставляли использовать те или иные механизмы.

Извините, если этослишком общий ответ - вопрос был очень общий.Раньше я работал в нескольких крупных организациях, основанных на программном обеспечении, и это, казалось, было лучшим подходом.Использование автономного сервера в качестве «одной единицы развертывания» является наиболее реалистичным сценарием (хотя иногда и дорогостоящим), поскольку приложения влияют друг на друга, и независимо от того, насколько вы осторожны, вы дестабилизируете всю систему, когда перемещаете любое заданное устройство или шестерню..

Альтернатива становится очень сложной очень быстро.Вам нужно начать переписывать приложения, которыми вы управляете, чтобы они приняли переключатель «DEV», и вы в конечном итоге добавляете слои kludge к тем, над которыми у вас нет контроля.Как правило, те, кого вы не контролируете, по крайней мере, основывают свои свойства на чем-то, определенном на общесистемном уровне, если только они «не обращаются к руководству за помощью».

Проще перенаправлять людей наудаленное местоположение и пусть они «используют DEV» против «использовать PROD», чем «заставить эту машину работать как DEV» против «заставить эту машину работать как PROD».И если вы все перепутаете, например, если задача DEV запускается вместе в одном окне с задачей PROD, то в любом случае это нереальный сценарий: я гарантирую, что в конечном итоге вы предоставите незаконный доступ только для DEV кому-то в PRODи у вас будет задача DEV стереть базу данных PROD.

Надеюсь, это поможет.Дайте мне знать, если вы хотите обсудить больше деталей.

0 голосов
/ 23 декабря 2016

Если вы используете JSON для хранения / передачи конфигурации (или можете использовать JSON в процессе перед развертыванием для вывода в другой формат), вы можете аннотировать имена ключей / свойств для значений среды / контекста с произвольными значениями или средой -специфичные суффиксы, а затем динамически предпочитать / различать их во время сборки / развертывания / запуска / рендеринга, оставляя только аннотированные свойства в одиночку.

Мы использовали это, чтобы избежать дублирования целых файлов конфигурации (с хорошо известными связанными проблемами) И для уменьшения повторения. Техника также идеально подходит для интернационализации (i18n) - даже в том же файле, если это необходимо.

Пример, фрагмент предварительно обработанной конфигурации JSON:

var config = {
    'ver': '1.0',
    'help': {
        'BLURB': 'This pre-production environment is not supported. Contact Development Team with questions.',
        'PHONE': '808-867-5309',
        'EMAIL': 'coder.jen@lostnumber.com'
    },
    'help@www.productionwebsite.com': {
        'BLURB': 'Please contact Customer Service Center',
        'BLURB@fr': 'S\'il vous plaît communiquer avec notre Centre de service à la clientèle',
        'BLURB@de': 'Bitte kontaktieren Sie unseren Kundendienst!!1!',
        'PHONE': '1-800-CUS-TOMR',
        'EMAIL': 'customer.service@productionwebsite.com'
    },
}

... и постобработка (в данном случае при рендеринг время) с учетом динамического, известного браузеру окружения location.hostname = ' www.productionwebsite.com ' и язык навигатора ' de '):

prefer(config,['www.productionwebsite.com','de']); // prefer(obj,string|Array<string>)

JSON.stringify(config); // {
    'ver': '1.0',
    'help': {
        'BLURB': 'Bitte kontaktieren Sie unseren Kundendienst!!1!',
        'PHONE': '1-800-CUS-TOMR',
        'EMAIL': 'customer.service@productionwebsite.com'
    }
}

Если неаннотированное («базовое») свойство не имеет конкурирующего аннотированного свойства, оно остается одним (предположительно глобальным для разных сред), в противном случае его значение заменяется аннотированным значением, если суффикс совпадает один из входов в функцию предпочтения / дискриминации. Аннотированные свойства, которые не совпадают, удаляются полностью.

Вы можете смешивать и сопоставлять это поведение для аннотирования конфигурации, чтобы добиться различий между глобальными, стандартными, специфичными, которые (если вы разумны) читаются с нулевым / минимальным дублированием.

Единственная, рекурсивная курсная () функция (как мы ее называем, без необходимости или желания сделать из нее целый проект / фреймворк), которую мы разработали до сих пор (см. jsFiddle , со встроенными документами) идет немного дальше, чем этот простой пример, и (более подробно объяснено здесь ) обрабатывает глубоко вложенные объекты конфигурации, а также преференциальный порядок и (если вы нужно остаться без изменений) комбинация суффиксов.

Функция полагается на способность JS ссылаться на свойства объекта как строки, динамически и допускать @ и & разделители в именах свойств, которые недопустимы в синтаксисе с точечной нотацией, но, следовательно, (помогают) не позволяют разработчикам нарушать эту технику, случайно ссылаясь на к предварительно обработанным / аннотированным атрибутам в коде (если они, как правило, не предпочитают использовать точечные обозначения.)

У нас еще не было этого разрыва для нас, и мы не были обучены каким-либо фундаментальным недостаткам этой техники, за исключением безответственного / непреднамеренного использования или инвестиций / привязанности к существующим основам / методам, которые уже существуют. Мы также не профилировали его для производительности (мы, как правило, запускаем его один раз за сборку / сессию и т. Д.), Поэтому для вашего собственного использования, YMMV.

Большинство конфигураций, передаваемых на стороне клиента, разумеется, не захотят содержать конфиденциальные значения перед началом производства, поэтому можно (следует!) Использовать эту же функцию для создания версии только для производства (без аннотаций) перед развертыванием, все еще наслаждаясь ОДИНОЧНЫМ файлом конфигурации перед вами в процессе.

Кроме того, если вы делаете это для i18n, вы можете не захотеть, чтобы весь пакет проходил по проводам, поэтому можете обработать его на стороне сервера (кэшированный или живой, и т. Д.) Или предварительно обработать его в build / deploy разделив на отдельные файлы, но ВСЕ ЕЩЕ наслаждайтесь единым источником правды как можно раньше в вашем рабочем процессе.

Мы не исследовали реализацию той же функции в Java (или C #, PERL и т. Д.), Предполагая, что это даже возможно (возможно, с каким-то экзотическим отражением?), Но среда сборки, включающая NodeJS, могла бы легко справиться с этой задачей.

0 голосов
/ 25 января 2015

Я думаю, что перед тем, как прочесть этот вопрос, я задал связанный вопрос с автоответчиком: Как организовать код, чтобы мы могли перемещать и обновлять его, не редактируя расположение файла конфигурации? 1002 *. Итак, на этом основании я даю ответ здесь. Мне не нравится идея «умного» приложения (решение 1 здесь) для такой простой задачи, как поиск настроек среды. Это кажется сложной структурой для чего-то, что должно быть простым. Идея сценария установки (решение 2 здесь) является мощной, но она полезна, чтобы позволить пользователю изменять содержимое файла конфигурации, но позволит ли это изменить местоположение этого файла конфигурации? Что это за «служба центральной конфигурации», где она находится? Мой ответ заключается в том, что я бы выбрал вариант 2, если цель состоит в том, чтобы установить содержимое файла конфигурации, но я чувствую, что вопрос о расположении этого файла конфигурации здесь остается без ответа.

0 голосов
/ 28 марта 2013

Я лично предпочитаю решение 2 (приложение должно по своей конфигурации знать, в какой среде оно работает).С решением 1 (передайте имя среды в качестве параметра запуска) опасность использования неправильного спецификатора среды слишком высока.Доступ к базе данных TEST из кода PROD и наоборот может вызвать хаос, если две установленные базы кода имеют разную версию, как это часто бывает.

Мой текущий проект использует решение 1, но я неэто так.В предыдущем проекте, над которым я работал, использовался вариант решения 2. Процесс сборки генерировал один установочный файл для каждой среды, следя за тем, чтобы они содержали одинаковую кодовую базу, но соответствующие параметры конфигурации.Это сработало как обаяние, но я знаю, что это противоречит парадигме, что «одни и те же файлы сборки должны быть развернуты везде».

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...