web-dev-qa-db-fra.com

Quelle est la meilleure façon de gérer les données de configuration

Je travaille sur une suite de produits contenant 4 produits. À l'heure actuelle, toutes les données de configuration se trouvent dans le fichier XML ou dans les fichiers de propriétés. Cette approche n'est pas maintenable car nous devons gérer différents fichiers de configuration pour différents environnements (par exemple, production, développement, etc.).

Alors, quel est le meilleur moyen de gérer les données de configuration?

De plus, pouvons-nous modulariser cela dans un module séparé? Pour que tous les produits puissent utiliser ce module ..__, nous ne voulons pas utiliser les fichiers de propriétés. Je recherche une solution dans laquelle nous pouvons déplacer tout le code spécifique à la configuration en tant que nouveau module de configuration et conserver toutes les données de configuration dans la base de données.

javaconfiguration-managementmodularity
27
Shekhar

En utilisant commons-configuration vous avez une API unifiée pour accéder aux propriétés, peu importe la façon dont elles sont représentées - .properties, xml, JNDI, etc. Par exemple:

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>

dans les deux cas, ils seront accessibles avec quelque chose comme:

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

Vous y êtes presque ... Je conserverais votre approche et extrairais le fichier de configuration correct pour l'instance de l'application qui s'exécute selon une méthode similaire à l'une des suivantes:

  1. Nommez tous vos fichiers de configuration différemment et demandez à votre application de les extraire selon des critères uniques (nom d'utilisateur, nom d'hôte, etc.):

    • production . propriétés
    • développeur1 . propriétés
    • développeur2 . propriétés

  2. Conservez-les en dehors de la base de code dans un emplacement basé sur une variable d'environnement supposée existante par l'application:

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

J'ai même utilisé une combinaison de ces approches sur le même projet (n ° 1 pour les configurations de processus de génération et n ° 2 pour les configurations d'exécution).

12
Nicole

Si vos applications fonctionnent avec une base de données, vous pouvez créer une table de "configuration" comme suit:

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

Vous pouvez l’initialiser à l’aide d’un script init, par exemple init.sql avec un contenu du type:

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

Les avantages de cette approche sont les suivants:

  • vous version le script avec votre code
  • vous pouvez facilement l'étendre pour inclure les paramètres par utilisateur ou par groupe en en ajoutant un identifiant d'utilisateur/de groupe
  • vous pouvez modifier les paramètres dans runtime si vous en avez besoin
  • vous utilisez la même pile (JPA + DAO, Cayenne ...) que vous utilisez normalement pour gérer les données de base de l'application afin de gérer les données de configuration.
5
Tomislav Nakic-Alfirevic

Pour tous nos environnements, les données de configuration résident sur les ordinateurs cibles sous la forme de fichiers de propriétés. Nous utilisons PropertyPlaceholderconfigurer de SpringFramework pour lier ces propriétés à nos applications afin que les éléments restent portables dans tous les environnements. 

Par exemple, tant que je sais que /etc/myapp/database.properties sera présent sur la machine sur laquelle mon application sera exécutée, dans ma configuration de printemps, il me faut juste quelque chose comme ça:

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

Il existe de nombreuses options pour cette classe Spring sur l'emplacement des fichiers de propriétés. Vous pouvez même en faire des substitutions et les transmettre en tant que variables d'environnement:

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

Et dans bash_profile (ou autre): Export Java_OPTS = "-Ddatabase.configuration.file.url = fichier: ///etc/myapp/database.properties"

Ou simplement la même option -D transmise lorsque vous appelez "Java" en fonction de ce que vous faites.

FWIW, nous conservons nos fichiers de propriétés séparément en tant que RPM.

4
zznate

Il y a beaucoup de stratégies différentes. Tous sont bons et dépendent de ce qui vous convient le mieux.

  1. Construisez un seul artefact et déployez les configurations dans un emplacement distinct. Cet artefact peut avoir des variables d'espace réservé et, lors du déploiement, la configuration peut être lue. Examinez l'espace réservé de la propriété Springs. Cela fonctionne à merveille pour les applications Web qui utilisent Spring et n'implique aucune implication.
  2. Avoir une configuration de propriété externalisée qui vit en dehors de la webapp. Gardez l'emplacement constant et lisez toujours depuis la propriété config. Mettez à jour la configuration à n'importe quel stade et un redémarrage fera apparaître les nouvelles valeurs.
  3. Si vous modifiez l'environnement (serveur d'application utilisé ou autorisations d'utilisateur/groupe, par exemple), envisagez d'utiliser les méthodes ci-dessus avec marionnette ou chef. Jetez également un coup d'oeil à la gestion de vos fichiers de configuration avec ces outils.
2
joevartuli

Les variables d'environnement constituent la solution la plus simple. Définissez-les comme vous le feriez à tout autre moment, accédez-y avec w/System.getenv("...")

0
Colby Cox

Config est un outil de gestion de fichier de configuration. Vous pouvez créer une configuration commune à tous les environnements ou créer une configuration spécifique à l'environnement. Vous pouvez continuer à utiliser vos fichiers XML et de propriétés et laisser Config gérer les différences d’environnement. Vous pouvez considérer Config comme votre base de données centralisée et le fichier de configuration peut être exporté dans le format de votre choix. Chaque fois que vous voulez votre fichier de configuration, il vous suffit de le déployer (pousser ou tirer) depuis Config vers l'emplacement souhaité Notez que je fais partie de l'équipe de configuration.

0
Bienvenido David