Was ist das minimalste Beispiel für die Bereitstellung eines War auf mehrere Tomcat-Server mit Maven, die geschrieben werden kann?
Ich habe die folgenden URLs ausprobiert und die Mailingliste befragt, aber ich habe nichts gefunden, was kurz ist und einfach funktioniert.
Im Beispiel sollten die Server irgendwo im Beispiel definiert sein (mit Beispiel-Benutzernamen/Passwörtern)
Die Idee von Markus Lux lässt sich auch mit einer Maven2-Lösung, mit der Profilverwaltung, umsetzen:
<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> Dann müssen Sie nur noch X-mal die mvn mit dem entsprechenden Parameter ( -Denv=foo1 , -Denv=foo2 ,...)
Darüber hinaus können Sie diese Lösung durch die Verwendung der Matrix-Funktion des Programms Hudson Server für kontinuierliche Integration. Ich habe eine kurze Erklärung zu dieser Funktion gegeben aquí .
Im Grunde definieren Sie einfach einen "normalen" Maven2-Job in Hudson, und mit der Matrix-Funktion können Sie Hudson bitten, diesen Job mehrmals auszuführen, einen pro Umgebung. Mit anderen Worten, Sie erstellen Ihren Hudson-Job und definieren dann die "Umgebungsachse" mit allen möglichen Werten für die env Parameter:
Hudson erstellt dann die Anwendung mit dem mvn Befehl und mit dem Parameter -Denv=foo1 Sobald dieser Build abgeschlossen ist, wird die gleiche Anwendung erstellt, jedoch mit dem Parameter -Denv=foo2 und so weiter...
Auf diese Weise wird Hudson Ihre Anwendung in jeder Umgebung einsetzen...
Ich hoffe, meine Lösung wird Ihnen helfen, Ihre Ziele zu erreichen...
Heilige Scheiße, das ist potenziell sehr nützlich, wie Hudson ist genau das, was ich war Targeting mit diesem in....
Das Komische ist, dass dies dem ähnelt, was der von mir angegebene Link andeutet, aber es ist nicht ganz klar. Kann es nicht erwarten, es zu versuchen.
Bei der Verwendung mehrerer Profile schien der Lebenszyklus bestimmte Schritte zu duplizieren - z. B. verdoppelte sich die Anzahl der Tests, wenn Profile verwendet wurden, die durch Variablen aktiviert wurden. Wir fanden, dass die Verwendung der catalina-ant Bibliothek viel effektiver ;) und "minimaler" war. Verwenden Sie das "executions"-Element, um das "run"-Ziel an eine Lebenszyklus-Phase anzuhängen, um sie zu straffen, oder führen Sie sie nach dem Paket aus: mvn package antrun:run
Man könnte mit der ant-contrib-Bibliothek noch ein bisschen schlauer werden und eine for-Schleife mit einer Liste von Servern erstellen, aber hier ist eine statische Konfiguration für 2 fest kodierte Server-URLs.
<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>Die oben verwendete Version von catalina-ant wurde manuell in unser verteiltes Maven-Repository eingespielt und befindet sich im lib-Verzeichnis der Tomcat-Distribution.
Dies ist eine ziemlich späte Antwort auf eine alte Frage, aber ich bin mir ziemlich sicher, dass die Leute daran interessiert sein werden. Ich habe es gerade geschafft, mehrere Deployments mit Maven und Ant-Tasks durchzuführen. Das Geheimnis ist die Verwendung eines macrodef (oder 2 für mich, wie ich heiß meine Anwendungen in Jetty bereitstellen und müssen eine war und eine xml-Datei zu übertragen) und mit einer ant-Eigenschaft Datei:
<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>Dann muss Ihre Eigenschaftsdatei etwa so aussehen wie :
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=usw... in einem Block von Optionen pro Serverkonfiguration, die von
<deploy-app config="<config>"/>Der Trick ist, dass das macrodef-Attribut mit @{} Vorrang vor der Eigenschaftsbewertung ${} in ant hat.
Vielleicht ist die "minimalste" Lösung gar nicht minimal. Wenn Sie Probleme damit haben, dies in Maven selbst zu tun, versuchen Sie es mit Ant: Erstellen Sie zwei verschiedene Deploy-Aufgaben (eine pro Server) und eine weitere Aufgabe, die sie als Abhängigkeiten hat. Es gibt mehrere Beispiele für die Bereitstellung auf einem Tomcat-Server mit ant. Googeln Sie einfach nach ihnen . Ist dies geschehen, müssen Sie die neuen Ant-Tasks in Maven integrieren, was mit Hilfe des antrun Plugin.
Diese Antwort ist für Jetty und für eine etwas andere Situation, aber vielleicht finden Sie sie trotzdem nützlich.
Bei einem früheren Projekt haben wir Jetty verwendet, also habe ich ein einfaches Jetty-Deployer-Modul geschrieben, das regelmäßig das Maven-Repository durchsucht und neue Artefakte herunterlädt und bereitstellt, sobald sie verfügbar sind. Dies lief gut auf einem kleinen Cluster von Staging- und Entwicklungsmaschinen.
Sie finden den Code bei Google Code im Bereich Polar Rose Jetty Maven Deployer Projekt.
Beachten Sie, dass wir dies nur für Entwicklungs- und Staging-Server getan haben. Meiner Meinung nach sollten Produktionsanwendungen niemals automatisch aktualisiert werden.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
