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

Question

Je travaille sur une suite de produits qui comprend 4 produits. À l'heure actuelle, toutes les données de configuration se trouvent dans les fichiers XML ou 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, Quelle est la meilleure façon de gérer les données de configuration?

Aussi, pouvons-nous moduler cela dans un module séparé? Alors que tous les produits peuvent utiliser ce module. Nous ne voulons pas utiliser les fichiers de propriétés. Je suis à la recherche d'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.

Answer 1

En utilisant commons-configuration vous avez une API unifiée pour accéder aux propriétés, peu importe la façon dont ils sont représentés - .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 wi e quelque chose comme:

String host = config.getString("jdbcHost"); 

Answer 2

Vous y êtes presque ... je garder votre même approche et tirer dans le fichier de configuration correcte pour l'instance de l'application qui est en cours d'exécution par une méthode similaire à une des conditions suivantes :

1. Nom tous vos fichiers de configuration différente et que votre demande soit les tirer dans certains critères uniques (nom d'utilisateur, nom d'hôte, etc.):

   • production .properties
   • Developer1 .properties
   • developer2 .properties

2. les laisser en dehors du code de base dans un emplacement basé sur une variable d'environnement que l'application suppose existe:

   • VOTREAPP_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 (# 1 pour les configurations de processus de construction et # 2 pour les configurations d'exécution).

Answer 3

Pour tous nos environnements, les données de configuration résident sur les machines cibles sous la forme de fichiers de propriétés.Nous utilisons PropertyPlaceholderconfigurer de SpringFramework pour relier ces propriétés à nos applications pour garder les choses portables dans les environnements.

Par exemple, tant que je sais que /etc/myapp/database.properties seront présents sur la machine quel que soit mon application sera en cours d'exécution sur, puis dans ma configuration de printemps, je dois juste quelque chose comme ceci:

<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 y a un tas d'options pour cette classe de printemps sur l'endroit où les fichiers de propriétés peuvent vivre. Vous pouvez même les 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 bash_profile (ou autre): JAVA_OPTS exportation = "-Ddatabase.configuration.file.url = file: /// etc/myapp/database.properties »

Ou la même option -D passé lorsque vous appelez « java » en fonction de ce que vous faites. FWIW, nous maintenons nos fichiers de propriétés séparément en tant que RPM.

Answer 4

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 l'initialiser à l'aide d'un script d'initialisation, dire init.sql avec le contenu le long des lignes de:

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

• vous la version du script ensem er avec votre code
• vous pouvez facilement l'étendre à inclure par utilisateur ou par groupe paramètres par l'ajout d'un identifiant utilisateur/groupe
• vous pouvez modifier les paramètres à exécution si vous avez besoin de le faire
• vous obtenez d'utiliser la même pile (JPA + OAC, Cayenne ...) vous utilisez normalement pour gérer les données d'application de base de données de configuration poignée

Answer 5

Il y a beaucoup de stratégies différentes. Tous sont bons et dépendent de ce qui vous convient le mieux. Créez un artefact unique et déployez les configs dans un emplacement distinct.

1. L'artefact pourrait avoir des variables d'espace réservé et, lors du déploiement, la config pourrait être lue. Jetez un oeil à l'espace réservé de la propriété Springs. Cela fonctionne de manière fantastique pour les webapps qui utilisent Spring et n'impliquent pas d'opérations impliquées.
2. Avoir une config de propriété externalisée qui vit en dehors de la webapp. Gardez l'emplacement constant et lisez toujours depuis la configuration de la propriété. Mettez à jour la configuration à tout moment et un redémarrage sera mis en place les nouvelles valeurs.
3. Si vous modifiez l'environnement (c'est-à-dire le serveur d'applications utilisé ou les autorisations d'utilisateur/de groupe), utilisez les méthodes ci-dessus avec un marionnettiste ou un chef. Jetez aussi un coup d'oeil à la gestion de vos fichiers de configuration avec ces outils.

Answer 6

Voici un donjon solution simple et stupide.

L'extrait de code, qui essaie d'utiliser d'abord le fichier de propriétés dans le répertoire en cours. En cas d'échec, utilisez plutôt le fichier de propriétés dans le répertoire de ressources (ou dans le fichier 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")); 
    } 

Answer 7

Les variables d'environnement sont à peu près le moyen le plus facile à utiliser. Réglez-les comme vous le feriez à tout moment, accédez-y w/System.getenv("...")

Answer 8

Config est un outil de gestion de fichiers 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 propriétés et laisser Config gérer les différences dans l'environnement. Vous pouvez considérer Config comme votre base de données centralisée et il peut générer le fichier de configuration au format souhaité. Chaque fois que vous voulez votre fichier de configuration, il suffit de déployer (pousser ou tirer) à partir de la configuration à l'emplacement désiré. Notez que je fais partie de l'équipe Config.