Spring Cloud Dataflow（SCDF）でストリームを作成すると、基盤となるアプリケーションがデプロイされ、RabbitMQなどの通信サービスがバインドされ、Spring Cloud Stream環境変数が設定され、アプリケーション。これは、cf pushコマンドを使用して手動で簡単に行うことができます。
はい - ストリームアプリケーションを個別にオーケストレーションすることができ、それには利点があります。ただし、ストリームアプリケーションのそれぞれをchannelName,destinationおよびバインディング固有のプロパティで手動で配線しようとすると、より多くの簿記に対処する必要があります。これはすべて、Spring Cloud Data Flow（SCDF）のオーケストレーション・レイヤーでのバック・ザ・シーンの雑用になります。
特に、ストリーミングパイプラインに「スケーリング」や「パーティション」が含まれている場合は、instanceCount,instanceIndexおよび関連するプロパティに注意する必要があります。これらは、DSLセマンティクスを通じてSCDFで自動化されています。
SCDFサーバー我々の実験に基づいて、PCF上のメモリ豚（私は6アプリケーションとのストリームを持って、まだ私は、サーバーのために10ギガバイト程度必要としています）
あり、これは一般的ですあなたが「開発」にいるときと、>展開中の>破棄しているストリームを繰り返し作成するときに、1日に数回見られます。一般的に言えば、サーバーは1Gしか必要ありません。
PCFのJVMが実際に使用していないメモリを報告するという一般的な合意があります。これはjavaのrt.jarで何かする必要があります。PCFの 'メモリ使用状況レポート作成'機能に新しいカーネルがいくつか変更されているため、JVMの起動後（は多くのリソースを使用します）は悪いデータを報告し続けません。私たちは密接にこれを追跡しています。
私たちはまた、サーバーのプロファイリングを行って、メモリリークがないことを確認しています。つまり、サーバーに必要な最小限のメタデータ状態（：ストリーム定義など）がRDBMSに保持されます。開発については#107をご覧ください。
あなたのアプリケーションの命名」によって何を意味するかは明らかではないアプリケーションの命名、メモリ、インスタンスなど（あなたが通常manifest.ymlに設定しますすべてのもの）
ではありません柔軟性"サーバー名を処理する必要がある場合は、manifest.ymlなどの方法で簡単に変更できます。ストリームアプリ名と関係がある場合は、プレフィックスとして「ストリーム名」を使用して自動的にデプロイされるため、CF CLIまたはApps-Mgrからアプリをレビューすると簡単に識別できます。
メモリとディスクの用途については、各アプリケーションレベルでSPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_STREAM_MEMORYとSPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_STREAM_DISKのトークンで制御できます。詳細はhereです。
我々はSCDF CLIを使用する必要があるため（竹のような）ビルドツールとの統合は、余分な作業を必要としようとしている
だけではなく、PCF CLI
あなたはCIを実行していることだろうに基づいていますストリーム/タスクアプリケーションは、開発ワークフローの一部です。 SCDFは、これらのアプリケーションを管理するオーケストレーションの仕組みを提供するだけです。近い将来、すぐに使用できるように、Netflix's Spinnakerツールとのネイティブ統合も進めています。
既存のストリームは変更できません。青緑のデプロイメントを行うには、アプリケーションを手動でデプロイする必要があります（サービスをバインドし、環境変数を手動で設定する必要があります）。青緑の配置が完了すると、SCDFはそのストリームを「失敗」と表示します。なぜなら、基礎となるアプリケーションの1つが変更されたことを知らないからです。
アプリでは、rolling upgradesのように青緑色を個別に実行できます。 SCDFのストリーム/タスクのアプリケーション状態の変更にも対応できるアクティブなw-i-pがあります。 Spinnakerの統合により、カスタムアプリケーションビットのローリングアップグレードがさらに単純化され、SCDFは動的な変更に適応します。これは、この要件が満たされる限り、最終目標です。
MySQLの主キー制約エラーのような私はに実行した
さまざまなエラー、我々はあなたのフィードバックを聞くのが大好きだ失敗したストリーム
を再配備しようとしたとき、具体的には、これらの問題をbacklogに報告することを検討してください。この点に関する助言は高く評価されます。
私は何が欠けていますか？なぜSpring Cloud Dataflowを使用するのは、アプリケーションを手動でデプロイするだけで有益でしょうか？
architecture sectionは一般的な機能をカバーします。多数のストリームアプリケーションやタスクアプリケーション（など）を使用する場合は、クラウド設定で集中管理ツールを使用する必要があります。 SCDFはDSL、REST-API、Dashboard、Floを提供します。もちろん、すぐに使えるセキュリティレイヤーを提供します。ストリームとタスクの相互運用性は、クローズドループアナリティクスを使用するユースケースのもう1つの重要な要件です。これを中心にDSLツールがあります。 Spinnakerの統合がファーストクラスの市民になると、データパイプラインを介してエンドツーエンドの継続的な配信が行われることが予測されます。最後に、Cloud FoundryのSCDFタイルはSpring Cloud Servicesと相互運用され、包括的なセキュリティカバレッジとともにプロビジョニングの面をさらに自動化します。
これが役に立ちます。
Sabby - お返事いただきありがとうございます。だから、いくつかのフォローアップの質問。 1 - 特に多数のストリームがある場合は、中央のオーケストレーションツールを使用することは有益であることに同意します。しかし、青緑の配置が行われるとすぐに、SCDFのストリーム定義は古くなり、失敗と表示されます。 MySQLに入ってストリームの定義を手動で変更する以外に、現時点ではこれを回避する方法はないと言っていますが、これはWIPです。 –
2 - 私がアプリケーション名、メモリなどを指しているとき、私は作成されている基礎となるアプリケーションを指しています。 SCDFはランダムな名前を使用しています（私たちは制御できません）、展開されたすべてのアプリケーションの設定を変更せずにアプリケーションのインスタンス/メモリをカスタマイズする方法はありません。これを回避する方法はありますか？ –
3 - あなたはすぐに出てくるセキュリティ層について言及します。 SCDFは、基本的なアプリケーションを手動で展開する場合と比較して、追加または異なるセキュリティを提供しますか？ –