| За последние пару лет этот плагин видел много выпусков. Спасибо всем участникам! К сожалению, у меня больше не так много времени для внесения вклад. На практике это означает гораздо меньшую активность, отзывчивость к вопросам и новые выпуски с моей стороны. |
| Я активно ищу участников, желающих принять участие в техническом обслуживании и внедрении проекта. Если вы заинтересованы и хотели бы, чтобы этот плагин продолжал процветать, выстрелите мне по почте. |
Плагин предоставляет возможности развертывания для веб -приложений для локальных и удаленных контейнеров в любой заданной сборке Gradle, используя задачи Cargo Ant. Плагин поддерживает артефакты войны и ушей.
Типичным вариантом использования этого плагина является поддержка развертывания во время разработки. Имейте в виду, что Cargo использует горячее развертывание, которое со временем заполняет память PertGen процесса JVM, управляющий вашим контейнером. Непрерывное развертывание артефакта неизбежно приведет к java.lang.OutOfMemoryError . Cargo поддерживает возможности управления контейнерами (запуск/остановка удаленных контейнеров) через так называемый грузовой демон. Тем не менее, в сценариях непрерывного развертывания вы часто хотите выполнять более сложные операции.
Чтобы использовать функциональность плагина, вам нужно будет добавить его двоичный артефакт к обмену класса сценария вашего сценария и применить плагин.
Плагин JAR должен быть определен в классе вашего сценария сборки. Он доступен на портале плагина Gradle. В следующем фрагменте кода показан пример того, как получить его с помощью синтаксиса buildscript :
buildscript {
repositories {
gradlePluginPortal()
}
dependencies {
classpath 'com.bmuschko:gradle-cargo-plugin:2.9.0'
}
}
Файл JAR поставляется с двумя плагинами:
| Идентификатор плагина | Зависит от | Тип | Описание |
|---|---|---|---|
| com.bmuschko.cargo-base | - | Cargobaseplugin | Предоставляет Cargo пользовательские типы задач, предварительные конфигурации ClassPath и Deployables. |
| com.bmuschko.cargo | com.bmuschko.cargo-base | Каргоплагин | Предоставляет набор локальных и удаленных грузовых задач и выявляет расширение для конфигурации. |
Плагин com.bmuschko.cargo помогает быстро начать работу. Если вам нужно иметь дело только с одним контейнерным продуктом, это предпочтительный вариант. Большинство пользователей плагинов пойдут с этой опцией. Чтобы использовать плагин груза, включите следующий фрагмент кода в свой сценарий сборки:
apply plugin: 'com.bmuschko.cargo'
Если вам нужен полный контроль над задачами развертывания, вам нужно использовать плагин com.bmuschko.cargo-base . Недостатком является то, что каждая задача должна быть настроена индивидуально в вашем сценарии сборки. Чтобы использовать плагин с грузовым базовым, включите следующий фрагмент кода в свой сценарий сборки:
apply plugin: 'com.bmuschko.cargo-base'
Плагин com.bmuschko.cargo-base уже устанавливает зависимости для груза. Для этого он выбирает версию библиотек по умолчанию. В качестве альтернативы, вы можете определить пользовательскую версию библиотек груза. Для этого, пожалуйста, используйте имя конфигурации cargo в закрытии dependencies и помните ниже:
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"
}
Плагин cargo предварительно определяет следующие задачи вне коробки:
| Имя задачи | Зависит от | Тип | Описание |
|---|---|---|---|
| Cargodeployremote | - | Cargodeployremote | Развертывает развертываемый для удаленного контейнера. |
| Cargoundeployremote | - | Cargoundeployremote | Недоставление развертываемого из удаленного контейнера. |
| Cargoredeployremote | - | Cargoredeployremote | Перераспределяет развертываемый в удаленном контейнере. |
| Cargorunlocal | - | Cargorunlocal | Запускает локальный контейнер, развертывает развертываемую и ждет, пока пользователь нажимает CTRL + C, чтобы остановиться. |
| Cargostartlocal | - | Cargostartlocal | Запускает локальный контейнер, развертывает развертываемые, а затем выполняет другие задачи (например, выполнить тесты). |
| CargoredEploylocal | - | CargoredEploylocal | Перераспределяет развертываемую на локальном контейнере. |
| каргостоплакальный | - | Каргостоплакальный | Останавливает местный контейнер. |
| Cargoconfigurelocal | - | Cargoconfigurelocal | Настраивает локальный контейнер. |
Плагин груза использует тот же макет, что и военный плагин.
Плагин груза определяет следующие свойства соглашения в закрытии cargo :
containerId : идентификатор контейнера, на который вы нацелены. Пожалуйста, смотрите список поддерживаемых контейнеров на веб -сайте груза.port : порт TCP. Контейнер реагирует (по умолчанию на 8080). В рамках cargo вы можете определить дополнительные свойства для артефактов развертывания 1..n в закрытии под названием deployable . Каждый артефакт развертывания будет указан в его собственном закрытии:
file : Любой тип, который можно передать в Project.files (Object ...) и решается в один файл или каталог, включая произвольные артефакты, взорванные каталоги военных действий и конфигурации зависимости, которые будут развернуты в контейнере (по умолчанию в артефакт проекта/модуля - военный или ушной файл).context : контекст URL. Контейнер обрабатывает ваше веб -приложение (по умолчанию к имени войны/уха). Имейте в виду, что вам не нужно определять deployable закрытие, если вы просто хотите развернуть артефакт, определенный вашим проектом/модулем Gradle.
Внутри cargo вы можете определить свойства для удаленных контейнеров в закрытии с именем remote :
protocol : протокол удаленного контейнера (по умолчанию в http ).hostname : имя хоста удаленного контейнера.username : учетные данные имени пользователя для удаленного контейнера (необязательно).password : учетные данные пароля для удаленного контейнера (необязательно). Внутри cargo вы можете определить свойства для местных контейнеров в закрытии с именем local :
jvmArgs : аргументы JVM для локального контейнера.outputFile : файл журнала вашего локального контейнера (по умолчанию для записи в консоли).logFile : файл журнала Cargo вашего локального контейнера (по умолчанию записать в консоли).logLevel : уровень журнала для запуска контейнера с (необязательно). Допустимые уровни low , medium и high .homeDir : домашний каталог вашей местной установки контейнера.configHomeDir : домашний каталог конфигурации вашего локального контейнера.configFile : файлы конфигурации, которые вы хотите добавить в конфигурацию вашего контейнера. configFile является самим закрытием и требует предоставления files атрибутов и toDir . FileCollection должна использоваться в качестве атрибута files , а toDir должен быть String . Несколько направлений файлов конфигурации могут быть определены путем создания более одного закрытия configFile .rmiPort : порт для использования при общении с этим сервером, например, для запуска и остановки его.startStopTimeout : тайм -аут (в MS), в котором можно определить, успешно ли контейнер запускается или останавливается (по умолчанию до 120000 мс).extraClasspath : FileCollection , которая предоставляет дополнительные элементы локальному контейнеру ClassPath (необязательно).sharedClasspath : FileCollection , которая предоставляет дополнительные элементы для приложения ClassPath, а не для локального контейнера (необязательно). Внутри local и remote вы можете определить контейнерные свойства. Эти свойства можно посмотреть на домашней странице груза. В следующем примере показано, как установить порт AJP для локального контейнера Tomcat:
cargo {
local {
containerProperties {
property 'cargo.tomcat.ajp.port', 9099
}
}
}
Локальные контейнеры могут использовать системные свойства, передаваемые ему. В следующем примере показано, как установить одно свойство системы с именем myproperty :
cargo {
local {
systemProperties {
property 'myproperty', 'myvalue'
}
}
}
Если вы решите использовать груз установщика ZIP автоматически загрузит ваш контейнер. Вы можете определить его свойства в installer закрытия. Установщик распространяется только на «локальные» грузовые задачи.
installUrl : URL -адрес загрузить распределение контейнеров.downloadDir : Target Directory для загрузки дистрибуции контейнеров.extractDir : каталог для извлечения загруженного распределения контейнеров.Пожалуйста, обратитесь к индивидуальным свойствам конфигурации на домашней странице груза. Все эти свойства могут быть отменены свойствами проекта. Название свойств проекта такое же, как в руководстве по грузу.
Если вы хотите извлечь выгоду из кэша зависимостей Gradle при разрешении распределений контейнеров, вы можете использовать конфигурацию вместо URL -адреса при настройке установщика:
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
}
}
}
Я хочу автоматически собрать артефакт моего проекта при выполнении задачи по развертыванию груза.
Задача cargoRunLocal не зависит от задачи assemble . Причина этого заключается в том, что вы, возможно, не захотите развернуть артефакт вашего проекта, или ваш проект не генерирует войну или файл уха. Вместо этого вы можете развернуть один или несколько внешних артефактов. Если ваш рабочий процесс выглядит как «Скомпилируйте код», «генерируйте артефакт» и «развертывание», тогда вы делаете задачу развертывания груза, зависит от задачи assemble . Вот один пример:
cargoRunLocal.dependsOn assemble
Я работаю над многопроектной сборкой. Могу ли я применить ту же конфигурацию груза на все мои веб -проекты?
Gradle допускает фильтрацию субпроектов по определенным критериям. Чтобы ввести соответствующую конфигурацию из корневого проекта вашей сборки, вам необходимо будет идентифицировать все субпроекты, которые применяют плагин войны (конечно, та же концепция работает для ушных проектов). Используйте метод configure , чтобы применить плагин Cargo и вашу конфигурацию, как показано в следующем фрагменте кода:
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'
}
}
}
}
Я хотел бы развернуть несколько артефактов в мой контейнер. Как мне это сделать?
Вы бы указали каждый артефакт в отдельном deployable закрытии. Каждое из закрытия должно назначить уникальный контекст URL. В следующем примере демонстрируется, как настройка груза с тремя различными артефактами, развернутыми в местном Tomcat:
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')
}
}
Есть ли способ позволить Cargo автоматически установить контейнер, который я хотел бы использовать?
Cargo позволяет определить контейнер, который автоматически загружается и устанавливается на ваш локальный диск. Все, что вам нужно сделать, это указать закрытие installer . Следующий фрагмент кода загружает, устанавливает и использует 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")
}
}
}
Я хотел бы добавить файл конфигурации в мой локальный контейнер. Как мне это сделать?
Для локальных контейнеров можно использовать закрытие с именем configFile , которое определяет исходные файлы и каталог, который вы хотели бы использовать файл из Runtime. Если вам нужно скопировать файлы в несколько направлений, просто создайте несколько закрытий 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'
}
}
}
Чтобы добавить двоичный файл (ы), вы должны использовать закрытие file (ы) вместо этого:
cargo {
containerId = 'glassfish3x'
local {
file {
file = file('../config/db/mysql-connector-java-5.1.23-bin.jar')
toDir = 'lib'
}
}
}
Я хочу настроить и настроить свою собственную задачу для груза для более чем одного контейнера. Можно ли это сделать?
Абсолютно. Плагин Bargo Base предоставляет все задачи, необходимые для установки задач развертывания. Все, что вам нужно сделать, это создать одну или несколько задач и настроить обязательные свойства. В следующем примере показано, как настроить локальные задачи контейнера для Tomcat и причала:
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')
}
Я хотел бы создать задачи развертывания для развертывания в нескольких удаленных контейнерах. Как мне это сделать?
Gradle позволяет динамически создавать задачи на основе вашей логики сценария сборки. В следующем примере показано, как создать три задачи развертывания Tomcat и как настроить их с помощью простой структуры данных. В конце сценария мы также добавляем еще одну задачу, которая запускает развертывание на все удаленные контейнеры.
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'
}
Перед удаленным развертыванием я хотел бы перезагрузить контейнер. Можно ли это сделать?
Да, это возможно с помощью функциональности грузового демона. Пожалуйста, обратитесь к онлайн -документации Cargo для настройки процесса JVM Cargo Daemon и настройки контейнера. С помощью этого плагина вы можете использовать пользовательские задачи для запуска и остановки контейнера. Следующий пример останавливается, начинается, а затем перераспределяет артефакт.
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