Как перенести Weblogic config.xml на несколько компьютеров?

Question

наша команда разработчиков разрабатывает приложение J2EE, которое работает на Weblogic 10.3.Каждая машина разработки запускает свою собственную копию сервера приложений Weblogic 10.3.Домен Weblogic среды разработки был первоначально создан на одной машине, а затем скопирован на все машины с помощью средства настройки Weblogic (bea10/wlserver_10.3/common/bin/config.cmd).

Каждая машина для разработки имеет свою собственную копию config.xml.Все парольные фразы (для источников данных JDBC и т.д.) В этом файле зашифрованы, и шифрование, по-видимому, использует разные исходные данные на каждой машине, поскольку один и тот же пароль имеет разные зашифрованные формы на разных машинах.

Проблема в том, что время от времени config.xml требуется обновление (например, при добавлении нового EJB), и обновления необходимо применять на всех машинах.Как нам следует это сделать?Если мы просто поместим файл в CVS и обновим оттуда другие компьютеры, зашифрованные пароли на каждом компьютере будут перезаписаны.Это приводит к уродливым исключениям paddingexceptions, когда сервер пытается расшифровать кодовые фразы, первоначально зашифрованные на другом компьютере.

Есть ли ant-задача (я не смог ее найти) или аналогичный механизм, который позаботился бы о правильном объединении изменений в config.xml без перезаписи зашифрованных паролей?Или можно каким-то образом указать кодовые фразы открытым текстом и зашифровать их при первом запуске (у меня есть смутное воспоминание, что это было возможно в предыдущих версиях, но не в 10.3).

Как команды разработчиков, работающие над Weblogic, справляются с этим?

БР,

Марко

Answer 1

[...] Каждая машина разработки имеет свою собственную копию config.xml.Все кодовые фразы (для JDBC источников данных и т.д.) В этом файле зашифрованы...

Да, WebLogic Server шифрует все текстовые пароли, хранящиеся в XML-файлах конфигурации домена.Это делается для предотвращения доступа к конфиденциальной информации.Когда пароли вводятся с помощью консоли администрирования или инструментов создания сценариев, они автоматически шифруются перед сохранением в XML-файлах конфигурации.

...и шифрование по-видимому, использует разные исходные данные на каждой машине, поскольку один и тот же пароль имеет разные зашифрованные формы на разных машинах.

О the the шифровать утилита (из Oracle WebLogic Server Java Utilities), говорится в документации:

Тот Самый weblogic.security.Encrypt шифрует строки открытого текста для использования с сервером WebLogic.Утилита использует службу шифрования текущего каталога или службу шифрования для указанного корневого каталога домена WebLogic Server.

Примечание: Зашифрованная строка должна быть зашифрована службой шифрования в домене сервера WebLogic, где она будет использоваться.В противном случае сервер не сможет расшифровать строку.

В документации об этом не упоминается, но, AFAIK, Weblogic использует солевой файл пароля домена (SerializedSystemIni.dat) для шифрования открытой текстовой строки.

[...] Если мы просто поместим файл в CVS и обновим оттуда другие компьютеры, зашифрованные пароли на каждом компьютере будут перезаписаны.

Вы могли бы использовать пароли в виде открытого текста в разделе config.xml, хранящемся в вашем VCS (если это не проблема).На самом деле, до выхода WebLogic Server 9.0 пароли шифровались при последующем перезапуске.Начиная с WebLogic Server 9.0, использование паролей с открытым текстом в файлах конфигурации "полностью" поддерживается только для домена разработки, и Weblogic не будет повторно шифровать пароли.В обоих случаях это позволило бы людям без проблем ознакомиться с конфигурационным файлом.

Есть ли ant-задача (я не смог ее найти) или аналогичный механизм, который позаботился бы о правильном объединении изменений в config.xml без перезаписи зашифрованных паролей?...

Я не уверен, что это прямо отвечает на ваш вопрос, но Oracle WebLogic Server предоставляет Муравьиные задачи для большинства (если не для всех) своих Java-утилит.Может быть, вы найдете там что-то полезное (ознакомьтесь Настройка домена сервера WebLogic С помощью Муравьиной задачи wlconfig)

Или можно каким-то образом указать кодовые фразы открытым текстом и зашифровать их при первом запуске (у меня есть смутное воспоминание, что это было возможно в предыдущих версиях, но не в 10.3).

Как я писал выше, это было поведение "по умолчанию" до Weblogic Server 9.0.Я не знаю, можете ли вы принудительно применить это поведение для более поздних версий.Конечно, вы всегда можете использовать ant и шифровать сделать это, но, честно говоря, если вы позволяете людям видеть пароли в открытом виде один раз, я действительно не вижу смысла шифровать их после того, как выяснятся факты.

Answer 2

Я бы использовал что-то вроде mercurial или git, а также функцию экспорта/импорта, чтобы изменения переносились в различия, а не в полные файлы.

Краткие инструкции

Что ж, если вы застряли в CVS (извините, я в некоторой степени разделяю вашу боль), вы можете подумать о создании репозитория различий CVS.Например.когда создается новая версия файла конфигурации, новый файл сравнивается со старым файлом, и файл различий добавляется в репозиторий, другие хосты извлекаются из cvs и исправляют файл конфигурации.

Это хак, но должен работать.

Answer 3

Лично я бы рассмотрел WLST для массовых обновлений домена.Это действительно просто, даже если у вас нет опыта работы с Python или WLST.

1. включить запись для домена (веб-интерфейс администратора)
2. вносите изменения в один домен (веб-интерфейс администратора)
3. активировать изменения (веб-интерфейс администратора)
4. вы должны получить скрипт Python в папке домена по умолчанию
5. для каждой среды
   1. подключитесь к серверу администратора с помощью WLST
   2. применить свой сценарий
   3. перезагрузите домен или управляемые серверы, если необходимо

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

Answer 4

Мы сделали это с помощью WLST.Мы используем какую-то простую декларативную «модель предметной области» в Python, которая довольно абстрактна (т.е.он не определяет конфигурацию разных серверов в кластере, в наших средах все узлы должны быть идентичными).Эта модель довольно короткая (2-3 страницы для самых больших приложений, имеющих более 30 пулов соединений, кучу JMS-материалов и некоторых иностранных поставщиков JMS).После этого у нас есть 2 скрипта:сначала создается пустой домен в целевой среде, второй применяет модель домена.Для сбора изменений, которые разработчики вносят в «главную» среду, у нас есть скрипт, который просматривает конфигурацию домена и выводит файл модели.Используя разницу в этих файлах модели, мы можем увидеть, какие изменения были внесены.

Это выглядит как тяжеловесный фреймворк, но он действительно экономит много времени, когда нам приходится управлять средами разработки, тестирования, промежуточной и производственной среды для более чем 100 приложений.

В небольших случаях достаточно просто скопировать файлы и использовать тот же SerializedSystemIni.dat.Просто убедитесь, что ваше доменное имя осталось прежним, настройте адреса/порты.Если вы хотите использовать другой SerializedSystemInit.dat, это также довольно легко сделать на основе этого кода (http://gustlik.wordpress.com/2008/08/06/decryption-of-configuration-passwords-in-weblogic/) довольно легко написать утилиту, которая будет декодировать пароль оригинальным SerializedSystemIni.dat и кодировать новым.Это должно сработать.