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

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 и обновим другие машины, там зашифрованные пароли на каждой машине будут перезаписаны. Это приводит к уродливым дополнениям, когда сервер пытается дешифровать фразы, первоначально зашифрованные на другой машине.

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

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

BR,

Марко

Answer 1

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

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

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

О encrypt утилита (от Oracle WebLogic Server Java Utilities), документация говорит:

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

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

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

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

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

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

Я не уверен, что это напрямую отвечает на ваш вопрос, но Oracle WebLogic Server предоставляет Ant tasks для большинства (если не всех) своих Java-приложений. Может быть, вы найдете что-то полезное там (проверить Configuring a WebLogic Server Domain Using the wlconfig Ant Task)

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

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

Answer 2

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

Short instructions

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

Это взлом, но он должен работать.

Answer 3

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

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

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

Answer 4

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

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

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