Каков самый минимальный пример развертывания войны на нескольких серверах tomcat с использованием maven, который можно записать?
Я пробовал следующие URL-адреса и задавал список рассылки, но не придумывал что-то короткое и просто работал.
В примере должны быть указаны серверы, определенные в примере где-нибудь (с примерами имен пользователей/паролей)
Идея Markus Lux также может применяться с решением Maven2 с управлением профилями:
<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>
Затем вам просто нужно запустить X раз команду mvn с соответствующим параметром (-Denv = foo1, -Denv = foo2,...)
В дополнение к этому вы можете улучшить это решение, используя функцию Matrix Hudson Сервер непрерывной интеграции. Я кратко рассказал об этой функции здесь.
В принципе, вы просто определяете "нормальную" работу Maven2 в Hudson и с помощью функции Matrix, вы можете попросить Хадсона запустить эту работу несколько раз, по одному на среду. В других словах вы создаете свое задание Хадсона, а затем определяете "ось окружения" со всеми возможными значениями для параметра env:
Затем Хадсон будет создавать приложение с помощью команды mvn и с параметром -Denv = foo1.Once эта сборка завершена, она будет создавать одно и то же приложение, но с параметром -Denv = foo2, и так далее...
Таким образом, Hudson будет развертывать ваше приложение в любой среде...
Я надеюсь, что мое решение поможет вам достичь ваших целей...
Что касается использования нескольких профилей, жизненный цикл, казалось, дублировал определенные шаги - например. количество тестов удваивается при использовании профилей, активируемых переменными. Мы обнаружили, что использование каталитической библиотеки было намного более эффективным;) и более "минимальным". Используйте элемент "Исполнения", чтобы привязать цель "выполнить" к фазе жизненного цикла, чтобы упорядочить ее или запустить после пакета: mvn package antrun: run
Вы могли бы немного походить на библиотеку ant -contrib и создать цикл for со списком серверов, но здесь статическая конфигурация для 2 жестких кодированных серверных URL-адресов.
<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>
Конкретная версия каталинии ant, использованная выше, была вручную развернута в нашем распределенном репозитории maven, ее можно найти в каталоге lib для дистрибутива tomcat.
Это довольно поздний ответ на старый вопрос, но я уверен, что люди будут в этом заинтересованы. Я просто добился выполнения нескольких развертываний с использованием задач maven и ant. Секрет заключается в использовании макродефа (или 2 для меня, когда я горячо развертываю свои приложения в причале и должен переносить войну и файл xml) и используя файл свойств 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>
Затем файл свойства должен выглядеть примерно так:
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=
и т.д. на блоке опций на конфигурацию сервера, используемой
<deploy-app config="<config>"/>
Фокус в том, что атрибут macrodef использует @{} как приоритет над оценкой свойства ${} в ant.
Возможно, "самое минимальное" решение не является минимальным. Если у вас есть проблемы с этим в maven, попробуйте использовать ant: создайте две разные задачи развертывания (по одному на один сервер) и другую задачу, которая имеет их как зависимости. Существует несколько примеров развертывания на сервере tomcat с помощью ant. Просто Google. Сделав это, вам нужно интегрировать новые задачи ant в maven, что совсем не сложно с помощью плагина antrun.
Этот ответ для Jetty и для немного другой ситуации, но вы можете найти его полезным в любом случае.
В предыдущем проекте мы использовали Jetty, поэтому я написал простой модуль развертывания Jetty, который периодически просматривал репозиторий maven и загружал и развертывал новые артефакты, как только они стали доступны. Это хорошо работает на небольшом кластере машин для разработки и разработки.
Код в коде Google можно найти в проекте Проект Polar Rose Jetty Maven Deployer.
Обратите внимание, что мы сделали это только для серверов разработки и промежуточного уровня. По-моему, производственные приложения никогда не должны обновляться автоматически.