Edge for Private Cloud v. 4.17.05
Edge Private Cloud のオンプレミス環境、または Edge インスタンスは、 一連のサーバーノードにインストールされている Edge コンポーネント。次の図に、Terraform の VPC ネットワークを構成する地球、リージョン、ポッド、組織、環境、 エッジ インスタンス:
次の表に、これらの関係を示します。
以下を含む |
関連付け |
デフォルト |
|
---|---|---|---|
惑星 |
1 つ以上のリージョン |
なし |
|
リージョン |
1 つ以上の Pod |
「dc-1」 |
|
ポッド |
1 つ以上の Edge コンポーネント |
「central」 |
|
組織 |
1 つ以上の環境 |
Message Processor を含む 1 つ以上の Pod と、組織管理者として機能するユーザー |
なし |
環境 |
1 つ以上の仮想ホスト |
親組織に関連付けられた Pod 内の 1 つ以上の Message Processor |
なし |
仮想ホスト |
1 つ以上のホスト エイリアス |
なし |
惑星について
「惑星」は、Edge のハードウェアとソフトウェア環境全体を表し、 1 つ以上のリージョンにとどめますEdge では、惑星とはリージョンの論理グループです。 Edge をインストールする際に、惑星を明示的に作成または構成することもできます。
リージョンについて
リージョンとは、1 つ以上の Pod のグループです。デフォルトでは、Edge をインストールすると、 「dc-1」という名前の単一のリージョンが作成されます次のテーブルのように、3 つの Pod が含まれます。 表示されます。
リージョン |
リージョン内の Pod |
---|---|
「dc-1」 |
"gateway"、"central"、"analytics" |
次の図は、デフォルトのリージョンを示しています。
この画像は、ロードバランサがトラフィックを「ゲートウェイ」に転送する様子を示しています。作成します。「ゲートウェイ」チーム には、API リクエストを処理する Edge Router と Message Processor のコンポーネントが含まれています。ただし、 複数のデータセンターを定義する場合、追加のリージョンを作成する必要はありません。
より複雑なインストールでは、2 つ以上のリージョンを作成できます。Google Cloud で マシンを地理的に整理することで、ネットワーク移行時間を最小限に抑えられます。イン このシナリオでは、データセンターに地理的に「近い」場所に API エンドポイントをホストします。 コンシューマとして活用できます
Edge では、各リージョンをデータセンターと呼びます。あるデータセンターは、 米国東部はマサチューセッツ州ボストンから到着したリクエストを処理できます。 シンガポールでは、アジアのデバイスやコンピュータからのリクエストを処理できます。
たとえば、次の画像は、2 つのデータセンターに対応する 2 つのリージョンを示しています。
Pod について
ポッドとは、1 つ以上の Edge コンポーネントと Cassandra データストアのグループです。エッジ コンポーネントは同じノードにインストールできますが、異なるノードにインストールするのが一般的です。 Cassandra データストアは、Pod 内の Edge コンポーネントによって使用されるデータ リポジトリです。
デフォルトでは、Edge をインストールすると、インストーラが 3 つの Pod を作成し、 次の Edge コンポーネントと Cassandra データストアを各 Pod にアタッチします。
ポッド |
Edge コンポーネント |
Cassandra データストア |
|
---|---|---|---|
"gateway" |
Router、Message Processor |
キャッシュ データストア |
keyvaluemap-datastore |
「central」 |
Management Server、Zookeeper、LDAP、UI、Qpid |
application-datastore |
identityzone-datastore |
"分析" |
Postgres |
analytics-datastore |
reportcrud-datastore |
「ゲートウェイ」の Edge コンポーネントと Cassandra データストアAPI には Pod が必要 あります。API リクエストを処理するには、これらのコンポーネントとデータストアが稼働している必要があります。「 コンポーネントとデータストアを「中央」の「analytics」Pod は API を処理する必要がないため、 Edge に機能を追加します
次の図は、各 Pod のコンポーネントを示しています。
Google Cloud で作成される 3 つの Pod に Message Processor と Router の Pod を あります。または、既存の Pod に Edge コンポーネントを追加することもできます。たとえば 「ゲートウェイ」に Router と Message Processor をPod の負荷の増加に対応する トラフィック負荷を表します。
「ゲートウェイ」はこの Pod には、Edge Router と Message Processor のコンポーネントが含まれています。 Router は、同じ Pod 内の Message Processor にのみリクエストを送信し、同じ Pod 内の Message Processor には送信しない Pod にアタッチされます。
次の API 呼び出しを使用すると、セッションの最後にサーバー登録の詳細を表示できます。 インストールする必要があります。これは便利なモニタリング ツールです。
curl -u adminEmail:pword http://<ms_IP>:8080/v1/servers?pod=podName
ここで、ms_IP は Management Server の IP アドレスまたは DNS 名です。 podName は次のいずれかです。
- gateway
- 中部
- アナリティクス
たとえば "gateway" にはpod:
> curl -u adminEmail:pword http://<ms_IP>:8080/v1/servers?pod=gateway
出力は次のようになります。
[ { "externalHostName" : "localhost", "externalIP" : "192.168.1.11", "internalHostName" : "localhost", "internalIP" : "192.168.1.11", "isUp" : true, "pod" : "gateway", "reachable" : true, "region" : "dc-1", "tags" : { "property" : [ { "name" : "jmx.rmi.port", "value" : "1101" }, ... ] }, "type" : [ "message-processor" ], "uUID" : "276bc250-7dd0-46a5-a583-fd11eba786f8" }, { "internalIP" : "192.168.1.11", "isUp" : true, "pod" : "gateway", "reachable" : true, "region" : "dc-1", "tags" : { "property" : [ ] }, "type" : [ "dc-datastore", "management-server", "cache-datastore", "keyvaluemap-datastore", "counter-datastore", "kms-datastore" ], "uUID" : "13cee956-d3a7-4577-8f0f-1694564179e4" }, { "externalHostName" : "localhost", "externalIP" : "192.168.1.11", "internalHostName" : "localhost", "internalIP" : "192.168.1.11", "isUp" : true, "pod" : "gateway", "reachable" : true, "region" : "dc-1", "tags" : { "property" : [ { "name" : "jmx.rmi.port", "value" : "1100" }, ... ] }, "type" : [ "router" ], "uUID" : "de8a0200-e405-43a3-a5f9-eabafdd990e2" } ]
type 属性は、コンポーネントのタイプを示します。ここには Cassandra が Pod に登録されているデータストアの数を表します。Cassandra ノードは「ゲートウェイ」にインストールされていますが、Pod、 すべての Pod に登録されている Cassandra データストアが表示されます。
組織について
組織は、Apigee アカウント内のすべてのオブジェクトのコンテナです。次のものが含まれます。 API、API プロダクト、アプリ、デベロッパー。組織は 1 つ以上の Pod に関連付けられており、 各 Pod には 1 つ以上の Message Processor が必要です。
Edge Private Cloud のオンプレミス環境にはデフォルトで組織は存在しません。 組織を作成する際は、次の 2 つの情報を指定します。
- 組織管理者として機能するユーザー。その後、ユーザーは 各ユーザーを組織に追加し、各ユーザーの役割を設定します。
- 「ゲートウェイ」Message Processor を含む Pod です。
組織には 1 つ以上の環境を含めることができます。Edge のデフォルトのインストール手順 「test」という 2 つの環境を作成するように求められます。作成しますこれ以外の 「staging」、「experiments」など、さまざまな環境を指定できます。
組織は、一部の Apigee 機能にスコープを提供します。例: Key-Value-map(KVM) データは組織レベル、つまりすべての環境から利用できます。その他の機能、 スコープは特定の環境をスコープとしますApigee の分析データは 組織と環境の組み合わせです。
以下に、組織の主要オブジェクトを示します。 環境に明確に定義されているものは
環境について
環境とは、組織内の API プロキシのランタイム実行コンテキストです。 環境にアクセスできるようにするには、その環境に API プロキシをデプロイする必要があります。ある特定の API プロキシを、単一の環境または複数の環境にデプロイできます。
1 つの組織に複数の環境を含めることが可能です。たとえば、「dev」というフォルダを 「test」、「prod」1 つです
環境を作成するときに、環境を 1 つ以上の Message Processor に関連付けます。Google Chat では 環境は、API プロキシが実行される Message Processor の名前付きセットと考えることができます。毎 複数の Message Processor を同じ Message Processor に関連付けることも、異なる Message Processor に関連付けることもできます。
環境を作成するには、次の 2 つの情報を指定します。
- 環境を含む組織。
- 環境に対する API プロキシ リクエストを処理する Message Processor。このメッセージ
プロセッサは、環境の親組織に関連付けられた Pod に配置する必要があります。
デフォルトでは、環境を作成するときに Edge が環境内の使用可能なすべての Message Processor を関連付けます。 「ゲートウェイ」Pod が作成されます。または、サービス アカウントのサブセットを Message Processor ごとにリクエストを処理するようにできます。 必要があります。
Message Processor は複数の環境に関連付けることができます。たとえば、Edge に 2 つの Message Processor(A と B)が含まれています。次に、プロジェクトに 3 つの環境を organization: "dev", "test", and "prod":
- 「dev」にはMessage Processor A を関連付けます。この 1 つを トラフィック量が多くなります。
- 「test」については、Message Processor B を関連付けます。この 1 つを トラフィック量が多くなります。
- 「prod」に対してはMessage Processor A と B の両方を関連付けて 必要があります。
環境に割り当てられた Message Processor は、すべて同じ Pod に属するものでも、別の Pod のものでもかまいません。 複数のリージョンとデータセンターにまたがっています。たとえば、 環境「global」3 つのリージョンの Message Processor を含む組織に つまり、米国、日本、ドイツの 3 つのデータセンターが存在します。
「グローバル」への API プロキシのデプロイMessage API に対して API プロキシが実行されます。 3 つのデータセンターすべてにプロセッサを配置します。いずれか 1 つの Router に到着した API トラフィック そのデータセンター内の Message Processor にのみ転送されます。これは、Router が 同じ Pod 内の Message Processor にのみトラフィックを転送します。
仮想ホストについて
仮想ホストは、API プロキシが公開される Edge Router のポートを定義します。 さらに、アプリが API プロキシにアクセスするために使用する URL です。すべての環境では、 構成する必要があります。
仮想ホストで指定されたポート番号が Router ノードで開いていることを確認します。Google Chat では 次の URL にリクエストを発行して API プロキシにアクセスします。
http://<routerIP>:<port>/{proxy-base-path}/{resource-name} https://<routerIP>:<port>/{proxy-base-path}/{resource-name}
ここで
- http または https: 仮想ホストが次のように構成されている場合 TLS/SSL をサポートしているため、HTTPS を使用してください。仮想ホストが TLS/SSL をサポートしていない場合は、HTTP を使用します。
- <routerIP>:<port> は IP 仮想ホストのアドレスとポート番号を指定します。
- {proxy-base-path} と {resource-name} が定義されている API プロキシを作成するときに指定します。
通常、IP アドレスとポート番号を使用して API をお客様に公開することはありません。 代わりに、Router とポートの DNS エントリを定義します。例:
http://myAPI.myCo.com/{proxy-base-path}/{resource-name} https://myAPI.myCo.com/{proxy-base-path}/{resource-name}
また、DNS のドメイン名と一致するホスト エイリアスを仮想ホストに作成することも必要です。 あります。上記の例では、ホスト エイリアス myAPI.myCo.com を指定します。 DNS エントリがない場合は、ホスト エイリアスを Router の IP アドレスとポート <routerIP>:port の形式で指定します。
詳細については、http://apigee.com/docs/api-services/content/virtual-hosts をご覧ください。
最初の組織を作成する ファイアウォール環境、仮想ホスト
Edge のインストール プロセスが完了したら、通常、最初に行う作業として、 「オンボーディング」を通じた組織、環境、仮想ホストへの準拠をプロセスです目的 Edge Management Server ノードで次のコマンドを実行します。
/opt/apigee/apigee-service/bin/apigee-service apigee-provision setup-org -f configFile
このコマンドは、ユーザー、組織、環境、サービス アカウントを定義する構成ファイルを入力として 構成されます。
たとえば、次のように作成します。
- 組織管理者として機能することを選択したユーザー
- example という名前の組織
- すべての Message イベントに関連付けられている prod という名前の組織内の環境。 「ゲートウェイ」のプロセッサチーム
- ポートでの HTTP アクセスを許可する、default という名前の環境内の仮想ホスト 9001
- 仮想ホストのホスト エイリアス
このスクリプトを実行した後、次の形式の URL を使用して API にアクセスできます。
http://<router-ip>:9001/{proxy-base-path}/{resource-name}
組織、環境、仮想ホストはいくつでも追加できます。
オンボーディングの詳細については、 できます。