it-swarm.com.de

Was ist der beste Weg, um Konfigurationsdaten zu verwalten?

Ich arbeite an einer Produktsuite mit 4 Produkten. Derzeit befinden sich alle Konfigurationsdaten entweder in den XML- oder in den Eigenschaftendateien. Dieser Ansatz kann nicht verwaltet werden, da verschiedene Konfigurationsdateien für unterschiedliche Umgebungen (z. B. Produktion, Entwicklung usw.) verwaltet werden müssen.

Also, wie gehe ich am besten mit Konfigurationsdaten um?

Können wir dies auch in einem separaten Modul modularisieren? Damit alle Produkte dieses Modul verwenden können. Wir möchten die Eigenschaftsdateien nicht verwenden. Ich suche nach einer Lösung, mit der wir den gesamten konfigurationsspezifischen Code als neues Konfigurationsmodul verschieben und alle Konfigurationsdaten in der Datenbank beibehalten können.

27
Shekhar

Mit commons-configuration haben Sie eine einheitliche API für den Zugriff auf die Eigenschaften, egal wie sie werden dargestellt - .properties, xml, JNDI usw.

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>

in beiden Fällen sind sie mit etwas erreichbar:

String Host = config.getString("jdbcHost");
22
Bozho

Sie sind fast da ... Ich würde den gleichen Ansatz beibehalten und die korrekte Konfigurationsdatei für die Instanz der Anwendung abrufen, die mit einer der folgenden Methoden ähnlichen Methode ausgeführt wird:

  1. Benennen Sie alle Konfigurationsdateien anders und lassen Sie sie von Ihrer Anwendung nach eindeutigen Kriterien (Benutzername, Hostname usw.) einlesen:

    • Produktion . Eigenschaften
    • developer1 . Eigenschaften
    • developer2 . Eigenschaften
  2. Bewahren Sie sie außerhalb der Codebasis an einem Ort auf, der auf einer Umgebungsvariablen basiert, die die Anwendung als vorhanden ansieht:

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

Ich habe sogar eine Kombination dieser Ansätze für dasselbe Projekt verwendet (Nr. 1 für Buildprozesskonfigurationen und Nr. 2 für Laufzeitkonfigurationen).

12
Nicole

Wenn Ihre Anwendungen mit einer Datenbank arbeiten, können Sie eine "Konfigurationstabelle" wie folgt erstellen:

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

Sie würden es mit einem Init-Skript initialisieren, beispielsweise init.sql mit folgenden Inhalten:

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

Die Vorteile dieses Ansatzes sind wie folgt:

  • sie versionieren das Skript zusammen mit Ihrem Code
  • sie können es problemlos um Einstellungen pro Benutzer oder Gruppen erweitern, indem Sie eine Benutzer-/Gruppen-ID hinzufügen
  • sie können die Einstellungen zur Laufzeit ändern, wenn Sie dies benötigen
  • sie können denselben Stack (JPA + DAO, Cayenne ...) verwenden, mit dem Sie normalerweise Core-Anwendungsdaten behandeln, um Konfigurationsdaten zu behandeln

In all unseren Umgebungen leben Konfigurationsdaten auf den Zielcomputern in Form von Eigenschaftsdateien. Wir verwenden PropertyPlaceholderconfigurer von SpringFramework, um diese Eigenschaften an unsere Apps zu binden, um die Umgebung tragbar zu machen. 

Solange ich beispielsweise weiß, dass /etc/myapp/database.properties auf dem Rechner vorhanden ist, auf dem meine App ausgeführt wird, brauche ich in meiner Frühlingskonfiguration nur Folgendes:

    <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>

Es gibt eine Reihe von Optionen für diese Spring-Klasse, in denen Eigenschaftsdateien gespeichert werden können. Sie können sie sogar ersetzen und als Umgebungsvariablen übergeben:

    <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>

Und in bash_profile (oder was auch immer): Export Java_OPTS = "-Ddatabase.configuration.file.url = file: ///etc/myapp/database.properties"

Oder nur die Option -D, die übergeben wird, wenn Sie "Java" aufrufen, je nachdem, was Sie tun.

FWIW pflegen wir unsere Eigenschaftendateien separat als RPMs.

4
zznate

Es gibt viele verschiedene Strategien. Alle sind gut und hängen davon ab, was am besten zu Ihnen passt.

  1. Erstellen Sie ein einzelnes Artefakt und stellen Sie Konfigurationen an einem separaten Ort bereit. Das Artefakt könnte Platzhaltervariablen haben, und bei der Implementierung kann die Konfiguration eingelesen werden. Sehen Sie sich den Platzhalter für Spring-Eigenschaften an. Es funktioniert fantastisch für Webapps, die Spring verwenden, und erfordert keine Ops involviert.
  2. Verfügt über eine externalisierte Eigenschaftskonfiguration, die sich außerhalb der Webanwendung befindet. Halten Sie die Position konstant und lesen Sie immer aus der Eigenschaft config. Aktualisieren Sie die Konfiguration zu einem beliebigen Zeitpunkt, und die neuen Werte werden neu gestartet.
  3. Wenn Sie die Umgebung ändern (z. B. verwendeter Anwendungsserver oder Benutzer-/Gruppenberechtigungen), verwenden Sie die oben genannten Methoden für Puppet oder Chef. Schauen Sie sich auch die Verwaltung Ihrer Konfigurationsdateien mit diesen Tools an.
2
joevartuli

Umgebungsvariablen sind in etwa der einfachste Weg. Stellen Sie sie wie zu jeder anderen Zeit ein und rufen Sie sie mit System.getenv("...") auf

0
Colby Cox

Config ist ein Konfigurationsdatei-Verwaltungstool. Sie können eine Konfiguration erstellen, die in allen Umgebungen üblich ist, oder Sie können eine umgebungsspezifische Konfiguration erstellen. Sie können Ihre XML- und Eigenschaftendateien weiterhin verwenden und Config die Unterschiede in der Umgebung beibehalten lassen. Sie können sich Config als Ihre zentralisierte Datenbank vorstellen und die Konfigurationsdatei in dem gewünschten Format ausgeben. Wann immer Sie Ihre Konfigurationsdatei wünschen, stellen Sie sie einfach (Config oder Push) von Config an Ihrem gewünschten Ort bereit. Beachten Sie, dass ich Teil des Config-Teams bin.

0