Comment migrer le fichier config.xml de Weblogic vers plusieurs machines ?

Question

Notre équipe de développement développe une application J2EE qui fonctionne sur Weblogic 10.3. Chaque machine de développement exécute sa propre copie du serveur d'application Weblogic 10.3. Le domaine Weblogic de l'environnement de développement a été initialement créé sur une machine, puis copié sur toutes les machines à l'aide de l'outil de configuration de Weblogic (bea10/wlserver_10.3/common/bin/config.cmd).

Chaque machine de développement possède sa propre copie du fichier config.xml. Toutes les phrases de passe (celles pour les sources de données JDBC, etc.) dans ce fichier sont cryptées et le cryptage utilise apparemment une graine différente sur chaque machine puisque le même mot de passe a des formes cryptées différentes sur différentes machines.

Le problème est que de temps en temps, config.xml doit être mis à jour (par exemple lorsqu'un nouvel EJB est ajouté) et que les mises à jour doivent être appliquées sur toutes les machines. Comment devons-nous procéder ? Si nous plaçons simplement le fichier dans CVS et que nous mettons à jour les autres machines à partir de là, les mots de passe cryptés de chaque machine seront écrasés. Il en résulterait d'horribles exceptions lorsque le serveur essaierait de décrypter les phrases de passe cryptées à l'origine sur une autre machine.

Existe-t-il une tâche ant (je n'en ai pas trouvé) ou un mécanisme similaire qui se chargerait de fusionner correctement les changements dans config.xml sans écraser les mots de passe cryptés ? Ou est-il possible de spécifier les mots de passe en clair et de les crypter au premier démarrage (j'ai un vague souvenir que c'était possible dans les versions précédentes mais pas dans la 10.3).

Comment les équipes de développement travaillant sur Weblogic gèrent-elles cette situation ?

BR,

Marko

Answer 1

[...] Chaque machine de développement copie de config.xml. [...] phrases de passe (celles pour JDBC etc.) contenues dans ce fichier sont cryptées ...

Oui, WebLogic Server crypte tous les mots de passe en texte clair stockés dans son (ses) fichier(s) XML de configuration de domaine. Cela permet d'empêcher l'accès à des informations sensibles. Lorsque les mots de passe sont saisis à l'aide de la console d'administration ou d'outils de script, ils sont automatiquement cryptés avant d'être stockés dans le(s) fichier(s) XML de configuration.

... et le cryptage utilise apparemment une graine différente sur chaque machine puisque le même mot de passe a des formes cryptées différentes sur différentes machines.

À propos de la crypter (à partir des utilitaires Java d'Oracle WebLogic Server), la documentation indique :

En weblogic.security.Encrypt crypte les chaînes en clair pour les utiliser avec WebLogic Server. L'utilitaire utilise le service de cryptage du répertoire actuel ou le service de cryptage d'un répertoire racine du domaine WebLogic Server spécifié.

Remarque : Une chaîne cryptée doit avoir été cryptée par le service de cryptage dans le domaine WebLogic Server où elle sera utilisée. Si ce n'est pas le cas, le serveur ne pourra pas déchiffrer la chaîne.

Ceci n'est pas mentionné dans la documentation mais, AFAIK, Weblogic utilise le fichier de sel de mot de passe du domaine ( SerializedSystemIni.dat ) pour chiffrer la chaîne de texte en clair.

[...] Si nous nous contentons de placer le fichier dans CVS et de mettre à jour les autres machines à partir de là, les mots de passe cryptés de chaque machine seront écrasés.

Vous pouvez choisir d'utiliser des mots de passe en texte clair dans le fichier config.xml stocké dans votre VCS (si cela ne pose pas de problème). En fait, avant WebLogic Server 9.0, les mots de passe étaient cryptés lors du redémarrage suivant. À partir de WebLogic Server 9.0, l'utilisation de mots de passe en texte clair dans les fichiers de configuration n'est "entièrement" prise en charge que pour le domaine Développement et Weblogic ne recrypte pas les mots de passe. Dans les deux cas, cela permettrait aux gens de consulter le fichier de configuration sans problème.

Il existe une tâche ant (je n'en ai pas trouvé) ou un mécanisme similaire qui se chargerait de fusionner correctement les changements dans config.xml sans écraser les mots de passe cryptés....

Je ne suis pas sûr que cela réponde directement à votre question, mais Oracle WebLogic Server fournit les éléments suivants Tâches de la fourmi pour la plupart (sinon la totalité) de ses utilitaires Java. Vous y trouverez peut-être quelque chose d'utile (voir Configuration d'un domaine WebLogic Server à l'aide de la tâche wlconfig Ant )

Ou est-il possible de spécifier les phrases de passe en clair et de les crypter au premier démarrage (je me souviens vaguement que c'était possible dans les versions précédentes, mais pas dans la 10.3).

Comme je l'ai écrit plus haut, c'était le comportement "par défaut" avant Weblogic Server 9.0. Je ne sais pas s'il est possible de forcer ce comportement pour les versions ultérieures. Bien sûr, vous pouvez toujours utiliser ant et crypter de le faire mais, honnêtement, si vous permettez aux gens de voir les mots de passe en clair une fois, je ne vois pas vraiment l'intérêt de les crypter après coup.

Answer 2

J'utiliserais quelque chose comme mercurial ou git, et j'utiliserais la fonctionnalité export/import, de sorte que les changements soient déplacés dans des diffs, et non dans des fichiers complets.

Instructions succinctes

Si vous êtes coincé avec CVS (je suis désolé, je partage votre peine dans une certaine mesure), vous pouvez envisager de créer un repo CVS de diffs. Par exemple, lorsqu'une nouvelle version du fichier de configuration est créée, le nouveau fichier est comparé à l'ancien et le fichier de comparaison est ajouté au repo, d'autres hôtes le vérifient à partir de cvs et corrigent le fichier de configuration.

Il s'agit d'une astuce, mais elle devrait fonctionner.

Answer 3

Personnellement, je me tournerais vers WLST pour effectuer des mises à jour massives de domaines. C'est très simple même si vous n'avez aucune expérience avec python ou WLST.

1. activer l'enregistrement pour un domaine (interface web d'administration)
2. faire vos changements sur un seul domaine (interface web d'administration)
3. activer les changements (interface web d'administration)
4. vous devriez obtenir un python script dans votre dossier de domaine par défaut
5. pour chaque environnement
   1. se connecter au serveur d'administration avec WLST
   2. appliquer votre script.
   3. redémarrer le domaine ou les serveurs gérés si nécessaire

Actuellement, la société pour laquelle je travaille fait une chose similaire à ce que vous décrivez : elle bidouille les fichiers du domaine weblogic et déploie ensuite les mêmes fichiers avec de petites modifications dans tous nos environnements. Au fil des ans, nous nous sommes retrouvés avec un véritable fouillis. Ce n'est tout simplement pas la bonne méthode.

Answer 4

Nous avons utilisé WLST. Nous utilisons une sorte de "modèle de domaine" déclaratif simple en python qui est plutôt abstrait (c'est-à-dire qu'il ne spécifie pas la configuration des différents serveurs dans un cluster, dans nos environnements tous les nœuds doivent être identiques). Ce modèle est assez court (2-3 pages pour les plus grandes applications qui ont plus de 30 pools de connexion, un tas de trucs JMS et quelques fournisseurs JMS étrangers). Ensuite, nous avons 2 scripts : le premier crée un domaine vide dans l'environnement cible, le second applique le modèle de domaine. Pour collecter les changements effectués par les développeurs dans l'environnement "maître", nous disposons d'un scripts qui parcourt la configuration du domaine et produit le fichier de modèle. En utilisant un diff sur ces fichiers de modèle, nous pouvons voir ce qui a été modifié.

Ce cadre semble lourd, mais il permet de gagner beaucoup de temps lorsque nous devons gérer des environnements de développement, de test, de mise en scène et de production pour plus de 100 applications.

Pour les petits cas, il suffit de copier les fichiers et d'utiliser le même SerializedSystemIni.dat. Veillez simplement à ce que votre nom de domaine reste le même, et adaptez les adresses/ports. Si vous souhaitez utiliser un SerializedSystemInit.dat différent, il est assez facile de le faire également, en se basant sur ce code ( http://gustlik.wordpress.com/2008/08/06/decryption-of-configuration-passwords-in-weblogic/ ), il est assez facile d'écrire un utilitaire qui décodera le mot de passe avec le SerializedSystemIni.dat original et l'encodera avec un nouveau. Ceci devrait faire l'affaire.