Развертывание Maven на нескольких серверах Tomcat - PullRequest
Новая
       21

Развертывание Maven на нескольких серверах Tomcat

19 голосов
/ 09 апреля 2009

Какой самый минимальный пример развертывания войны на нескольких серверах tomcat с использованием maven, который можно записать?

Я попробовал следующие URL-адреса и спросил список рассылки, но не придумал ничего короткого и просто сработавшего.

В этом примере где-то должны быть определены серверы (с примерами имен пользователей / паролей)

Ответы [ 5 ]

25 голосов
/ 21 апреля 2009

Идея 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 вы можете попросить Hudson запустить это задание несколько раз, по одному для каждой среды. Другими словами, вы создаете задание Hudson, а затем определяете «ось среды» со всеми возможными значениями параметра env :

  • foo1
  • foo2
  • foo3
  • ...

Затем Hudson создаст приложение с помощью команды mvn и с параметром -Denv = foo1 . После завершения сборки будет построено то же приложение, но с параметром -Denv = foo2 и т. Д. *

Таким образом, Hudson развернет ваше приложение в любой среде ...

Я надеюсь, что мое решение поможет вам достичь ваших целей ...

8 голосов
/ 06 января 2011

Что касается использования нескольких профилей, жизненный цикл, казалось, дублировал определенные этапы - например, количество тестов удваивается при использовании профилей, активированных переменными. Мы обнаружили, что использование библиотеки catalina-ant намного эффективнее;) и более «минимально». Используйте элемент «execute», чтобы присоединить цель «run» к фазе жизненного цикла, чтобы упростить ее, или запустить после package: mvn package antrun: run

Вы можете получить немного больше пользы от библиотеки ant-contrib и создать цикл for со списком серверов, но вот статическая конфигурация для двух жестко закодированных 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>

Специальная версия catalina-ant, использованная выше, была вручную развернута в нашем распределенном репозитории maven, ее можно найти в каталоге lib дистрибутива tomcat.

2 голосов
/ 14 января 2012

Это довольно поздний ответ на старый вопрос, но я уверен, что люди будут заинтересованы в нем. Я только что выполнил несколько развертываний, используя задачи maven и ant. Секрет заключается в том, чтобы использовать macrodef (или 2 для меня, когда я в горячем режиме развертываю свои приложения в Jetty и мне нужно передать файл war и 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 использует @ {} в качестве приоритета над оценкой свойства $ {} в муравье.

1 голос
/ 19 апреля 2009

Возможно, «самое минимальное» решение вовсе не минимальное. Если у вас есть проблемы с этим в самом maven, попробуйте использовать ant: создайте две разные задачи развертывания (по одной на сервер) и другую задачу, в которой они находятся в качестве зависимостей. Есть несколько примеров того, как выполнить развертывание на сервере Tomcat с помощью ant. Просто погуглите их . Для этого вам нужно интегрировать новые задачи ant в maven, что совсем не сложно, используя плагин antrun .

0 голосов
/ 23 апреля 2009

Этот ответ для Jetty и для немного другой ситуации, но вы все равно можете найти его полезным.

В предыдущем проекте мы использовали Jetty, поэтому я написал простой модуль развертывания Jetty, который будет периодически сканировать репозиторий maven и загружать и развертывать новые артефакты, как только они станут доступны. Это хорошо работало на небольшом кластере машин для разработки и разработки.

Код можно найти в Google Code в проекте Polar Rose Jetty Maven Deployer .

Обратите внимание, что мы сделали это только для серверов разработки и промежуточных версий. По моему мнению, производственные приложения никогда не должны обновляться автоматически.

...