環境について

環境は、API プロキシを実行する分離されたコンテキスト、すなわち「サンドボックス」を提供します。単一の組織で複数の環境を作成できます。詳細については、環境と環境グループについてをご覧ください。

次のコードは、複数の環境が定義されている構成をオーバーライドする例を示しています。環境 prod と test のホストエイリアスが異なることに注意してください。

namespace: my-namespace
org: my-organization
...
envs:
  - name: test
    serviceAccountPaths:
      synchronizer: "your_keypath/synchronizer-manager-service-account.json
      udca: "your_keypath/analytic-agent-service-account.json

  - name: prod
    serviceAccountPaths:
      synchronizer: "your_keypath/synchronizer-manager-service-account.json
      udca: "your_keypath/analytic-agent-service-account.json
...

routingRules を環境にマッピングする virtualhosts プロパティを追加します。

virtualhosts:
  - name: default
    hostAliases: ["api.example.com"]
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    routingRules:
      - env: test

virtualhosts:
  - name: external
    hostAliases: ["apiprod.example.com"]
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    routingRules:
      - env: prod

ベースパス /foo1 のプロキシが環境 test にデプロイされているとします。このプロキシは、次のように呼び出すことができます。

curl -k https://api.example.com/foo1

この呼び出しが Ingress に到着すると、Ingress は呼び出しリクエストを処理する test 環境の Message Processor に呼び出しを送信します。

同様に、foo1 が prod 環境にもデプロイされている場合は、ホストエイリアス apiprod.mydomain.net に次のようなプロキシリクエストを発行できます。

curl -k https://apiprod.example.com/foo1

この呼び出しは、Ingress によってそのホストに関連付けられている MP にルーティングされます。

注: API プロキシがリクエストを受信すると、Ingress は受信リクエストの Host ヘッダーをホストエイリアスのリストと比較して、リクエストを処理する仮想ホストを特定します。curl コマンド、ブラウザ、その他多くのユーティリティでは、リクエストのドメインを使用して Host ヘッダーを自動的に設定します。なんらかの理由でアプリが Host ヘッダーを自動的に設定しない場合は、手動で設定する必要があります。

アンチパターン: すべてのプロキシを 1 つのハイブリッド環境にデプロイします。

ベストプラクティス: 複数の環境を作成し、それぞれの環境に限られた数のプロキシをデプロイします。特定の API プロキシのベースパスをルーティングする先の環境を指定するルーティングルールを作成できます。詳細については、仮想ホストの構成をご覧ください。

プロキシデプロイの数を制限する

ハイブリッドの場合、多くの環境で同じ仮想ホストを共有できます。これは、特定の環境へのプロキシデプロイの管理方法を慎重に検討する必要があることを意味します。ハイブリッドでは、複数の環境を作成して、それぞれの環境に限られた数のプロキシをデプロイすることをおすすめします。

環境にはプロキシをいくつデプロイすべきでしょうか。この質問に対する決まった答えはありませんが、次の表に、各環境にデプロイするプロキシの数を制限することが推奨される理由と、プロキシデプロイを管理する際に考慮すべき事項に関する一般的なガイダンスを示します。

考慮すべき課題	説明
Message Processor の起動時間	Message Processor（MP）が起動するまでの時間とその MP にデプロイされるプロキシの数には直接的な相関関係があります。自動スケーリングの Kubernetes 環境では、起動時間の増加が問題になることがあります。MP にデプロイされるプロキシが多いほど、その MP のスケーリングや再作成が必要な場合に MP の起動時間が長くなります。
スケーリングのパフォーマンス	1 つの環境に複数のプロキシがデプロイされ、プロキシの 1 つが大量のトラフィックを受信するために頻繁に自動スケーリングする場合、その環境内のすべてのプロキシがスケーリングされます。複数のプロキシをスケーリングする際、トラフィック量の多いプロキシが 1 つでもあると、パフォーマンスが低下することがあります。
ノイジーネイバー	同じ環境に複数のプロキシがデプロイされた状態で、プロキシが 1 つでもクラッシュすると、MP の再起動中にその環境内のすべてのプロキシが停止します。1 つの環境にデプロイされるプロキシの数を制限することで、単一のプロキシがクラッシュした場合の影響を最小限に抑えられます。

環境構成のリファレンス

環境構成の要素の詳細については、構成プロパティのリファレンスの envs をご覧ください。

環境の操作

構成の詳細については、以下のトピックをご覧ください。