gradle cargo plugin
1.0.0
| In den letzten Jahren hat dieses Plugin viele Veröffentlichungen verzeichnet. Vielen Dank an alle Beteiligten! Leider habe ich nicht mehr viel Zeit, um einen Beitrag zu leisten. In der Praxis bedeutet dies weitaus weniger Aktivität, Reaktionsfähigkeit in Themen und Neuveröffentlichungen von meinem Ende. |
| Ich suche aktiv nach Mitwirkenden, die bereit sind, die Wartung und Implementierung des Projekts zu übernehmen. Wenn Sie interessiert sind und gerne sehen würden, dass dieses Plugin weiterhin gedeiht, schießen Sie mir eine Post. |
Das Plugin bietet Bereitstellungsfunktionen für Webanwendungen für lokale und entfernte Container in einem bestimmten Gradle -Build, indem die Frachtameisenaufgaben genutzt werden. Das Plugin unterstützt Kriegs- und Ohrartefakte.
Der typische Anwendungsfall für dieses Plugin besteht darin, die Bereitstellung während der Entwicklung zu unterstützen. Denken Sie daran, dass Cargo einen heißen Einsatz verwendet, der im Laufe der Zeit den Permgen -Speicher des JVM -Vorgangs ausführt, aus dem Ihr Container ausgeführt wird. Die kontinuierliche Bereitstellung eines Artefakts wird zu einer java.lang.OutOfMemoryError führen. Cargo unterstützt Containermanagementfunktionen (Starten/Stoppen von Fernbehältern) über den sogenannten Frachtdämon. In kontinuierlichen Bereitstellungsszenarien möchten Sie jedoch häufig komplexere Vorgänge ausführen.
Um die Funktionalität des Plugins zu verwenden, müssen Sie das Binärartefakt zum Klassenpfad Ihres Build -Skripts hinzufügen und das Plugin anwenden.
Das Plugin -Glas muss im Klassenpfad Ihres Build -Skripts definiert werden. Es ist im Gradle -Plugin -Portal erhältlich. Das folgende Code -Snippet zeigt ein Beispiel zum Abrufen der buildscript -Syntax:
buildscript {
repositories {
gradlePluginPortal()
}
dependencies {
classpath 'com.bmuschko:gradle-cargo-plugin:2.9.0'
}
}
Die JAR -Datei wird mit zwei Plugins ausgestattet:
| Plugin -Kennung | Hängt von | Typ | Beschreibung |
|---|---|---|---|
| com.bmuschko.cargo-base | - - | Cargobaseplugin | Bietet Fracht-benutzerdefinierte Task-Typen, Klassenpfad vor der Konfiguration und Bereitstellungen. |
| com.bmuschko.cargo | com.bmuschko.cargo-base | Cargoplugin | Bietet eine Reihe lokaler und abgelegener Frachtaufgaben und enthält Erweiterung für die Konfiguration. |
Das com.bmuschko.cargo -Plugin hilft Ihnen, schnell loszulegen. Wenn Sie sich nur mit einem einzelnen Containerprodukt befassen müssen, ist dies die bevorzugbare Option. Die meisten Plugin -Benutzer entscheiden sich für diese Option. Um das Cargo -Plugin zu verwenden, geben Sie den folgenden Code -Snippet in Ihr Build -Skript ein:
apply plugin: 'com.bmuschko.cargo'
Wenn Sie Ihre Bereitstellungsaufgaben vollständig steuern, sollten Sie das Plugin com.bmuschko.cargo-base verwenden. Der Nachteil ist, dass jede Aufgabe in Ihrem Build -Skript einzeln konfiguriert werden muss. Um das Cargo Base -Plugin zu verwenden, geben Sie den folgenden Code -Snippet in Ihr Build -Skript ein:
apply plugin: 'com.bmuschko.cargo-base'
Das com.bmuschko.cargo-base -Plugin richtet bereits die Abhängigkeiten für Fracht ein. Dazu wählt es eine Standardversion der Bibliotheken. Alternativ können Sie eine benutzerdefinierte Version der Frachtbibliotheken definieren. Verwenden Sie dazu den Namen cargo in Ihrem dependencies und denken Sie nach unten:
dependencies {
def cargoVersion = '1.9.10'
cargo "org.codehaus.cargo:cargo-core-uberjar:$cargoVersion",
"org.codehaus.cargo:cargo-licensed-dtds:$cargoVersion",
"org.codehaus.cargo:cargo-ant:$cargoVersion"
}
Das cargo -Plugin definiert die folgenden Aufgaben außerhalb des Boxs:
| Aufgabenname | Hängt von | Typ | Beschreibung |
|---|---|---|---|
| cargodeployremote | - - | Cargodeployremote | Bereitstellung eines Bereitstellbarens für Remote -Container. |
| careGoundeployremote | - - | CareGoundeployremote | Unterlegt einen vom Remote -Container einsetzbaren Einsatz. |
| Cargeoreployremote | - - | Cargeoreployremote | Wiederversetzt einen im Remote -Container einsetzbaren Einsatz. |
| Cargorunlocal | - - | Cargorunlocal | Startet den lokalen Container, bereitet ein Bereitstellbar bereit und wartet darauf, dass der Benutzer Strg + C drückt, um zu stoppen. |
| CargostartLocal | - - | CargostartLocal | Startet den lokalen Container, bereitet ein Bereitstellungsabschnitt bereit und erledigte dann andere Aufgaben (z. B. Tests ausführen). |
| Cargeoreploylocal | - - | Cargeoreploylocal | Wiedereinsetzen Sie einen im lokalen Container einsetzbaren Einsatz. |
| Cargostoplokal | - - | Cargostoplokal | Stoppt den lokalen Behälter. |
| Cargoconfigurelocal | - - | Cargoconfigurelocal | Konfiguriert den lokalen Container. |
Das Fracht -Plugin verwendet das gleiche Layout wie das Kriegs -Plugin.
Das Fracht -Plugin definiert die folgenden Kongresseigenschaften im cargo :
containerId : Die Container -ID, die Sie abzielen. Bitte beachten Sie die Liste der unterstützten Container auf der Cargo -Website.port : Der TCP -Port Der Container reagiert auf (Standardeinstellungen auf 8080). In cargo können Sie optionale Eigenschaften für die 1..N -Bereitstellungsartefakte in einem Verschluss namens deployable definieren. Jedes Bereitstellungsartefakt wird in seiner eigenen Schließung angegeben:
file : Jeder Typ, der an project.files (Objekt ...) übergeben werden kann und in eine einzelne Datei oder ein Verzeichnis mit beliebigen Artefakten, explodierten Kriegsverzeichnissen und Abhängigkeitskonfigurationen für den Container (Standards an Project/Modul Artefact - War oder Ohr -Datei) aufgelöst werden kann.context : Der URL -Kontext des Containers bearbeitet Ihre Webanwendung (Standardnamen zum Krieg/Ohrnamen). Denken Sie daran, dass Sie den deployable nicht definieren müssen, wenn Sie nur das von Ihrem Gradle -Projekt/-Modul definierte Artefakt bereitstellen möchten.
In der cargo können Sie Eigenschaften für Fernbehälter in einem Verschluss namens remote definieren:
protocol : Das Protokoll des Remote -Containers (Standard zu http ).hostname : Der Hostname des Remote -Containers.username : Der Benutzername -Anmeldeinformator für den Remote -Container (optional).password : Der Kennwortanmeldeinformator für den Remote -Container (optional). In der cargo können Sie Eigenschaften für lokale Behälter in einem Verschluss namens local definieren:
jvmArgs : Die JVM -Argumente für einen lokalen Container.outputFile : Die Protokolldatei Ihres lokalen Containers (standardmäßig zum Schreiben in die Konsole).logFile : Die Ladungsprotokolldatei Ihres lokalen Containers (standardmäßig zum Schreiben in die Konsole).logLevel : Die Protokollebene für den Container mit (optional) ausführen. Die gültigen Werte sind low , medium und high .homeDir : Das Heimverzeichnis Ihrer örtlichen Containerinstallation.configHomeDir : Das Heimverzeichnis der Konfiguration Ihres lokalen Containers.configFile : Die Konfigurationsdateien, die Sie zur Konfiguration Ihres Containers hinzufügen möchten. Die configFile ist ein Verschluss selbst und erfordert, dass Sie die files und toDir bereitstellen. Eine FileCollection sollte als files verwendet werden, und toDir sollte eine String sein. Mehrere Konfigurationsdateiziele können definiert werden, indem mehr als einen configFile erstellt wird.rmiPort : Der Port, der bei der Kommunikation mit diesem Server verwendet wird, zum Beispiel, um ihn zu starten und zu stoppen.startStopTimeout : Die Zeitüberschreitung (in MS), in der festgestellt werden kann, ob der Container erfolgreich gestartet oder gestoppt wird (Standardeinstellungen bis 120000 ms).extraClasspath : Eine FileCollection , die dem lokalen Container -Klassenpfad zusätzliche Elemente liefert (optional).sharedClasspath : Eine FileCollection , die dem Anwendungsklassenpfad zusätzliche Elemente und nicht für den lokalen Container (optional) zur Verfügung stellt. Innerhalb local und remote können Sie containerspezifische Eigenschaften definieren. Diese Immobilien können auf der Fracht -Homepage nachgeschlagen werden. Das folgende Beispiel zeigt, wie der AJP -Anschluss für einen lokalen Tomcat -Container festgelegt wird:
cargo {
local {
containerProperties {
property 'cargo.tomcat.ajp.port', 9099
}
}
}
Lokale Container können Systemeigenschaften verwenden. Das folgende Beispiel zeigt, wie eine einzelne Systemeigenschaft namens myproperty festgelegt wird:
cargo {
local {
systemProperties {
property 'myproperty', 'myvalue'
}
}
}
Wenn Sie sich für die Verwendung der ZIP -Installateur -Fracht entscheiden, laden Sie Ihren Container automatisch herunter. Sie können seine Eigenschaften im Verschluss installer definieren. Der Installateur gilt nur für "lokale" Frachtaufgaben.
installUrl : Die URL zum Herunterladen der Containerverteilung von.downloadDir : Zielverzeichnis zum Herunterladen der Containerverteilung auf.extractDir : Verzeichnis zum Extrahieren der heruntergeladenen Containerverteilung zu.In den individuellen Konfigurationseigenschaften auf der Fracht -Homepage finden Sie bitte. Alle diese Eigenschaften können durch Projekteigenschaften überschrieben werden. Der Name der Projekteigenschaften ist der gleiche wie im Frachthandbuch.
Wenn Sie beim Auflösen von Containerverteilungen vom Gradle -Abhängigkeits -Cache profitieren möchten, können Sie bei der Konfiguration des Installationsprogramms eine Konfiguration anstelle einer URL verwenden:
configurations {
tomcat
}
dependencies {
tomcat "org.apache.tomcat:tomcat:9.0.14@zip"
}
cargo {
local {
installer {
installConfiguration = configurations.tomcat
}
}
}
cargo {
containerId = 'tomcat6x'
port = 9090
deployable {
context = 'myawesomewebapp'
}
remote {
hostname = 'cloud.internal.it'
username = 'superuser'
password = 'secretpwd'
}
local {
homeDir = file('/home/user/dev/tools/apache-tomcat-6.0.32')
outputFile = file('build/output.log')
startStopTimeout = 60000
containerProperties {
property 'cargo.tomcat.ajp.port', 9099
}
}
}
Ich möchte das Artefakt meines Projekts automatisch zusammenstellen, wenn ich eine Frachtbereitungsaufgabe ausführte.
Die Aufgabe, cargoRunLocal nicht automatisch von der assemble -Aufgabe abhängt. Der Grund dafür ist, dass Sie möglicherweise nicht das Artefakt Ihres Projekts bereitstellen möchten oder Ihr Projekt keine Kriegs- oder Ohrdatei generiert. Stattdessen möchten Sie möglicherweise einen oder mehrere externe Artefakte bereitstellen. Wenn Ihr Workflow wie "den Code kompilieren" aussieht, "generieren Sie das Artefakt" und "Bereitstellung", hängt eine Frachtbereitungsaufgabe von der assemble -Aufgabe ab. Hier ist ein Beispiel:
cargoRunLocal.dependsOn assemble
Ich arbeite an einem Multi-Project-Build. Kann ich die gleiche Frachtkonfiguration auf alle meine Webprojekte anwenden?
Gradle ermöglicht die Filterung von Unterprojekten nach bestimmten Kriterien. Um die relevante Konfiguration aus dem Stammprojekt Ihres Builds zu injizieren, müssen Sie alle Unterprojekte identifizieren, die das Kriegs -Plugin anwenden (natürlich das gleiche Konzept funktioniert für Ohrprojekte). Verwenden Sie die configure , um das Cargo -Plugin und Ihre Konfiguration anzuwenden, wie im folgenden Code -Snippet gezeigt:
def webProjects() {
subprojects.findAll { subproject -> subproject.plugins.hasPlugin('war') }
}
gradle.projectsEvaluated {
configure(webProjects()) {
apply plugin: 'com.bmuschko.cargo'
cargo {
containerId = 'tomcat7x'
remote {
hostname = 'localhost'
username = 'manager'
password = 'manager'
}
}
}
}
Ich möchte mehrere Artefakte in meinem Behälter bereitstellen. Wie mache ich das?
Sie würden jedes Artefakt in einem separaten deployable angeben. Jeder der Schließungen sollte einen eindeutigen URL -Kontext zuweisen. Das folgende Beispiel zeigt, wie ein Fracht -Setup mit drei verschiedenen Artefakten, die in einem lokalen Tomcat eingesetzt werden, eingesetzt werden:
cargo {
containerId = 'tomcat6x'
port = 9090
deployable {
file = file('/home/foo/bar/web-services.war')
context = 'web-services'
}
deployable {
file = file('/home/foo/bar/web-app.war')
context = 'web-app'
}
deployable {
file = file('/home/foo/bar/enterprise-app.ear')
context = 'enterprise-app'
}
local {
homeDir = file('/home/user/dev/tools/apache-tomcat-6.0.32')
}
}
Gibt es eine Möglichkeit, Fracht den Container automatisch installieren zu lassen, den ich gerne verwenden möchte?
Mit Cargo können Sie einen Container definieren, der automatisch heruntergeladen und auf Ihrer lokalen Festplatte installiert wird. Alles, was Sie tun müssen, ist, den installer -Verschluss anzugeben. Der folgende Code -Snippet -Download, installiert und verwendet Tomcat 7:
cargo {
containerId = 'tomcat7x'
local {
installer {
installUrl = 'http://apache.osuosl.org/tomcat/tomcat-7/v7.0.27/bin/apache-tomcat-7.0.27.zip'
downloadDir = file("$buildDir/download")
extractDir = file("$buildDir/extract")
}
}
}
Ich möchte meinem lokalen Container eine Konfigurationsdatei hinzufügen. Wie mache ich das?
Für lokale Container kann ein Verschluss mit dem Namen configFile verwendet werden, der die Quelldateien und das Verzeichnis definiert, von dem Sie die Datei zur Laufzeit verwenden möchten. Wenn Sie Dateien in mehr als ein Ziel kopieren müssen, erstellen Sie einfach mehrere configFile -Verschlüsse.
cargo {
containerId = 'jboss5x'
local {
configFile {
files = project.files('src/main/jboss5/login-config.xml')
toDir = 'conf'
}
configFile {
files = project.files('src/main/jboss5/login-config.xml', 'src/main/jboss5/sample-users.properties')
toDir = 'conf/props'
}
}
}
Um Binärdateien hinzuzufügen, sollten Sie stattdessen file verwenden:
cargo {
containerId = 'glassfish3x'
local {
file {
file = file('../config/db/mysql-connector-java-5.1.23-bin.jar')
toDir = 'lib'
}
}
}
Ich möchte meine eigene Frachtaufgabe für mehr als einen Container einrichten und konfigurieren. Kann das getan werden?
Absolut. Das Frachtbasis -Plugin bietet alle Aufgaben, die zum Einrichten von Bereitstellungsaufgaben erforderlich sind. Sie müssen lediglich eine oder mehrere Aufgaben erstellen und die obligatorischen Eigenschaften konfigurieren. Das folgende Beispiel zeigt, wie lokale Containeraufgaben für Tomcat und Jetty eingerichtet werden:
apply plugin: 'com.bmuschko.cargo-base'
task myTomcatRun(type: com.bmuschko.gradle.cargo.tasks.local.CargoRunLocal) {
containerId = 'tomcat7x'
homeDir = file('/home/user/dev/tools/apache-tomcat-7.0.42')
}
task myJettyRun(type: com.bmuschko.gradle.cargo.tasks.local.CargoRunLocal) {
containerId = 'jetty9x'
homeDir = file('/home/user/dev/tools/jetty-distribution-9.0.4.v20130625')
}
Ich möchte Bereitstellungsaufgaben für eine rollende Bereitstellung für mehrere Remote -Container erstellen. Wie mache ich das?
Gradle ermöglicht es dynamisch, Aufgaben basierend auf Ihrer Build -Skriptlogik zu erstellen. Das folgende Beispiel zeigt, wie drei Tomcat -Bereitstellungsaufgaben erstellt werden und wie Sie sie mit Hilfe einer einfachen Datenstruktur konfigurieren. Am Ende des Skripts fügen wir auch eine weitere Aufgabe hinzu, die alle Remote -Container den Einsatz auslöst.
class RemoteContainer {
String name
String hostname
Integer port
String username
String password
}
def remoteContainers = [new RemoteContainer(name: 'tomcat1', hostname: 'remote-tomcat1',
port: 9090, username: 'admin', password: 's3cr3t'),
new RemoteContainer(name: 'tomcat2', hostname: 'remote-tomcat2',
port: 8050, username: 'deployer', password: 'qwerty'),
new RemoteContainer(name: 'tomcat3', hostname: 'remote-tomcat3',
port: 8888, username: 'su', password: 'powerful')]
apply plugin: 'com.bmuschko.cargo-base'
remoteContainers.each { config ->
task "deployRemote${config.name.capitalize()}"(type: com.bmuschko.gradle.cargo.tasks.remote.CargoDeployRemote) {
description = "Deploys WAR to remote Tomcat '${config.name}'."
containerId = 'tomcat7x'
hostname = config.hostname
port = config.port
username = config.username
password = config.password
}
}
task deployToAllRemoteTomcats {
dependsOn remoteContainers.collect { "deployRemote${it.name.capitalize()}" }
description = 'Deploys to all remote Tomcat containers.'
group = 'deployment'
}
Vor einer Remote -Bereitstellung möchte ich meinen Container neu starten. Kann das getan werden?
Ja, dies ist mit Hilfe der Fracht -Daemon -Funktionalität möglich. Weitere Informationen finden Sie in der Fracht -Online -Dokumentation zum Einrichten des Fracht -Dämon -JVM -Vorgangs und der Konfiguration eines Containers. Mit diesem Plugin können Sie benutzerdefinierte Aufgaben verwenden, um einen Container zu starten und zu stoppen. Das folgende Beispiel stoppt, beginnt und dann ein Artefakt neu anwendet.
apply plugin: 'com.bmuschko.cargo'
cargo {
...
}
ext.tomcat7HandleId = 'tomcat7'
task cargoDaemonStop(type: com.bmuschko.gradle.cargo.tasks.daemon.CargoDaemonStop) {
handleId = tomcat7HandleId
}
task cargoDaemonStart(type: com.bmuschko.gradle.cargo.tasks.daemon.CargoDaemonStart) {
handleId = tomcat7HandleId
}
cargoDaemonStart.mustRunAfter cargoDaemonStop
cargoRedeployRemote.dependsOn cargoDaemonStop, cargoDaemonStart
