Maven Implementar en varios servidores Tomcat

Question

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

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

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

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

Answer 1

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>  

A continuación, sólo tendrá que ejecutar X veces el comando mvn, con el parámetro adecuado (-Denv = foo1, -Denv = foo2, ...)

---

Además de eso, puede mejorar esta solución por nosotros ing la característica de matriz del servidor de integración continua Hudson. Di una breve explicación sobre esta característica here.

Básicamente, usted solo 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, se crea el trabajo de Hudson, y luego se define el "eje del medio ambiente", con todos los valores posibles para el parámetro env :

• foo1
• foo2
• foo3
• .. .

Hudson entonces generar la aplicación con el comando mvn y con el parámetro -De nv = foo1 .Una vez esta construcción está terminado, se va a construir la misma aplicación pero con el parámetro -Denv = foo2, y así sucesivamente ...

De esta manera, Hudson desplegará su aplicación en cada entornos. ..

espero que mi solución ayudará a alcanzar sus objetivos ...

Answer 2

Tal vez la solución "más mínima" no es mínimo en absoluto. Si tiene problemas para hacerlo en Maven, intente usar hormiga: 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 hormiga. Just google them. Hecho esto, necesita integrar las nuevas tareas ant en maven, que no es nada complicado usando el plugin antrun.

Answer 3

Esta respuesta es para el embarcadero y para una situación ligeramente diferente, pero puede que le sirva de ayuda.

En un proyecto anterior, utilizamos Jetty, así que escribí un módulo de implementación simple de Jetty que escaneaba periódicamente el repositorio de maven y descargaba e implementaba nuevos artefactos tan pronto como estuvieran disponibles. Esto funcionó bien en un pequeño grupo de máquinas de etapas y desarrollo.

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

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

Answer 4

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

Puede obtener un poco más de fantasía 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 URL de servidor codificadas.

<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 utilizado anteriormente fue desplegado manualmente a nuestro repositorio Maven distribuido, que se pueden encontrar en el directorio lib de la distribución de Tomcat.

Answer 5

Esta es una respuesta bastante tardía a una pregunta anterior, pero estoy bastante seguro de que a la gente le interesará. Acabo de ejecutar varias implementaciones usando tareas de maven y ant. El secreto es usar un macrodef (o 2 para mí como yo caliente despliego mis aplicaciones en el embarcadero y la necesidad de transferir una guerra y un archivo XML) y el uso de un archivo de propiedades de hormigas:

<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 usted necesidades de archivo de propiedades a ser algo así 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 opción por configuración del servidor utilizado por

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

El truco es que el atributo macrodef usando @ {} como prioridad sobre la evaluación de la propiedad $ { } en hormiga