ref-app の「アプリケーション」は、いくつかの「アプリ」と Predix の「サービス」で構成されています。アプリは、manifest.yml のエントリを介してサービスにバインドされます。したがって、このバインディングを介して、サービス エンドポイントとその他の重要な構成情報を取得します。アプリがサービスにバインドされている場合、「cf env」コマンドは必要な情報を返します。
プロパティ ファイルにはまだサービス エンドポイント情報が含まれている可能性がありますが、これは時間の経過とともにリファクタリングされる予定です。
ref-app アプリケーションの個々のアプリは、他のアプリケーションのコンポーネントとして使用されるため、個別のマイクロサービスに配置されます。したがって、マイクロサービスのアプローチです。アプリ間でスタートアップの依存関係がある場合、アプリをクラウドにプッシュする CI/CD パイプラインは、これらの依存関係を管理する必要があります。ref-app の依存関係は、単純に明らかなものです。
マイクロサービスの結合が設計されていないことは事実ですが。これが発生する可能性があるいくつかの明白な理由があります。言語と機能。NodeJS 上の Javascript で記述された「フロントエンド」UI マイクロサービスによって使用される Java で記述された「バックエンド」マイクロサービスがある場合、これらは 2 つの別個のアプリとしてプッシュされます。理論的には、UI はバックエンドなしではうまく機能しませんが、実際に既定の JSON を使用してそれを実現する計画があります。それでも、そこにはいくつかの論理的な結合があります。
マイクロサービスから得られる素晴らしい点は、異なるスケーリングが必要になる可能性があることです。クラウド ファウンドリでは、「cf scale」コマンドを使用してそれを非常に簡単に行うことができます。それらは他の複数のマイクロサービスで使用される可能性があるため、新しいスケール要件が作成されます。したがって、何をスケーリングする必要があるか、また機能のリリース サイクルを考慮すると、マイクロサービスを構成するものを決定するのに役立ちます。
たとえば、注文に関しては、アプリケーションで Google マップ API が必要になる場合があるため、アプリケーションを最初に起動し、アプリケーションを 2 番目に起動する必要があると言えます。しかし実際には、マップ API がダウンしている可能性があることをアプリケーションで考慮する必要があります。目標は、依存するマイクロサービスが利用できないときにアプリが適切に動作することです。
「アプリケーション」の「アプリ」は、その名前とクラウドが提供する URL により、それぞれについて認識しています。実際には、さまざまなクラウドやスペースで実行されている参照アプリの多くのコピーがあります。Dev、QA、Integration などで始まります。Dev フロントエンドが QA バックエンド マイクロサービスと通信できるようにすることはできますか?確かに、それは単なる URL です。
前述の etcd (まだ試していません) に加えて、CUPS サービスの「定義」を作成することもできます。これもキーと値のペアのセットです。スペース (dev/qa/stage/prod) に関連付けて、マニフェスト経由でバインドできます。このようにして、環境から小道具を取得します。