gradle cargo plugin
1.0.0
| Nos últimos dois anos, este plugin já viu muitos lançamentos. Obrigado a todos os envolvidos! Infelizmente, não tenho muito tempo para contribuir mais. Na prática, isso significa muito menos atividade, capacidade de resposta a questões e novos lançamentos do meu fim. |
| Estou procurando ativamente os colaboradores dispostos a assumir a manutenção e a implementação do projeto. Se você estiver interessado e adoraria ver esse plugin continuar prosperando, faça -me um e -mail. |
O plug -in fornece recursos de implantação para aplicativos da Web para contêineres locais e remotos em qualquer formação gradle, aproveitando as tarefas de ANT de carga. O plug -in suporta artefatos de guerra e ouvido.
O caso de uso típico deste plug -in é apoiar a implantação durante o desenvolvimento. Lembre -se de que a carga usa implantação quente que com o tempo preenche a memória permgen do processo JVM executando seu contêiner. A implantação continuamente um artefato inevitável levará a um java.lang.OutOfMemoryError . A carga suporta recursos de gerenciamento de contêineres (iniciando/parado de contêineres remotos) através do chamado daemon de carga. No entanto, em cenários de implantação contínua, você geralmente precisa executar operações mais complexas.
Para usar a funcionalidade do plug -in, você precisará adicionar o artefato binário ao seu script de construção e aplicar o plug -in.
O frasco do plug -in precisa ser definido no caminho de classe do seu script de construção. Está disponível no portal do plug -in gradle. O snippet de código a seguir mostra um exemplo sobre como recuperá -lo com a sintaxe buildscript :
buildscript {
repositories {
gradlePluginPortal()
}
dependencies {
classpath 'com.bmuschko:gradle-cargo-plugin:2.9.0'
}
}
O arquivo JAR vem com dois plugins:
| Identificador de plug -in | Depende de | Tipo | Descrição |
|---|---|---|---|
| com.bmuschko.cargo-base | - | Cargobaseplugin | Fornece tipos de tarefas personalizados de carga, pré-configurações de classe e implantáveis. |
| com.bmuschko.cargo | com.bmuschko.cargo-base | Cargoplugin | Fornece um conjunto de tarefas de carga local e remoto e expõe a extensão da configuração. |
O plugin com.bmuschko.cargo ajuda a começar rapidamente. Se você precisar lidar apenas com um único produto de contêiner, esta é a opção preferida. A maioria dos usuários de plug -in optará com esta opção. Para usar o plug -in de carga, inclua o seguinte snippet de código em seu script de construção:
apply plugin: 'com.bmuschko.cargo'
Se você precisar de controle total sobre suas tarefas de implantação, desejará usar o plugin com.bmuschko.cargo-base . A desvantagem é que cada tarefa deve ser configurada individualmente em seu script de construção. Para usar o plug -in de base de carga, inclua o seguinte snippet de código em seu script de construção:
apply plugin: 'com.bmuschko.cargo-base'
O plug-in com.bmuschko.cargo-base já configura as dependências para a carga. Para fazer isso, ele escolhe uma versão padrão das bibliotecas. Como alternativa, você pode definir uma versão personalizada das bibliotecas de carga. Para fazer isso, use o nome da configuração cargo no fechamento de suas dependencies e lembre -se de que: lembre -se:
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"
}
O plug-in cargo prejudica as seguintes tarefas prontas para uso:
| Nome da tarefa | Depende de | Tipo | Descrição |
|---|---|---|---|
| CargodeployRemote | - | CargodeployRemote | Implanta um contêiner remoto implantável. |
| CargoundEployRemote | - | CargoundEployRemote | UNDEPLAPE UM PROBLEMA DO CONTESTO DE REMOTO. |
| CargoredeployRemote | - | CargoredeployRemote | Reimplenta um contêiner remoto implantável. |
| Cargorunlocal | - | Cargorunlocal | Inicia o contêiner local, implanta um implantável e aguarda o usuário pressionar Ctrl + C para parar. |
| CargostartLocal | - | CargostartLocal | Inicia o contêiner local, implanta um implantável e, em seguida, realize outras tarefas (por exemplo, execute testes). |
| Cargoredeploylocal | - | Cargoredeploylocal | Reimplanta um implantável no contêiner local. |
| Cargostoplocal | - | Cargostoplocal | Pare o contêiner local. |
| Cargoconfigurelocal | - | Cargoconfigurelocal | Configura o contêiner local. |
O plug -in de carga usa o mesmo layout que o plug -in de guerra.
O plug -in de carga define as seguintes propriedades da convenção no fechamento cargo :
containerId : o ID do contêiner que você está segmentando. Consulte a lista de contêineres suportados no site da carga.port : a porta TCP em que o contêiner responde (padrão para 8080). Na cargo você pode definir propriedades opcionais para os artefatos de implantação 1..n em um fechamento chamado deployable . Cada artefato de implantação seria especificado em seu próprio fechamento:
file : Qualquer tipo que possa ser passado para o Project.Files (objeto ...) e resolva um único arquivo ou um diretório, incluindo artefatos arbitrários, diretórios de guerra explodidos e configurações de dependência a serem implantadas no contêiner (padrão para projetar/module artefato - alerta ou arquivo de ouvido).context : o contexto da URL O contêiner está lidando com seu aplicativo da web (Padrões para o nome da guerra/ouvido). Lembre -se de que você não precisa definir o fechamento deployable se deseja implantar o artefato definido pelo seu projeto/módulo gradle.
Na cargo você pode definir propriedades para contêineres remotos em um fechamento chamado remote :
protocol : o protocolo do contêiner remoto (padrão para http ).hostname : o nome do host do contêiner remoto.username : a credencial do nome de usuário para o contêiner remoto (opcional).password : a credencial de senha para o contêiner remoto (opcional). Na cargo você pode definir propriedades para contêineres locais em um fechamento chamado local :
jvmArgs : Os argumentos da JVM para um contêiner local.outputFile : O arquivo de log do seu contêiner local (padrão para gravar no console).logFile : o arquivo de log de carga do seu contêiner local (padrão para gravar no console).logLevel : o nível de log para executar o contêiner (opcional). Os níveis válidos são low , medium e high .homeDir : o diretório inicial da instalação local do contêiner.configHomeDir : o diretório inicial da configuração do seu contêiner local.configFile : os arquivos de configuração que você deseja adicionar à configuração do seu contêiner. O configFile é um fechamento em si e exige que você forneça os files de atributos e toDir . Um FileCollection deve ser usado como atributo files e toDir deve ser uma String . Vários destinos de arquivo de configuração podem ser definidos pela criação de mais de um fechamento configFile .rmiPort : A porta a ser usada ao se comunicar com este servidor, por exemplo, para iniciar e interromper.startStopTimeout : o tempo limite (em MS) para determinar se o contêiner é iniciado ou interrompido com sucesso (padrão para 120000ms).extraClasspath : uma FileCollection que fornece elementos extras para o contêiner local ClassPath (opcional).sharedClasspath : uma FileCollection que fornece elementos extras ao Application ClassPath, e não ao contêiner local (opcional). Dentro local e remote você pode definir propriedades específicas do contêiner. Essas propriedades podem ser analisadas na página inicial da carga. O exemplo a seguir mostra como definir a porta AJP para um contêiner local do tomcat:
cargo {
local {
containerProperties {
property 'cargo.tomcat.ajp.port', 9099
}
}
}
Os contêineres locais podem usar as propriedades do sistema transmitidas a ele. O exemplo a seguir mostra como definir uma única propriedade do sistema chamada myproperty :
cargo {
local {
systemProperties {
property 'myproperty', 'myvalue'
}
}
}
Se você decidir usar a carga do instalador ZIP, baixará automaticamente seu contêiner. Você pode definir suas propriedades no installer de fechamento. O instalador se aplica apenas a tarefas de carga "locais".
installUrl : o URL para baixar a distribuição de contêineres.downloadDir : diretório de destino para baixar a distribuição de contêineres para.extractDir : diretório para extrair a distribuição de contêineres baixados para.Consulte as propriedades de configuração individuais na página inicial da carga. Todas essas propriedades podem ser substituídas pelas propriedades do projeto. O nome das propriedades do projeto é o mesmo que no manual de carga.
Se você deseja se beneficiar do cache de dependência da gradle ao resolver distribuições de contêineres, você pode usar uma configuração em vez de um URL ao configurar o instalador:
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
}
}
}
Quero montar automaticamente o artefato do meu projeto ao executar uma tarefa de implantação de carga.
A tarefa cargoRunLocal não depende automaticamente da tarefa assemble . A razão por trás disso é que você pode não querer implantar o artefato do seu projeto ou seu projeto não gera um arquivo de guerra ou ouvido. Em vez disso, você pode querer implantar um ou mais artefatos externos. Se o seu fluxo de trabalho parecer "compilar o código", "gerar o artefato" e "implantar", você faz uma tarefa de implantação de carga depende da tarefa assemble . Aqui está um exemplo:
cargoRunLocal.dependsOn assemble
Estou trabalhando em uma compilação com vários projetos. Posso aplicar a mesma configuração de carga a todos os meus projetos da web?
A gradle permite filtrar subprojetos por certos critérios. Para injetar a configuração relevante do projeto raiz da sua compilação, você precisará identificar todos os subprojetos que aplicam o plug -in de guerra (é claro que o mesmo conceito funciona para projetos de ouvido). Use o método configure para aplicar o plug -in de carga e sua configuração, conforme mostrado no seguinte snippet de código:
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'
}
}
}
}
Eu gostaria de implantar vários artefatos no meu contêiner. Como faço isso?
Você especificaria cada artefato em um fechamento deployable separado. Cada um dos fechamentos deve atribuir um contexto de URL exclusivo. O exemplo a seguir demonstra como uma configuração de carga com três artefatos diferentes implantados em um 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 uma maneira de deixar a carga instalar automaticamente o contêiner que eu gostaria de usar?
A carga permite definir um contêiner que seja baixado e instalado automaticamente no disco local. Tudo o que você precisa fazer é especificar o fechamento installer . Os seguintes downloads de snippet de código, instalam e usa o 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")
}
}
}
Eu gostaria de adicionar um arquivo de configuração ao meu contêiner local. Como faço isso?
Para contêineres locais, pode ser usado um fechamento nomeado configFile , que define os arquivos de origem e o diretório da qual você deseja usar o arquivo no tempo de execução. Se você precisar copiar arquivos em mais de um destinos, basta criar vários fechamentos 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'
}
}
}
Para adicionar arquivos binários, você deve usar o (s) fechamento (s) file :
cargo {
containerId = 'glassfish3x'
local {
file {
file = file('../config/db/mysql-connector-java-5.1.23-bin.jar')
toDir = 'lib'
}
}
}
Quero configurar e configurar minha própria tarefa de carga para mais de um contêiner. Isso pode ser feito?
Absolutamente. O plug -in de base de carga fornece todas as tarefas necessárias para configurar tarefas de implantação. Tudo o que você precisa fazer é criar uma ou mais tarefas e configurar as propriedades obrigatórias. O exemplo a seguir mostra como configurar tarefas locais de contêineres para Tomcat e Jetty:
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')
}
Eu gostaria de criar tarefas de implantação para uma implantação rolante em vários contêineres remotos. Como faço isso?
A gradle permite a criação dinamicamente de tarefas com base na sua lógica de script de construção. O exemplo a seguir mostra como criar três tarefas de implantação do Tomcat e como configurá -las com a ajuda de uma estrutura de dados simples. No final do script, também adicionamos outra tarefa que aciona a implantação a todos os contêineres remotos.
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'
}
Antes de uma implantação remota, gostaria de reiniciar meu contêiner. Isso pode ser feito?
Sim, isso é possível com a ajuda da funcionalidade de daemon de carga. Consulte a documentação on -line de carga para configurar o processo JVM da DAEMON de carga e configurar um contêiner. Com este plug -in, você pode usar tarefas personalizadas para iniciar e interromper um contêiner. O exemplo a seguir para, inicia e depois reimplande um artefato.
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
