Отделение конфигов от WAR / EAR для развертываний Puppet - PullRequest
Новая
       28

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

4 голосов
/ 02 декабря 2011

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

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

  2. Редактирование файла свойств для задания переменных среды (IP-адреса, имена пользователей и т. Д.)

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

  4. Старт услуг

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

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

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

1 Ответ

4 голосов
/ 02 декабря 2011

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

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

mkdir -p %{buildroot}/var/lib/tomcat5/webapps/APP
cd %{buildroot}/var/lib/tomcat5/webapps/APP
unzip ../APP.war
rm ../APP.war

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

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

package {
  "tomcat5":
    require => Package["java-1.6.0-sun"],
    ensure => installed;
  "java-1.6.0-sun":
    ensure => installed;
  "APP":
    ensure => installed,
    notify => Service["tomcat5"],
    require => Package["java-1.6.0-sun"];
}

file {
  "/usr/share/tomcat5/webapps/APP":
    source  => [ "puppet:///MODULE/APP" ],
    ensure  => directory,
    ignore  => [ 'CVS', '.git', '.svn', '*~' ], # ignore revision control and backup files
    purge   => false, # leaves other stuff alone
    replace => true, # replaces stock files with ours
    recurse => true, # gets everything recursively
    require => Package[APP], # install package first
    notify  => Service[tomcat5]; # restart tomcat after
}

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

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

...