How to use spring-cloud-task with spring-cloud-deployer-cloudfoundry?

Question

I am investigating using spring-cloud-task to execute short-lived jobs in my Cloud Foundry environments.

Looking through the documentation and some youtube videos, I gathered that there should be 3 components (applications) involved for my setup:

• The task-requester: a spring-boot app that places a TaskLaunchRequest on a spring-cloud-stream Rabbit/Kafka queue/topic
• The task-launcher: a spring-boot app annotated with @EnableTaskLauncher and which has the following dependencies: spring-cloud-starter-task, spring-cloud-starter-stream-rabbit, spring-cloud-deployer-cloudfoundry, spring-cloud-deployer-resource-maven
• The task-definition: a spring-boot app annotated with @EnableTask and which has the logic to be performed by the short-lived job

I have several questions about the process and configurations required to get a task deployed in CloudFoundry using this setup.

1. What is the difference between configuring environmentProperties, deploymentProperties and applicationName in the TaskLaunchRequest (in the task-submitter) versus configuring the CloudFoundryDeploymentProperties (in the task-launcher)? Also, where should the SPRING_APPLICATION_JSON be defined and what does it do exactly?
2. All of the examples I have seen for spring-cloud-task use the maven:// scheme to indicate the TaskLaunchRequest#uri. Why doesn't the spring-cloud-deployer-cloudfoundry dependency come bundled with the spring-cloud-deployer-resource-maven dependency? Is there a different URI scheme that is preferred when deploying to CloudFoundry?
3. When I cf-push the task bootJar to Cloud Foundry with instances=0, when the task-launcher launches the task then everything works fine. The only problem in this case is that even when publishing a new version of the SNAPSHOT bootJar to the remote repository, the original bootJar from the cf-push is used instead (even when setting maven.remote-repositories.my-repo.snapshot-policy.update-policy: always). Is the maven artifact not actually considered if the Cloud Foundry application is already defined for the application that is trying to be dynamically executed by spring-cloud-task? In other words, does every new version (SNAPSHOT or RELEASE) of the maven artifact require a new Cloud Foundry application?
4. When I do not cf-push the task bootJar to Cloud Foundry and do not pre-create the task application, then I expect that the task-launcher will create the application in Cloud Foundry for me using the maven artifact I specified (with spring.cloud.deployer.cloudfoundry.push-task-apps-enabled: true). When I attempt this, then I get an error in the launcher indicating Application [...] failed during stagingand this error stems from the following:org.cloudfoundry.operations.applications.DefaultApplications.pushManifest(DefaultApplications.java:431)`. I can see that the task-launcher has created the application in Cloud Foundry successfully, but that it failed to stage it. What am I missing to get this working? Here are the logs from the task application that fails to stage:

   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

Following what was said in the logs, I have checked that the maven artifact is in fact a valid bootJar of 15.1MB, but the logs show that my app package is only "12.4M". The buildpack version (4.29.1) is also not the version I indicated in spring.cloud.deployer.cloudfoundry.buildpacks property. I think the problem may be with the buildpack configuration not being set correctly, but I'm not sure.

Note: I do not want to introduce spring-cloud-dataflow into my architecture at this time.

Answer 1

For the discrepancy between a manual cf push and a CF Java Client app deployment, I finally discovered that the reactive cf java-client 4.0.9.RELEASE+ has an issue with Netty 4.1.51.Final where Netty fails to perform file uploads. I upgraded my dependencies to use Netty 4.1.52.Final and now the client is able to properly deploy my application.

See https://github.com/cloudfoundry/cf-java-client/releases for the details of the issue between these 2 components.