Separando configurações do WAR/EAR para implantações do Puppet

Question

Fazemos muitas implantações de aplicativos web Java em servidores Weblogic e Jboss.Muitas vezes, a implantação é assim:

1. Copie o código e as configurações padrão para um diretório temporário no servidor de aplicativos ou servidor administrativo do Weblogic.

2. Edite um arquivo de propriedades para definir variáveis ​​específicas do ambiente (endereços IP, nomes de usuário, etc.)

3. Execute ant para criar o ear/war e solte-o no diretório apropriado.

4. Iniciar serviços

Este provou ser um conjunto de etapas muito hostil para usar com o Puppet como nossa ferramenta de gerenciamento de configuração.Preferiríamos um processo que fosse muito mais semelhante ao trio Package, File, Service do Puppet, mas ter que configurar as propriedades antes de construir o ear/war torna isso difícil porque requer uma etapa extra para construir o war/ear no host após as propriedades terem sido preenchidas.

Existe uma maneira de construir um war/ear que seja independente do ambiente e mantenha as configurações externas, removendo a etapa extra de construção?

Alguém trabalhou especificamente com aplicativos da web e Puppet e você tem alguma recomendação?

Answer 1

O que eu fiz com gato e .war webapps é construir um pacote de sistema com um war descompactado e então lidar com os arquivos conf.Eu não lidei muito com Weblogic ou JBoss, então não sei como ele lida com coisas WAR descompactadas.

1) Construa um pacote (RPM) onde eu faço todo o material de construção do .war, depois algo como:

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

(para que o arquivo .war descompactado esteja no pacote sem nenhum arquivo .war real nele.Com o Tomcat, ele deixará esse diretório em paz, especialmente se não tiver acesso de gravação porque os arquivos pertencem ao root)

2) Coisas de fantoches mais ou menos como:

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
}

Este pacote específico possui 32 arquivos em 8 diretórios que estamos modificando ou enviando para configurá-lo.Se fossem apenas alguns arquivos, eu usaria alguns simples file{} recursos para gerenciar esses arquivos em vez do material recursivo.

Se você não quisesse construir um pacote do tipo sistema, você poderia fazer um file{} recurso para a guerra em um diretório alternativo, um exec{"unzip ...": creates => '/path/to/unzipped/webapp;} e tenha o file{} recursos para configuração exigem o Exec["unzip ..."].