如何在spring-cloud-deployer-cloudfoundry中使用spring-cloud-task？

编程问答 2022-06-12

问题描述

我正在研究使用spring-cloud-task在我的Cloud Foundry环境中执行短期工作。

通过查看文档和一些youtube视频，我发现设置应该涉及3个组件（应用程序）：

  • 任务请求者：一个春季启动应用，该应用将TaskLaunchRequest放置在春季云流Rabbit / Kafka队列/主题上
  • 任务启动器：一个带有@EnableTaskLauncher注释的spring-boot应用程序，它具有以下依赖性：spring-cloud-starter-task，spring-cloud-starter-stream-rabbit，spring-cloud-deployer-cloudfoundry，spring-cloud-deployer-resource-maven
  • 任务定义：带有@EnableTask注释的spring-boot应用程序，它具有由短期任务执行的逻辑

对于使用此设置在CloudFoundry中部署任务所需的流程和配置，我有几个问题。

  1. 在environmentProperties中（在任务提交者中）配置deploymentProperties，applicationName和TaskLaunchRequest与在CloudFoundryDeploymentProperties中配置SPRING_APPLICATION_JSON之间有什么区别任务启动器）？另外，maven://应该在哪里定义，它到底是做什么的？
  2. 我在spring-cloud-task上看到的所有示例都使用TaskLaunchRequest#uri方案来表示spring-cloud-deployer-cloudfoundry。为什么spring-cloud-deployer-resource-maven依赖项不与cf-push依赖项捆绑在一起？部署到CloudFoundry时是否有不同的URI方案是首选的？
  3. 当我将cf-push任务bootJar转到instances = 0的Cloud Foundry时，当任务启动器启动任务时，一切正常。在这种情况下，唯一的问题是，即使将新版本的SNAPSHOT bootJar发布到远程存储库，也将使用maven.remote-repositories.my-repo.snapshot-policy.update-policy: always中的原始bootJar（即使设置了cf-push）。如果已经为尝试由spring-cloud-task动态执行的应用程序定义了Cloud Foundry应用程序，则实际上未考虑Maven工件吗？换句话说，Maven工件的每个新版本（SNAPSHOT或RELEASE）是否都需要一个新的Cloud Foundry应用程序？
  4. 当我不将任务bootJar spring.cloud.deployer.cloudfoundry.push-task-apps-enabled: true). When I attempt this,then I get an error in the launcher indicating 放到Cloud Foundry且不预先创建任务应用程序时，我希望任务启动器将使用我的Maven工件在Cloud Foundry中为我创建应用程序指定（在过渡期间and this error stems from the following:应用程序[...]失败 2020-09-25T14:05:43.69-0400 [API/2] OUT Uploading bits for app with guid d598b251-4827-4c55-9e56-1d0c8301b5c3 2020-09-25T14:05:59.66-0400 [API/0] OUT Updated app with guid d598b251-4827-4c55-9e56-1d0c8301b5c3 ({"state"=>"STOPPED"}) 2020-09-25T14:06:00.26-0400 [API/0] OUT Creating build for app with guid d598b251-4827-4c55-9e56-1d0c8301b5c3 2020-09-25T14:06:00.61-0400 [API/0] OUT Updated app with guid d598b251-4827-4c55-9e56-1d0c8301b5c3 ({"state"=>"STARTED"}) 2020-09-25T14:06:01.00-0400 [STG/0] OUT Cell 884d3852-1063-452a-8e94-c11ea9307c4a creating container for instance cc9b7101-2fc4-4c56-9f86-019736eb6b71 2020-09-25T14:06:01.79-0400 [STG/0] OUT Cell 884d3852-1063-452a-8e94-c11ea9307c4a successfully created container for instance cc9b7101-2fc4-4c56-9f86-019736eb6b71 2020-09-25T14:06:01.95-0400 [STG/0] OUT Downloading app package... 2020-09-25T14:06:02.37-0400 [STG/0] OUT Downloaded app package (12.4M) 2020-09-25T14:06:04.08-0400 [STG/0] OUT -----> Java Buildpack v4.29.1 | https://github.com/cloudfoundry/java-buildpack.git#3dbe582 2020-09-25T14:06:04.08-0400 [STG/0] ERR [Buildpack] ERROR Finalize Failed with exception #<RuntimeError: No container can run this application. Please ensure that you've pushed a valid JVM artifact or artifacts using the -p command line argument or path manifest entry. information about valid JVM artifacts can be found at https://github.com/cloudfoundry/java-buildpack#additional-documentation. > 2020-09-25T14:06:04.08-0400 [STG/0] ERR No container can run this application. Please ensure that you've pushed a valid JVM artifact or artifacts using the -p command line argument or path manifest entry. information about valid JVM artifacts can be found at https://github.com/cloudfoundry/java-buildpack#additional-documentation. 2020-09-25T14:06:04.08-0400 [STG/0] ERR Failed to compile droplet: Failed to run finalize script: exit status 1 2020-09-25T14:06:04.11-0400 [STG/0] OUT Exit status 223 2020-09-25T14:06:04.52-0400 [STG/0] OUT Cell 884d3852-1063-452a-8e94-c11ea9307c4a stopping instance cc9b7101-2fc4-4c56-9f86-019736eb6b71 2020-09-25T14:06:04.52-0400 [STG/0] OUT Cell 884d3852-1063-452a-8e94-c11ea9307c4a destroying container for instance cc9b7101-2fc4-4c56-9f86-019736eb6b71 2020-09-25T14:06:04.61-0400 [API/4] ERR Failed to stage build: staging Failed 2020-09-25T14:06:05.15-0400 [STG/0] OUT Cell 884d3852-1063-452a-8e94-c11ea9307c4a successfully destroyed container for instance cc9b7101-2fc4-4c56-9f86-019736eb6b71 org.cloudfoundry.operations.applications.DefaultApplications.pushManifest（DefaultApplications.java:431）中。我可以看到任务启动器已成功在Cloud Foundry中创建了该应用程序，但未能上演该应用程序。 以下是任务应用程序无法上载的日志：
spring.cloud.deployer.cloudfoundry.buildpacks

根据日志中的内容，我检查了maven工件实际上是有效的15.1MB bootJar，但日志显示我的应用程序包仅为“ 12.4M”。 buildpack版本（4.29.1）也不是我在spring-cloud-dataflow属性中指示的版本。我认为问题可能出在buildpack配置设置不正确，但是我不确定。

注意：我现在不希望将<ServiceResultOfarrayofstringuHEDJ7Dj xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/HotelWeb.SanAdminSite.RestWebApi.App_Data"> <Data xmlns:d2p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays"> <d2p1:string>1105</d2p1:string> <d2p1:string>1111</d2p1:string> </Data> <Error> <Code></Code> <Message></Message> </Error> <InfoMessage></InfoMessage> <IsSuccessful>true</IsSuccessful> </ServiceResultOfarrayofstringuHEDJ7Dj> 引入我的体系结构。

解决方法

对于手动cf push与CF Java Client应用程序部署之间的差异，我最终发现反应式cf java-client 4.0.9.RELEASE+与Netty 4.1.51.Final有问题，其中Netty失败执行文件上传。我升级了依赖项以使用Netty 4.1.52.Final，现在客户端可以正确部署我的应用程序了。

有关这两个组件之间的问题的详细信息，请参见https://github.com/cloudfoundry/cf-java-client/releases。

cloudfoundry-java-clientspring-cloudspring-cloud-dataflowspring-cloud-task