1

我正在调查使用 spring-cloud-task 在我的 Cloud Foundry 环境中执行短期作业。

查看文档和一些 youtube 视频，我收集到我的设置应该涉及 3 个组件（应用程序）：

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

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

  1. 配置environmentProperties，deploymentProperties和（applicationName在TaskLaunchRequest任务提交者中）与配置CloudFoundryDeploymentProperties（在任务启动器中）有什么区别？另外，应该在哪里SPRING_APPLICATION_JSON定义它，它到底做了什么？
  2. 我看到的所有 spring-cloud-task 示例都使用该maven://方案来指示TaskLaunchRequest#uri. 为什么依赖项不与spring-cloud-deployer-cloudfoundry依赖项捆绑在一起spring-cloud-deployer-resource-maven？部署到 CloudFoundry 时是否首选不同的 URI 方案？
  3. 当我cf-push使用实例 = 0 将任务 bootJar 到 Cloud Foundry 时，当任务启动器启动任务时，一切正常。在这种情况下，唯一的问题是，即使将新版本的 SNAPSHOT bootJar 发布到远程存储库，也会cf-push使用来自 的原始 bootJar（即使在设置时maven.remote-repositories.my-repo.snapshot-policy.update-policy: always）。如果已经为尝试由 spring-cloud-task 动态执行的应用程序定义了 Cloud Foundry 应用程序，是否实际上没有考虑 maven 工件？换句话说，maven 工件的每个新版本（SNAPSHOT 或 RELEASE）是否都需要新的 Cloud Foundry 应用程序？
  4. 当我没有cf-push将任务 bootJar 发送到 Cloud Foundry 并且没有预先创建任务应用程序时，我希望任务启动器将使用我指定的 maven 工件在 Cloud Foundry 中为我创建应用程序（使用spring.cloud.deployer.cloudfoundry.push-task-apps-enabled: true). When I attempt this, then I get an error in the launcher indicating Application [... ] 在暂存and this error stems from the following:org.cloudfoundry.operations.applications.DefaultApplications.pushManifest(DefaultApplications.java:431)` 期间失败。我可以看到任务启动器已成功在 Cloud Foundry 中创建了应用程序，但未能暂存它。什么我错过了这个工作吗？以下是任务应用程序中未能暂存的日志：
   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

按照日志中所说的，我检查了 maven 工件实际上是 15.1MB 的有效 bootJar，但日志显示我的应用程序包只有“12.4M”。buildpack 版本（4.29.1）也不是我在spring.cloud.deployer.cloudfoundry.buildpacks属性中指定的版本。我认为问题可能在于未正确设置 buildpack 配置，但我不确定。

注意：我现在不想在spring-cloud-dataflow我的架构中引入。

4

1 回答 1

0

对于手动和 CF Java 客户端应用程序部署之间的差异cf push，我终于发现反应式 cf java-client4.0.9.RELEASE+与 Netty 存在问题，4.1.51.Final即 Netty 无法执行文件上传。我升级了依赖项以使用 Netty 4.1.52.Final，现在客户端能够正确部署我的应用程序。

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

于 2020-09-29T20:17:54.597 回答