環境は、API プロキシを実行するための分離コンテキストまたは「サンドボックス」を提供します。1 つの組織で、複数の環境を作成できます。
多くのユーザーは、基本インストール中にテスト用の環境を 1 つだけセットアップします。しかし、複数の環境を作成して、それぞれに限られた数のプロキシをデプロイすることをおすすめします。
仮想ホストと環境について
Apigee Hybrid は、Istio Ingress ゲートウェイを使用して、受信 API トラフィックを処理します。MART サービスとランタイム サービスはどちらも Istio Ingress ゲートウェイを使用して、クラスタ外部に公開された接続を管理するように構成されます。これは、たとえば、API プロキシへのすべての HTTP リクエストと HTTPS リクエストが最初に Istio Ingress ゲートウェイで処理されることを意味します。
ハイブリッドでは、1 つ以上の環境を作成して、各環境にホスト エイリアスを 1 つずつ割り当てます。 ホスト エイリアスは DNS 名です。その DNS 名への受信トラフィックは、Ingress でその環境にルーティングされます。内部的に、各環境は 1 つの Message Processor だけに割り当てられます。このプロセッサは、プロキシ リクエストの処理、ポリシーの適用、ターゲット サービスとの間でやり取りされるトラフィックのルーティングを担当します。したがって、ホスト エイリアスが、特定の受信リクエストをどの Message Processor が受信するかを決定します。
次のコードは、複数の環境が定義されている構成例を示しています(このような構成は、オーバーライド ファイルにあります)。環境の dev1 と prod1 のホスト エイリアスは異なることに注意してください。
envs: - name: dev1 hostAlias: "apitest.mydomain.net" ... - name: prod1 hostAlias: "apiprod.mydomain.net" ...
ベースパス /foo1
を持つプロキシが環境 dev1 にデプロイされているとします。次のようにプロキシを呼び出すことができます。
curl -k https://apitest.mydomain.net/foo1
この呼び出しが Ingress に到達したとき、Ingress はその呼び出しの送信先が dev1
環境に関連付けられた Message Processor であることを知っており、そこでリクエストが処理されます。
同様に、foo1
も prod1
環境にデプロイされている場合は、このようなプロキシ リクエストをホスト エイリアス apiprod.mydomain.net
に発行できます。
curl -k https://apiprod.mydomain.net/foo1
この呼び出しは Ingress によってそのホストに関連付けられた MP にルーティングされます。
つまり、作成する環境ごとにホスト エイリアスを割り当てる必要があります。各環境が 1 つの Message Processor だけにマッピングされ、ホスト エイリアスがリクエストを受け取る Message Processor を特定します。
複数の環境で同じホスト エイリアスを共有できます
Apigee Hybrid を使用すれば、好きな方法で管理できる複数の環境を作成できます。たとえば、dev1、dev2、dev3 などの複数の開発環境を作成し、それぞれに 1 つのホスト エイリアスをマッピングすることができます。さらに、各環境に複数のプロキシをデプロイできます。
アンチパターン: すべてのプロキシを 1 つのハイブリッド環境にデプロイする。
おすすめの方法: 複数の環境を作成し、それぞれに限られた数のプロキシをデプロイする。ハイブリッドがプロキシ呼び出しをホスト エイリアスを共有する適切な環境にルーティングする方法を管理するための手法をベース パス ルーティングと言います。
たとえば、次の構成では、環境の dev1 と dev2 が同じホスト エイリアスを共有しています。
envs: - name: dev1 hostAlias: "apitest.mydomain.net" ... - name: dev2 hostAlias: "apitest.mydomain.net" ...
複数の環境が同じホスト エイリアスを共有している場合は、ベース パス ルーティングという構成手法を使用して、特定のプロキシ ベース パスを特定の環境にマッピングする必要があります。詳細については、ベース パス ルーティングをご覧ください。
プロキシ デプロイメントの数を制限する
ハイブリッドの場合に、複数の環境で同じ仮想ホストを共有できるということは、特定の環境へのプロキシ デプロイメントの管理方法を慎重に検討する必要があることを意味します。ハイブリッドでは、複数の環境を作成して、それぞれに限られた数のプロキシをデプロイすることをおすすめします。
環境にデプロイするプロキシの数はいくつにすべきですか?この質問に対する答えはありませんが、次の表で、各環境にデプロイするプロキシの数を制限することが推奨される理由と、プロキシ デプロイメントの管理で考慮すべきことに関する一般的なガイダンスを提供します。
考慮すべき課題 | 説明 |
---|---|
Message Processor の起動時間 | Message Processor(MP)が起動するまでの時間とその MP にデプロイされるプロキシの数には直接的な相関関係があります。自動スケーリング Kubernetes 環境では、起動時間の増加が問題になることがあります。MP にデプロイされるプロキシが多いほど、その MP のスケーリングや再作成が必要な場合の MP の起動時間が長くなります。 |
スケーリングのパフォーマンス | 1 つの環境に複数のプロキシがデプロイされ、プロキシの 1 つが大量のトラフィックを受信するために頻繁に自動スケーリングされる場合は、その環境内のすべてのプロキシがそれと一緒にスケーリングされます。1 つの高トラフィック プロキシを含む複数のプロキシのスケーリングでは、パフォーマンスが低下することがあります。 |
ノイジー ネイバー | 同じ環境に複数のプロキシがデプロイされた状態で、1 つのプロキシがクラッシュすると、MP の再起動中にその環境内のすべてのプロキシが停止します。環境にデプロイするプロキシの数を制限することにより、1 つのプロキシのクラッシュによる影響を最小限に抑えられます。 |
環境設定リファレンス
環境設定要素の完全なリストについては、構成プロパティのリファレンスで envs をご覧ください。
環境の操作
構成の詳細については、以下のトピックをご覧ください。