gradle cargo plugin
1.0.0
| Au cours des deux dernières années, ce plugin a vu de nombreuses versions. Merci à toutes les personnes impliquées! Malheureusement, je n'ai plus beaucoup de temps pour contribuer. En pratique, cela signifie beaucoup moins d'activité, de réactivité sur les problèmes et de nouvelles versions de ma fin. |
| Je recherche activement des contributeurs disposés à assumer la maintenance et la mise en œuvre du projet. Si vous êtes intéressé et que vous aimeriez voir ce plugin continuer à prospérer, tirez-moi un courrier. |
Le plugin fournit des capacités de déploiement pour les applications Web aux conteneurs locaux et distants dans une création de gradle donnée en tirant parti des tâches de fourmis de cargaison. Le plugin prend en charge les artefacts de guerre et d'oreille.
Le cas d'utilisation typique de ce plugin est de prendre en charge le déploiement pendant le développement. Gardez à l'esprit que Cargo utilise un déploiement à chaud qui au fil du temps remplit la mémoire Permgen du processus JVM exécutant votre conteneur. Le déploiement continue d'un artefact mènera inévitablity à un java.lang.OutOfMemoryError . La cargaison prend en charge les capacités de gestion des conteneurs (démarrage / arrêt des conteneurs distants) via le démon soi-disant cargo. Cependant, dans les scénarios de déploiement continu, vous voulez souvent avoir besoin d'effectuer des opérations plus complexes.
Pour utiliser les fonctionnalités du plugin, vous devrez ajouter son artefact binaire au chemin de classe de votre script de build et appliquer le plugin.
Le pot de plugin doit être défini dans le chemin de classe de votre script de construction. Il est disponible sur le portail du plugin Gradle. L'extrait de code suivant montre un exemple sur la façon de le récupérer avec la syntaxe buildscript :
buildscript {
repositories {
gradlePluginPortal()
}
dependencies {
classpath 'com.bmuschko:gradle-cargo-plugin:2.9.0'
}
}
Le fichier JAR est livré avec deux plugins:
| Identifiant de plugin | Dépend de | Taper | Description |
|---|---|---|---|
| com.bmuschko.cargo-base | - | Cargobaseplugine | Fournit des types de tâches personnalisés de cargaison, pré-configures ClassPath et départements. |
| com.bmuschko.cargo | com.bmuschko.cargo-base | Cargoplugine | Fournit un ensemble de tâches de fret locales et distantes et expose l'extension pour la configuration. |
Le plugin com.bmuschko.cargo vous aide à démarrer rapidement. Si vous avez seulement besoin de traiter avec un seul produit de conteneur, il s'agit de l'option préférable. La plupart des utilisateurs de plugins iront avec cette option. Pour utiliser le plugin de cargaison, incluez l'extrait de code suivant dans votre script de construction:
apply plugin: 'com.bmuschko.cargo'
Si vous avez besoin d'un contrôle complet sur vos tâches de déploiement, vous voudrez utiliser le plugin com.bmuschko.cargo-base . L'inconvénient est que chaque tâche doit être configurée individuellement dans votre script de construction. Pour utiliser le plugin de base de cargaison, incluez l'extrait de code suivant dans votre script de construction:
apply plugin: 'com.bmuschko.cargo-base'
Le plugin com.bmuschko.cargo-base configure déjà les dépendances pour le fret. Pour ce faire, il choisit une version par défaut des bibliothèques. Alternativement, vous pouvez définir une version personnalisée des bibliothèques de cargaison. Pour ce faire, veuillez utiliser le nom de configuration cargo dans votre fermeture dependencies et gardez à l'esprit ce qui précède:
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"
}
Le plugin cargo pré-définit les tâches suivantes à l'extérieur de la boîte:
| Nom de tâche | Dépend de | Taper | Description |
|---|---|---|---|
| cargodeployremote | - | Cargodeployremote | Déploie un conteneur déployable à distance. |
| CargoundPloyRemote | - | CargoundPloyRemote | Undeploine un déploiement à partir du conteneur distant. |
| cargoreployremote | - | Cargoreployremote | Redéployer un conteneur déployable à distance. |
| cargorunlocal | - | Cargorunlocal | Démarre le conteneur local, déploie un déployable et attend que l'utilisateur appuye sur Ctrl + C pour s'arrêter. |
| cargostartlocal | - | Cargostartlocal | Démarre le conteneur local, déploie un déployable puis effectuer d'autres tâches (par exemple, exécuter des tests). |
| cargoreploylocal | - | Cargoreploylocal | Redéployer un déployable sur un conteneur local. |
| cargostoplocal | - | Cargostoplocal | Arrête le conteneur local. |
| cargoconfigurelocal | - | Cargoconfigurelocal | Configure le conteneur local. |
Le plugin de cargaison utilise la même disposition que le plugin de guerre.
Le plugin de cargaison définit les propriétés de convention suivantes dans la fermeture cargo :
containerId : l'ID de conteneur que vous ciblez. Veuillez consulter la liste des conteneurs pris en charge sur le site Web du fret.port : le port TCP sur lequel le conteneur répond (par défaut en 8080). Dans cargo vous pouvez définir des propriétés facultatives pour les artefacts de déploiement 1..N dans une fermeture nommée deployable . Chaque artefact de déploiement serait spécifié dans sa propre fermeture:
file : tout type qui peut être transmis à project.files (objet ...) et se résout en un seul fichier ou un répertoire comprenant des artefacts arbitraires, des répertoires de guerre explosés et des configurations de dépendance à déployer dans le conteneur (par défaut, Project / Module Artefact - War ou Ear File).context : Le contexte de l'URL dans lequel le conteneur gère votre application Web sur (par défaut est le nom de guerre / oreille). Gardez à l'esprit que vous n'avez pas à définir la fermeture deployable si vous souhaitez simplement déployer l'artefact défini par votre projet / module Gradle.
Dans cargo vous pouvez définir des propriétés pour les conteneurs distants dans une fermeture nommée remote :
protocol : le protocole du conteneur distant (par défaut est http ).hostname : le nom d'hôte du conteneur distant.username : l'identification du nom d'utilisateur pour le conteneur distant (facultatif).password : l'identification du mot de passe pour le conteneur distant (facultatif). Dans cargo vous pouvez définir les propriétés des conteneurs locaux dans une fermeture nommée local :
jvmArgs : Les arguments JVM pour un conteneur local.outputFile : le fichier journal de votre conteneur local (par défaut en écrivant à la console).logFile : le fichier journal de cargaison de votre conteneur local (par défaut, l'écriture dans la console).logLevel : le niveau de journal pour exécuter le conteneur avec (facultatif). Les niveaux valides sont low , medium et high .homeDir : Le répertoire domestique de votre installation de conteneurs locale.configHomeDir : Le répertoire domestique de la configuration de votre conteneur local.configFile : les fichiers de configuration que vous souhaitez ajouter à la configuration de votre conteneur. Le configFile est une fermeture elle-même et vous oblige à fournir les files d'attributs et toDir . Une FileCollection doit être utilisée comme attribut files et toDir doit être une String . Plusieurs destinations de fichiers de configuration peuvent être définies en créant plus d'une fermeture configFile .rmiPort : le port à utiliser lors de la communication avec ce serveur, par exemple pour démarrer et l'arrêter.startStopTimeout : le délai d'attente (dans MS) dans lequel déterminer si le conteneur est démarré avec succès ou arrêté (par défaut, 120000 ms).extraClasspath : une FileCollection qui fournit des éléments supplémentaires au cours de classe de conteneur local (facultatif).sharedClasspath : une FileCollection qui fournit des éléments supplémentaires au chemin de classe d'application, et non au conteneur local (facultatif). Dans le local et remote vous pouvez définir les propriétés spécifiques au conteneur. Ces propriétés peuvent être recherchées sur la page d'accueil du fret. L'exemple suivant montre comment définir le port AJP pour un conteneur Tomcat local:
cargo {
local {
containerProperties {
property 'cargo.tomcat.ajp.port', 9099
}
}
}
Les conteneurs locaux peuvent utiliser les propriétés du système qui lui sont transmises. L'exemple suivant montre comment définir une propriété système unique nommée myproperty :
cargo {
local {
systemProperties {
property 'myproperty', 'myvalue'
}
}
}
Si vous décidez d'utiliser la cargaison d'installation ZIP, téléchargera automatiquement votre conteneur. Vous pouvez définir ses propriétés dans le installer de fermeture. Le programme d'installation ne s'applique qu'aux tâches de fret "locales".
installUrl : L'URL pour télécharger la distribution des conteneurs à partir de.downloadDir : Target Directory pour télécharger la distribution des conteneurs vers.extractDir : Répertoire pour extraire la distribution de conteneurs téléchargée vers.Veuillez vous référer aux propriétés de configuration individuelles sur la page d'accueil du fret. Toutes ces propriétés peuvent être remplacées par les propriétés du projet. Le nom des propriétés du projet est le même que dans le manuel du fret.
Si vous souhaitez bénéficier du cache de dépendance Gradle lors de la résolution des distributions de conteneurs, vous pouvez utiliser une configuration au lieu d'une URL lors de la configuration du programme d'installation:
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
}
}
}
Je veux assembler automatiquement l'artefact de mon projet lors de l'exécution d'une tâche de déploiement de fret.
La tâche cargoRunLocal ne dépend pas automatiquement de la tâche assemble . La raison derrière cela est que vous ne voudrez peut-être pas déployer l'artefact de votre projet ou votre projet ne génère pas de fichier de guerre ou d'oreille. Au lieu de cela, vous voudrez peut-être déployer un ou plusieurs artefacts externes. Si votre workflow ressemble à "compiler le code", "générer l'artefact" et "déploier", vous faites une tâche de déploiement de fret dépend de la tâche assemble . Voici un exemple:
cargoRunLocal.dependsOn assemble
Je travaille sur une version multi-projets. Puis-je appliquer la même configuration de fret à tous mes projets Web?
Gradle permet de filtrer les sous-projets par certains critères. Pour injecter la configuration pertinente à partir du projet racine de votre build, vous devrez identifier tous les sous-projets qui appliquent le plugin de guerre (bien sûr, le même concept fonctionne pour les projets d'oreille). Utilisez la méthode configure pour appliquer le plugin de cargaison et votre configuration comme indiqué dans l'extrait de code suivant:
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'
}
}
}
}
Je voudrais déployer plusieurs artefacts dans mon conteneur. Comment faire ça?
Vous spécifiez chaque artefact dans une fermeture deployable distincte. Chacune des fermetures doit attribuer un contexte URL unique. L'exemple suivant montre comment une configuration de cargaison avec trois artefacts différents a été déployé dans un Tomcat local:
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')
}
}
Existe-t-il un moyen de laisser le fret installer automatiquement le conteneur que j'aimerais utiliser?
La cargaison permet de définir un conteneur qui est automatiquement téléchargé et installé sur votre disque local. Tout ce que vous avez à faire est de spécifier la fermeture installer . Les extraits de code suivants téléchargent, installent et utilisent 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")
}
}
}
Je voudrais ajouter un fichier de configuration à mon conteneur local. Comment faire ça?
Pour les conteneurs locaux, une fermeture nommée configFile peut être utilisée qui définit les fichiers source et le répertoire que vous souhaitez utiliser le fichier à partir de l'exécution. Si vous devez copier des fichiers dans plusieurs destinations, créez simplement plusieurs fermetures configFile .
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'
}
}
}
Pour ajouter des fichiers binaires, vous devez utiliser la (s) fermeture file :
cargo {
containerId = 'glassfish3x'
local {
file {
file = file('../config/db/mysql-connector-java-5.1.23-bin.jar')
toDir = 'lib'
}
}
}
Je souhaite configurer et configurer ma propre tâche de cargaison pour plus d'un conteneur. Cela peut-il être fait?
Absolument. Le plugin de base de cargaison fournit toutes les tâches nécessaires pour configurer les tâches de déploiement. Tout ce que vous avez à faire est de créer une ou plusieurs tâches et de configurer les propriétés obligatoires. L'exemple suivant montre comment configurer des tâches de conteneurs locaux pour Tomcat et Je jetée:
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')
}
Je voudrais créer des tâches de déploiement pour un déploiement roulant vers plusieurs conteneurs distants. Comment faire cela?
Gradle permet de créer dynamiquement des tâches en fonction de votre logique de script de construction. L'exemple suivant montre comment créer trois tâches de déploiement Tomcat et comment les configurer à l'aide d'une structure de données simple. À la fin du script, nous ajoutons également une autre tâche qui déclenche le déploiement à tous les conteneurs distants.
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'
}
Avant un déploiement à distance, je voudrais redémarrer mon conteneur. Cela peut-il être fait?
Oui, cela est possible à l'aide de la fonctionnalité des démon de cargaison. Veuillez vous référer à la documentation en ligne Cargo pour la mise en place du processus de damis de cargaison JVM et la configuration d'un conteneur. Avec ce plugin, vous pouvez utiliser des tâches personnalisées pour démarrer et arrêter un conteneur. L'exemple suivant s'arrête, démarre puis redéploite un artefact.
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
