Отделение конфигураций от WAR / EAR для развертываний Puppet

Question

Мы часто развертываем веб-приложения Java на серверах Weblogic и Jboss. Довольно часто развертывание выглядит так:

1. Скопируйте код и конфигурации по умолчанию в промежуточный каталог на сервере приложений или административном сервере Weblogic.

2. Отредактируйте файл свойств, чтобы установить переменные, зависящие от среды (IP-адреса, имена пользователей и т. д.)

3. Запустите ant, чтобы создать ear / war и поместите его в соответствующий каталог.

4. Запустить службы

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

Есть ли способ создать войну / ухо, не зависящую от среды, и сохранить внешние конфигурации, удалив лишний этап сборки?

Кто-нибудь специально работал с веб-приложениями и Puppet, и есть ли у вас какие-либо рекомендации?

Answer 1

Что я сделал с tomcat и .war webapps, так это построил системный пакет с распакованной war, а затем обработал файлы conf. Я вообще не имел дела с Weblogic или JBoss, поэтому не знаю, как они работают с разархивированными файлами WAR.

1) Создайте пакет (RPM), в котором я занимаюсь сборкой файлов .war, а затем что-то вроде:

родовое слово

(чтобы распакованный файл .war находился в пакете без реального файла .war. С tomcat он оставит этот каталог в покое, особенно если у него нет доступа на запись, потому что файлы принадлежат пользователю root)

2) Кукольный материал вроде:

родовое слово

В этом конкретном пакете 32 файла в 8 каталогах, которые мы модифицируем или выталкиваем, чтобы настроить его. Если бы это было всего несколько файлов, я бы использовал пару простых ресурсов file{} для управления этими файлами вместо рекурсивного материала.

Если вы не хотите создавать пакет системного типа, вы можете сделать ресурс file{} для войны в альтернативном каталоге, создать код exec{"unzip ...": creates => '/path/to/unzipped/webapp;} и сделать так, чтобы ресурсы file{} для конфигурации потребовали создания кода Exec["unzip ..."].