プラネット、リージョン、ポッド、組織、環境、仮想ホストについて

Edge Private Cloud のオンプレミス環境、または Edge インスタンスは、 一連のサーバーノードにインストールされている Edge コンポーネント。次の図に、Terraform の VPC ネットワークを構成する地球、リージョン、ポッド、組織、環境、 エッジ インスタンス:

次の表に、これらの関係を示します。

コンポーネント 次を含む 関連付け デフォルト
惑星 1 つ以上のリージョン なし
リージョン 1 つ以上の Pod 「dc-1」
ポッド 1 つ以上の Edge コンポーネント "central"
"gateway"
"分析"
組織 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 キャッシュ データストア
カウンタ データストア
dc-datastore 		keyvaluemap-datastore
kms-datastore
「central」 Management Server、Zookeeper、LDAP、UI、Qpid application-datastore
apimodel-datastore
audit-datastore
auth-datastore		 identityzone-datastore
edgenotification-datastore
management-server
scheduler-datastore
user-settings-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
  • central
  • analytics

たとえば "gateway" にはpod:

curl -u adminEmail:pword http://ms_IP:8080/v1/servers?pod=gateway

Apigee から次のような出力が返されます。

[ {
  "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 つの情報を指定します。

  1. 組織管理者として機能するユーザー。その後、ユーザーは 各ユーザーを組織に追加し、各ユーザーの役割を設定します。
  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 つの情報を指定します。

  1. 環境を含む組織。
  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 として）

詳細については、仮想ホストについてをご覧ください。

最初の組織を作成する ファイアウォール環境、仮想ホスト

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://routerIP:9001/proxy-base-path/resource-name

組織、環境、仮想ホストはいくつでも追加できます。

詳細については、組織のオンボーディングをご覧ください。