問題タブ [cloudfoundry-java-client]

Cloud Foundry 環境で spring-cloud-task を使用して短期間のジョブを実行することを調査しています。

ドキュメントといくつかの YouTube ビデオを調べたところ、セットアップには 3 つのコンポーネント (アプリケーション) が必要であることがわかりました。

• タスクリクエスター: TaskLaunchRequestspring-cloud-stream Rabbit/Kafka キュー/トピックに配置する spring-boot アプリ
• タスク ランチャー: と の注釈が付けられた spring-boot アプリで@EnableTaskLauncher、次の依存関係があります: spring-cloud-starter-task、spring-cloud-starter-stream-rabbit、spring-cloud-deployer-cloudfoundry、spring-cloud-deployer-resource-maven
• タスク定義: で注釈が付け@EnableTaskられ、短期間のジョブによって実行されるロジックを持つスプリング ブート アプリ

このセットアップを使用して CloudFoundry にタスクをデプロイするために必要なプロセスと構成について、いくつか質問があります。

1. と(タスク サブミッターで) を構成することとenvironmentProperties(タスク ランチャーで) を構成することの違いは何ですか? また、どこで定義する必要があり、正確には何をしますか?deploymentPropertiesapplicationNameTaskLaunchRequestCloudFoundryDeploymentPropertiesSPRING_APPLICATION_JSON
2. spring-cloud-task で見たすべての例では、maven://スキームを使用してTaskLaunchRequest#uri. spring-cloud-deployer-cloudfoundry依存関係が依存関係にバンドルされていないのはなぜspring-cloud-deployer-resource-mavenですか? CloudFoundry にデプロイするときに優先される別の URI スキームはありますか?
3. インスタンス= 0でCloud FoundryにbootJarタスクを実行するとcf-push、タスクランチャーがタスクを起動すると、すべて正常に動作します。この場合の唯一の問題は、新しいバージョンの 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-pushCloud Foundry へのタスク bootJar を実行せず、タスク アプリケーションを事前に作成しない場合、タスク ランチャーが指定した 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 アプリケーション [... ] failed during staging and this error stems from the following:org.cloudfoundry.operations.applications.DefaultApplications.pushManifest(DefaultApplications.java:431)`. タスク ランチャーが Cloud Foundry でアプリケーションを正常に作成したが、ステージングに失敗したことがわかります。ステージングに失敗したタスク アプリケーションのログは次のとおりです。

ログに記載されている内容に従って、maven アーティファクトが実際には 15.1MB の有効な bootJar であることを確認しましたが、ログにはアプリ パッケージが「12.4M」しかないことが示されています。ビルドパックのバージョン (4.29.1) も、spring.cloud.deployer.cloudfoundry.buildpacksプロパティで示したバージョンではありません。ビルドパックの構成が正しく設定されていないことが問題の可能性があると思いますが、よくわかりません。

注spring-cloud-dataflow:現時点ではアーキテクチャに導入したくありません。

以前は、Pivo​​tal クラウド ファウンドリーの無料サブスクリプションを使用して poc を実行できましたが、現在はそれができず、クラウドファウンドリーの名前が Tanzu に変更されました。

変化し続ける Cloudfoundry のタイムラインの歴史を理解したいと思います。

親切に助けてください。

OutOfMemory に heapdump を作成するには、PCF マニフェスト yml で -XXHeapdumoOutofmemory および -XXHeapdumoFilepath オプションが必要です。VM引数でSMBまたはNFSを使用できることは理解していますが、アプリがOutOfMemoryになりアクセスできなくなったときにヒープダンプファイルを取得する方法.

親切に助けてください。