Каков наилучший способ управления данными конфигурации - PullRequest
28 голосов
/ 24 февраля 2010

Я работаю над набором продуктов, который имеет 4 продукта. Прямо сейчас все данные конфигурации находятся либо в XML, либо в файлах свойств. Этот подход не поддерживается, поскольку нам приходится управлять другим файлом конфигурации для другой среды (например, для производства, разработки и т. Д.).

Итак, Каков наилучший способ обработки данных конфигурации?

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

Ответы [ 8 ]

22 голосов
/ 24 февраля 2010

Используя commons-configuration у вас есть единый API для доступа к свойствам, независимо от того, как они представлены - .properties, xml, JNDI и т. Д. Например:

config.properties

jdbcHost=192.168.12.35
jdbcUsername=dbuser
jdbcPassword=pass

config.xml:

<config>
   <jdbcHost>192.168.12.35</jdbcHost>
   <jdbcUsername>dbuser</jdbcUsername>
   <jdbcPassword>pass</jdbcPassword>
</config>

в обоих случаях они будут доступны с чем-то вроде:

String host = config.getString("jdbcHost");
12 голосов
/ 24 февраля 2010

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

  1. Назовите все ваши файлы конфигурации по-разному, и ваше приложение получит их по некоторым уникальным критериям (имя пользователя, имя хоста и т. Д.):

    • Производство .properties
    • developer1 .properties
    • developer2 .properties
  2. Храните их вне кодовой базы в месте, основанном на переменной среды, которая, как предполагает приложение, существует:

    • YOURAPP_CONFIG_DIR / server_config.xml
    • YOURAPP_CONFIG_DIR / database_config.properties

Я даже использовал комбинацию этих подходов в одном и том же проекте (# 1 для конфигурации процесса сборки и # 2 для конфигурации времени выполнения).

5 голосов
/ 24 февраля 2010

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

create table configuration (mode char(3), key varchar(255), value varchar(1023));

Вы могли бы инициализировать его, используя скрипт инициализации, скажем, init.sql с содержимым в соответствии с:

insert into configuration values ('pro', 'param1', 'value1'); -- production
insert into configuration values ('dev', 'param1', 'value1'); -- development
insert into configuration values ('tst', 'param1', 'value1'); -- testing
...

Преимущества этого подхода следующие:

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

Для всех наших сред данные конфигурации хранятся на целевых машинах в форме файлов свойств. Мы используем PropertyPlaceholderconfigurer из SpringFramework, чтобы связать эти свойства с нашими приложениями, чтобы обеспечить переносимость между средами.

Например, если я знаю, что /etc/myapp/database.properties будет присутствовать на любой машине, на которой будет работать мое приложение, то в моей весенней конфигурации мне просто нужно что-то вроде этого:

    <bean id="myPropertyConfigurer"
    class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="locations">
        <list>
            <value>/etc/myapp/database.properties</value>
        </list>
    </property>
</bean>
<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource">
    <property name="driverClassName" value="com.mysql.jdbc.Driver" />
    <property name="url"
        value="jdbc:mysql://${db.host}:3306/${db.name}" />
    <property name="username" value="${db.user}" />
    <property name="password" value="${db.pass}" />     
</bean>

Для этого класса Spring есть несколько вариантов, где могут храниться файлы свойств. Вы даже можете сделать их заменами и передать их как переменные окружения:

    <bean id="myPropertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="searchSystemEnvironment" value="true" />
    <property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE" />
    <property name="locations">
        <list>
            <value>${database.configuration.file.url}</value>
        </list>
    </property>
</bean>

И в bash_profile (или как угодно): export JAVA_OPTS = "-Ddatabase.configuration.file.url = file: ///etc/myapp/database.properties"

Или просто та же опция -D, переданная при вызове «java», в зависимости от того, что вы делаете.

FWIW, мы храним наши файлы свойств отдельно как RPM.

2 голосов
/ 24 апреля 2012

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

  1. Создайте один артефакт и разверните конфиги в отдельном месте. Артефакт может иметь переменные-заполнители, и при развертывании можно прочитать конфигурацию. Посмотрите на заполнитель свойства Springs. Он фантастически работает для веб-приложений, использующих Spring, и не требует участия в операциях.
  2. Иметь конфигурацию внешнего свойства, которая находится за пределами веб-приложения. Сохраняйте постоянное местоположение и всегда читайте из конфигурации свойств. Обновите конфигурацию на любом этапе, и при перезагрузке появятся новые значения.
  3. Если вы изменяете среду (то есть используете сервер приложений или права пользователя / группы), обратите внимание на использование вышеуказанных методов с puppet или chef. Также обратите внимание на управление файлами конфигурации с помощью этих инструментов.
0 голосов
/ 17 февраля 2018

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

0 голосов
/ 24 мая 2017

Переменные окружения - это самый простой способ. Установите их так же, как в любое другое время, получите к ним доступ с System.getenv("...")

0 голосов
/ 21 апреля 2015

Вот простое глупое решение.

Фрагмент кода, который сначала пытается использовать файл свойств в текущем каталоге. Если не удалось, используйте файл свойств в каталоге ресурсов (или в файле jar).

    Properties configFile = new Properties();
    try {
        configFile.load(new FileInputStream("production.properties"));
    } catch (Exception e) {
        System.err.println("Can not read properties, try to use default properties file.");
        configFile.load(this.getClass().getClassLoader().
                    getResourceAsStream("development.properties"));
    }
...