简介
除了配置文件的批改之外,最重要的就是应用程序的部署了。本文将会解说如何在 wildfly 21 中,在 Managed Domain 和 standalone 两种模式中如何部署应用程序。
Managed Domain 中的部署
在 managed domain 模式下,服务是放在很多个 server 中启动的,而 server 是和 server-group 相关联的。同一个 server-group 下的 server 部署是统一的。
在 managed domain 模式下,须要先将要部署的应用程序上传到 domain controller 中,而后通过 domain controller 将其部署到一个或者多个 server-group 中。
当然咱们在 domain controller 中的 cli 环境中只须要一个 deploy 命令就能够做到下面的两步了。
比如说,咱们创立了一个应用程序叫做 test-application.war,看下怎么进行部署:
[domain@localhost:9990 /] deploy ~/Desktop/test-application.war
Either --all-server-groups or --server-groups must be specified.
[domain@localhost:9990 /] deploy ~/Desktop/test-application.war --all-server-groups
'test-application.war' deployed successfully.
在执行 deploy 命令的时候,须要指定部署到的 server-groups 名字,能够部署到所有的 server-groups 中,也能够指定特定的某些 server-groups:
[domain@localhost:9990 /] deploy ~/Desktop/test-application.war --server-groups=main-server-group,another-group
'test-application.war' deployed successfully.
部署实现之后,咱们能够通过 cli 来查看一下部署的状态:
[domain@localhost:9990 /] /server-group=main-server-group/deployment=test-application.war:read-resource(include-runtime)
{
"outcome" => "success",
"result" => {
"enabled" => true,
"name" => "test-application.war",
"managed" => true,
"runtime-name" => "test-application.war"
}
}
deploy 能够增加 –force 参数,用来降级或者替换现有的程序版本:
[domain@localhost:9990 /] deploy ~/Desktop/test-application.war --all-server-groups --force
'test-application.war' deployed successfully.
如果想勾销部署,则能够应用 undeploy:
[domain@localhost:9990 /] undeploy test-application.war --all-relevant-server-groups
Successfully undeployed test-application.war.
[domain@localhost:9990 /] /server-group=main-server-group:read-children-names(child-type=deployment)
{
"outcome" => "success",
"result" => []}
部署实现之后,会在 domain.xml 中增加或者批改两个局部的内容,别离是 deployments 和 server-groups:
[...]
<deployments>
<deployment name="test-application.war"
runtime-name="test-application.war">
<content sha1="dda9881fa7811b22f1424b4c5acccb13c71202bd"/>
</deployment>
</deployments>
[...]
<server-groups>
<server-group name="main-server-group" profile="default">
[...]
<deployments>
<deployment name="test-application.war" runtime-name="test-application.war"/>
</deployments>
</server-group>
</server-groups>
[...]
治理开展的部署文件
一般来说,如果咱们要创立或者批改一个应用程序的部署文件的话,咱们能够从新打包这个部署文件,而后重新部署即可。
然而有时候,从新打包整个应用程序可能比较复杂,而咱们只是想批改程序中的某一个或者某几个特定的文件。那么 wildfly 提供了命令行方便的实现这个性能。
要批改打包好的部署文件,首先就是要将部署文件开展。因为部署文件个别都是以 ear,war 结尾的,开展的目标就是将其进行解压缩,以便咱们能够批改包外面的内容。
比如说咱们当初曾经部署好了一个 kitchensink.ear 文件,当初能够应用上面的命令将其开展:
[domain@localhost:9990 /] /deployment=kitchensink.ear:explode()
因为下面的开展命令并不是递归执行的,如果 ear 中蕴含子的部署零碎 war 文件的话,咱们能够应用 path 来指定开展的子系统:
[domain@localhost:9990 /] /deployment=kitchensink.ear:explode(path=wildfly-kitchensink-ear-web.war)
开展部署文件之后,咱们能够应用 browse-content 来查看文件的列表:
[domain@localhost:9990 /] /deployment=kitchensink.ear:browse-content(archive=false, path=wildfly-kitchensink-ear-web.war)
{
"outcome" => "success",
"result" => [
{
"path" => "META-INF/",
"directory" => true
},
{
"path" => "META-INF/MANIFEST.MF",
"directory" => false,
"file-size" => 128L
},
...
}
如果想查看具体某个文件的形容,则能够应用 read-content:
[domain@localhost:9990 /] /deployment=kitchensink.ear:read-content(path=META-INF/MANIFEST.MF)
{
"outcome" => "success",
"result" => {"uuid" => "b373d587-72ee-4b1e-a02a-71fbb0c85d32"},
"response-headers" => {"attached-streams" => [{
"uuid" => "b373d587-72ee-4b1e-a02a-71fbb0c85d32",
"mime-type" => "text/plain"
}]}
}
留神,read-content 只能读取到文件的描述符,并不能获取到文件的内容,如果想要读取文件的内容,能够应用 attachment display:
[domain@localhost:9990 /] attachment display --operation=/deployment=kitchensink.ear:read-content(path=META-INF/MANIFEST.MF)
ATTACHMENT d052340a-abb7-4a66-aa24-4eeeb6b256be:
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Built-By: mjurc
Created-By: Apache Maven 3.3.9
Build-Jdk: 1.8.0_91
应用 attachment save 命令还能够将部署文件的内容拷贝到指定的文件目录中:
[domain@localhost:9990 /] attachment save --operation=/deployment=kitchensink.ear:read-content(path=META-INF/MANIFEST.MF) --file=/tmp/example
File saved to /tmp/example
咱们能够应用 add 操作来创立一个空的开展部署文件:
[domain@localhost:9990 /] /deployment=exploded.war:add(content=[{empty=true}])
而后应用 add-content 向其中增加文件:
[domain@localhost:9990 /] /deployment=exploded.war:add-content(content=[{target-path=WEB-INF/classes/org/jboss/as/test/deployment/trivial/ServiceActivatorDeployment.class, input-stream-index=/home/demo/org/jboss/as/test/deployment/trivial/ServiceActivatorDeployment.class}, {target-path=META-INF/MANIFEST.MF, input-stream-index=/home/demo/META-INF/MANIFEST.MF}, {target-path=META-INF/services/org.jboss.msc.service.ServiceActivator, input-stream-index=/home/demo/META-INF/services/org.jboss.msc.service.ServiceActivator}])
或者应用 remove-content 删除其中的文件:
[domain@localhost:9990 /] /deployment=exploded.war:remove-content(paths=[WEB-INF/classes/org/jboss/as/test/deployment/trivial/ServiceActivatorDeployment.class, META-INF/MANIFEST.MF, META-INF/services/org.jboss.msc.service.ServiceActivator])
十分的不便。
standalone 模式下的部署
standalone 模式下的部署和 domain 模式下的部署其实是差不多的,只不过 standalone 模式下没有 server group 的概念,咱们看下怎么部署和反部署:
[standalone@localhost:9990 /] deploy ~/Desktop/test-application.war
'test-application.war' deployed successfully.
[standalone@localhost:9990 /] undeploy test-application.war
Successfully undeployed test-application.war.
standalone 模式下的主动部署
手动部署比拟麻烦,须要手动输出命令能力实现部署,如果零碎中曾经存在了 deployment-scanner 这个 subsystem 的话,那么这个 scanner 会定时去扫描 standalone/deployments 中的文件,从而实现主动部署的工作。
留神,在生产环境下,并不激励应用 scanner 去实现部署工作。
咱们能够在 standalone.xml 中对 deployment-scanner 进行更加具体的配置:
<deployment-scanner scan-interval="5000" relative-to="jboss.server.base.dir"
path="deployments" auto-deploy-zipped="true" auto-deploy-exploded="false"/>
Marker Files
Marker Files 是和部署文件同名的文件,只不过在部署文件前面加上了一些后缀,比方:.dodeploy,.skipdeploy,.isdeploying,.deployed 等等。
其中比拟重要的是.dodeploy 和.deployed,咱们能够手动创立或者删除这些文件,来控制系统的部署工作。
比方,咱们的部署文件叫做 example.war,那么咱们能够通过:
cp target/example.war/ $JBOSS_HOME/standalone/deployments
touch $JBOSS_HOME/standalone/deployments/example.war.dodeploy
来手动部署 example.war 文件。
还能够通过删除.deployed 来反部署应用程序。
rm $JBOSS_HOME/standalone/deployments/example.war.deployed
如果 $JBOSS_HOME/standalone/deployments/example.war.undeployed 呈现了,就体现零碎反部署胜利了。
受治理的和不受治理的部署
wildfly 反对两种部署模式,受治理的和不受治理的部署。
所谓不受治理的部署就是说,用户自行提供要部署的文件门路,零碎间接去读取该门路上的文件。
而受治理的部署会把要部署的文件上传到外部的仓库中,而后应用这个仓库中的内容进行前面的部署操作。
仓库文件目录是 standalone/data/content 或者 domain/data/content,咱们看下仓库的文件格式:
ls domain/data/content/
|---/47
|-----95cc29338b5049e238941231b36b3946952991
|---/dd
|-----a9881fa7811b22f1424b4c5acccb13c71202bd
咱们看一个部署文件的形容:
<deployments>
<deployment name="test-application.war"
runtime-name="test-application.war">
<content sha1="dda9881fa7811b22f1424b4c5acccb13c71202bd"/>
</deployment>
</deployments>
能够看到下面列出了部署文件的名字和 sha1 编码。WildFly 次要通过这个 sha1 的编码去找到存储的文件。
默认状况下,咱们应用 deploy 命令部署的是受治理的利用,咱们能够通过增加 –unmanaged 来部署非受治理的利用:
[standalone@localhost:9990 /] deploy ~/Desktop/test-application.war --unmanaged
'test-application.war' deployed successfully.
这样将会存储文件的绝对路径在配置文件中,并且也不会去计算文件的 hash 值。
反部署利用都是一样的命令:
[standalone@localhost:9990 /] undeploy test-application.war
Successfully undeployed test-application.war.
部署笼罩
有时候咱们须要批改部署好的应用程序中的某些文件,除了能够解压应用程序之外,还能够应用 deployment-overlay 命令:
deployment-overlay add --name=myOverlay --content=/WEB-INF/web.xml=/myFiles/myWeb.xml,/WEB-INF/ejb-jar.xml=/myFiles/myEjbJar.xml --deployments=test.war,*-admin.war --redeploy-affected
总结
wildfly 的两种模式的部署就讲到这里,大家能够依据须要自行抉择。
本文作者:flydean 程序那些事
本文链接:http://www.flydean.com/wildfly-app-deployment/
本文起源:flydean 的博客
欢送关注我的公众号:「程序那些事」最艰深的解读,最粗浅的干货,最简洁的教程,泛滥你不晓得的小技巧等你来发现!