framework - Implementar Maven a múltiples servidores Tomcat

material design jsf

Question

¿Cuál es el ejemplo más mínimo de implementación de una guerra en varios servidores tomcat que utilizan maven que se puede escribir?

Probé las siguientes URL y le pedí a la lista de correo, pero no encontré nada que fuera breve y que simplemente funcionara.

• http://www.nabble.com/Deploying-to-Multiple-Servers-at-Once-td21592419.html

El ejemplo debe tener los servidores definidos en el ejemplo en algún lugar (con nombres de usuario / contraseñas de muestra)

Answer 1

Con respecto al uso de múltiples perfiles, el ciclo de vida parecía duplicar ciertos pasos, por ejemplo, el número de pruebas se duplicó al usar perfiles activados por variables. Encontramos que usar la biblioteca catalina-ant fue mucho más efectivo;) y es más "mínimo". Use el elemento "ejecuciones" para adjuntar el objetivo "ejecutar" a una fase del ciclo de vida para simplificarlo, o ejecute después del paquete: mvn package antrun: run

Podría ser un poco más sofisticado con la biblioteca ant-contrib y crear un bucle for con una lista de servidores, pero aquí hay una configuración estática para 2 urls de servidor codificados.

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.6</version>
<configuration>
<target>
<taskdef name="deploy" classname="org.apache.catalina.ant.DeployTask"/>
<deploy url="http://tc-app-01:8080/manager" username="manager" password="pass"
path="/app-path" war="file:${project.build.directory}/${project.build.finalName}.${project.packaging}" update="true"/>
<deploy url="http://tc-app-02:8080/manager" username="manager" password="pass"
path="/app-path" war="file:${project.build.directory}/${project.build.finalName}.${project.packaging}" update="true"/>
</target>
</configuration>
<dependencies>
<dependency>
<groupId>tomcat</groupId>
<artifactId>catalina-ant</artifactId>
<version>6.0.29</version>
</dependency>
</dependencies>
</plugin>

La versión específica de catalina-ant utilizada anteriormente se implementó manualmente en nuestro repositorio Maven distribuido, se puede encontrar en el directorio lib de la distribución tomcat.

Answer 2

Esta es una respuesta bastante tardía a una vieja pregunta, pero estoy bastante seguro de que la gente estará interesada en ella. Acabo de ejecutar múltiples implementaciones utilizando tareas de maven y ant. El secreto es usar un macrodef (o 2 para mí cuando implemento mis aplicaciones en el embarcadero y necesito transferir una guerra y un archivo xml) y usar un archivo de propiedades ant:

<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<phase>install</phase>
<configuration>
<tasks>
<taskdef name="scp"
classname="org.apache.tools.ant.taskdefs.optional.ssh.Scp"
classpath="/usr/local/java/ant/lib/ant-jsch.jar:/usr/local/java/ant/lib/jsch-0.1.45.jar" />
<macrodef name="deploy">
<attribute name="server" default="NOT SET" />
<attribute name="file" default="NOT SET" />
<attribute name="todir" default="NOT SET" />
<attribute name="port" default="NOT SET" />
<attribute name="passphrase" default="NOT SET" />
<attribute name="keyfile" default="NOT SET" />
<sequential>
<echo message="Deploying to @{server}" />
<echo message="Deploying @{file} to @{todir}" />
<scp
file="@{file}" todir="@{todir}"
port="@{port}" passphrase="@{passphrase}"
keyfile="@{keyfile}" />
</sequential>
</macrodef>
<macrodef name="deploy-app">
<attribute name="config" default="NOT SET" />
<sequential>
<property file="deploy.properties"/>
<echo message="Deploying to @{config}" />
<deploy server="${@{config}.jetty.server.host}"
file="${project.build.directory}/${project.build.finalName}.${project.packaging}"
todir="${@{config}.jetty.server.user}@${@{config}.jetty.server.host}:${@{config}.jetty.server.baseDir}/${@{config}.jetty.server.webappsDir}"
port="${@{config}.jetty.server.port}"
passphrase="${@{config}.jetty.server.passphrase}"
keyfile="/home/steff/.ssh/id_rsa"/>
<deploy server="${@{config}.jetty.server.host}"
file="${project.build.finalName}.xml"
todir="${@{config}.jetty.server.user}@${@{config}.jetty.server.host}:${@{config}.jetty.server.baseDir}/${@{config}.jetty.server.contextDir}"
port="${@{config}.jetty.server.port}"
passphrase="${@{config}.jetty.server.passphrase}"
keyfile="/home/steff/.ssh/id_rsa"/>
</sequential>
</macrodef>
<deploy-app config="home"/>
<deploy-app config="wap"/>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>

Entonces tu archivo de propiedades debe ser algo como:

home.jetty.server.user=
home.jetty.server.port=
home.jetty.server.host=
home.jetty.server.baseDir=
home.jetty.server.webappsDir=
home.jetty.server.contextDir=
home.jetty.server.passphrase=
wap.jetty.server.user=
wap.jetty.server.port=
wap.jetty.server.host=
wap.jetty.server.baseDir=
wap.jetty.server.webappsDir=
wap.jetty.server.contextDir=
wap.jetty.server.passphrase=

etc ... en un bloque de opciones por configuración de servidor utilizado por

<deploy-app config="<config>"/>

El truco es que el atributo macrodef usa @ {} como precedencia sobre la evaluación de propiedades $ {} en ant.

Answer 3

Esta respuesta es para Jetty y para una situación ligeramente diferente, pero puede que le resulte útil de todos modos.

En un proyecto anterior, usamos Jetty, así que escribí un sencillo módulo de implementación de Jetty que escanearía periódicamente el repositorio de Maven y descargaría y desplegaría nuevos artefactos tan pronto como estuvieran disponibles. Esto funcionó bien en un pequeño grupo de máquinas de preparación y desarrollo.

Puede encontrar el código en Google Code en el proyecto de Despliegue Polar Rose Jetty Maven .

Tenga en cuenta que solo hicimos esto para los servidores de desarrollo y de ensayo. En mi opinión, las aplicaciones de producción nunca deberían actualizarse automáticamente.

Answer 4

La idea de Markus Lux también se puede aplicar con una solución Maven2, con la gestión de perfiles:

<build>
<plugins>
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
</plugin>
</plugins>
...
</build>
<profiles>
<profile>
<id>env-foo1</id>
<!-- Activated when -Denv=foo1 is given as parameter. -->
<activation>
<property>
<name>env</name>
<value>foo1</value>
</property>
</activation>
<properties>
<deploy.env>xxx</deploy.env>
<tomcat.manager>http://foo1/manager</tomcat.manager>
<tomcat.manager.username>foo</tomcat.manager.username>
<tomcat.manager.password>bar</tomcat.manager.password>
</properties>
</profile>
<profile>
<id>env-foo2</id>
<!-- Activated when -Denv=foo2 is given as parameter. -->
<activation>
<property>
<name>env</name>
<value>foo2</value>
</property>
</activation>
<properties>
<deploy.env>dev</deploy.env>
<tomcat.manager>http://foo2/manager</tomcat.manager>
<tomcat.manager.username>foo</tomcat.manager.username>
<tomcat.manager.password>bar</tomcat.manager.password>
</properties>
</profile>
...
</profiles> 

Luego, solo necesitará ejecutar X veces el comando mvn , con el parámetro adecuado ( -Denv = foo1 , -Denv = foo2 , ...)

Además, puede mejorar esta solución utilizando la función Matrix del servidor de integración continua de Hudson . Di una breve explicación sobre esta característica here .

Básicamente, simplemente define un trabajo Maven2 "normal" en Hudson, y con la función Matrix, puede pedirle a Hudson que ejecute este trabajo varias veces, una por entorno. En otras palabras, crea su trabajo Hudson y luego define el "eje de entorno" con todos los valores posibles para el parámetro env :

• foo1
• foo2
• foo3
• ...

Hudson luego compilará la aplicación con el comando mvn y con el parámetro -Denv = foo1. Una vez finalizada esta compilación, se construirá la misma aplicación pero con el parámetro -Denv = foo2 , y así sucesivamente ...

De esta manera, Hudson implementará su aplicación en todos los entornos ...

Espero que mi solución te ayude a alcanzar tus metas ...

Answer 5

Tal vez la solución "más mínima" no sea mínima en absoluto. Si tiene problemas para hacerlo en maven, intente usar ant: cree dos tareas de implementación diferentes (una por servidor) y otra tarea que las tenga como dependencias. Hay varios ejemplos de cómo implementar en un servidor Tomcat usando ant. Solo buscalos en google . Hecho esto, necesitas integrar las nuevas tareas ant en Maven, lo que no es difícil en absoluto con el complemento antrun .