Kong Konnect と Runtime Groups による複数環境の管理

Kong Konnect による複数環境の管理

その呼び方は千差万別であり、あるときは「選択的同期」、またあるときは「環境」と呼ばれますが、Kong Gateway の複数の設定を 1 つのインターフェイスで管理できるようにすることの必要性は明らかです。本日、Kong は Kong Konnect の Runtime Groups を発表できることを嬉しく思います。

Runtime Groups を使用することで、設定を個別に管理できます。たとえば、部門間で変更を分離する必要がある場合や、本番環境に移行する前に変更をテストするためのステージング環境を作成する場合などです。

このブログでは、Runtime Groups を使用してステージング環境で変更をテストしてから、decK と GitHub Actions を使用して本番環境に変更を反映させる方法を紹介します。

Kong Bank

Kong Bank デモ環境で Runtime Groups をテストしてみましょう。Kong Bank は、Accounts、Balance、Contacts、Loans の 4 つのサービスを実行しています。

これらのサービスはすべて default ランタイム グループで実行されていますが、Balance サービスを実行しているチームは、予期せぬパフォーマンスの問題から、新しいレート制限機能を試したいと考えています。

しかし、本番環境でテストして実際のトランザクションに影響を与えたくないので、ステージング環境を実行する方法を必要としています。そこで役立つのが、新しい Konnect Runtime Groups 機能です。

ランタイム グループの作成

Kong Konnect の Runtime Manager セクションで新しいランタイム グループを作成できます (追加のランタイム グループを作成するには、エンタープライズ アカウントが必要です)。名前 (ここでは「staging」を使用) と説明を入力し、[Create] を押します。

ランタイム グループはすぐに利用可能になるため、プロビジョニングされるまで 15 分待つ必要はありません。

既存サービスのコピー

Balance サービスのコピーをステージング Runtime Group に作成します。この操作を行うには、decK バージョン 1.12.0 以上のコマンドライン ツールがインストールされている必要があります。

まず、既存の設定をローカル マシンにダウンロードする必要があります。deck dump を使用し、メール アドレス、パスワード、ダウンロードするランタイム グループの名前 (ここでは「default」) を指定します。

deck dump \
 --konnect-email $KONNECT_EMAIL \
 --konnect-password $KONNECT_PASSWORD \
 --konnect-runtime-group-name default

カレント ディレクトリに kong.yaml という名前のファイルが作成されます。decK を使用したことがある方は、次に deck sync を実行して、ランタイム グループ名を default から staging に変更しようとされるかもしれません。残念ながら、正しくないランタイム グループに対して deck sync を実行することを防ぐ decK の安全機能により、これはうまくいきません。

deck sync \
 --konnect-email $KONNECT_EMAIL \
 --konnect-password $KONNECT_PASSWORD \
 --konnect-runtime-group-name staging

Error: warning: runtime group 'staging' specified via --konnect-runtime-group flag is different from 'default' found in state file(s)

そのため、異なるランタイム グループに対して実行するには、kong.yaml から _konnect セクションを削除して、このチェックを無効にします。再度 deck sync を実行すると、期待どおりにサービスが作成されます。

deck sync \
 --konnect-email $KONNECT_EMAIL \
 --konnect-password $KONNECT_PASSWORD \
 --konnect-runtime-group-name staging
creating service Balance
creating route Default
Summary:
  Created: 2
  Updated: 0
  Deleted: 0

レート制限の追加

サービスがステージング環境にコピーされたので、decK を使用してレート制限を追加できます。サービス定義に以下を追加することで、コンシューマーからのリクエストを 1 分間に 5 つに制限します。

  plugins:
  - config:
        fault_tolerant: true
        hide_client_headers: false
        limit_by: consumer
        minute: 5
        policy: local
        enabled: true
        name: rate-limiting
        protocols:
        - http

以下は、設定ファイルの内容を示す完全な kong.yaml ファイルです。

_format_version: "1.1"
services:
- connect_timeout: 60000
  host: mockbin.org
  name: Balance
  path: /request
  plugins:
  - config:
        fault_tolerant: true
        hide_client_headers: false
        limit_by: consumer
        minute: 5
        policy: local
        enabled: true
        name: rate-limiting
        protocols:
        - http
  port: 443
  protocol: https
  read_timeout: 60000
  retries: 5
  routes:
  - https_redirect_status_code: 426
        methods:
        - GET
        name: Default
        path_handling: v0
        paths:
        - /balance
        preserve_host: false
        protocols:
        - http
        regex_priority: 0
        strip_path: false
  write_timeout: 60000

最後に、deck sync を実行して、この変更を staging ランタイム グループの Balance サービスに適用します。

deck sync \
 --konnect-email $KONNECT_EMAIL \
 --konnect-password $KONNECT_PASSWORD \
 --konnect-runtime-group-name staging

ローカルでのテスト

変更を適用したら、本番環境に移行する前に、レート制限が意図したとおりに動作するかどうかをテストします。Runtime Manager ページにアクセスし、staging ランタイム グループを選択し、[New Runtime Instance] をクリックして新しいランタイムを作成します。

Docker のクイック セットアップ スクリプトを使用して、ランタイムを作成します (Docker がイメージをプルするのに 1 ～ 2分かかることがあります)。

このコマンドは、デフォルトのランタイム グループに対してアクティブなランタイムがある場合、失敗します。その場合、コマンドの最後に -pp 8001 を指定し、代わりにポート 8001 にバインドします。

ランタイムがオンラインになったら、エンドポイントを 6 回連続で呼び出し、Kong がレート制限メッセージを返すのを確認します。

本番環境への移行

設定変更が意図したとおりに動作することが確認できたら、本番環境に移行します。kong.yaml は変更済みなので、deck sync を実行してデフォルトのランタイム グループを選択します。

deck sync \
 --konnect-email $KONNECT_EMAIL \
 --konnect-password $KONNECT_PASSWORD \
 --konnect-runtime-group-name default

creating plugin rate-limiting for service 2c5c87d6-7761-4ba1-81a4-13c24ee035e4
Summary:
  Created: 1
  Updated: 0
  Deleted: 0

簡単に、インフラに変更を加え、ステージング環境で検証し、本番環境を更新できました。

このプロセスがうまくいくことがわかったので、次はこれを開発ワークフローに組み込んでみましょう。GitHub Actions を使用して、develop にコミットしたらステージング環境に変更を自動適用し、main にコミットしたら本番環境に変更を自動適用します。

GitHub Actions で自動化

GitHub Actions には「環境」という概念があり、選択した環境に応じて実行するワークフローをカスタマイズできます。この例では、ステージング環境と本番環境の 2 つが必要です。

ステージング環境を作成するには、リポジトリ設定から [Environments] -> [New environment] を選択します。環境を作成すると、画面の下に「環境のシークレット」を追加するオプションが表示されます。KONG_RUNTIME_GROUP という名前のシークレットを作成し、ステージング用のランタイム グループ ID を設定します。ID は Runtime Manager ページで確認できます。

これが完了したら、production という名前の別の環境を作成し、KONG_RUNTIME_GROUP シークレットを default ランタイム グループの ID に設定します。

最後に、リポジトリ設定から [Secrets] -> [Actions] を選択して、特定の環境ではなくリポジトリに適用されるシークレットを追加する必要があります。

decK を使用して Kong Konnect で認証するため、リポジトリのシークレットとして KONNECT_EMAIL と KONNECT_PASSWORD を追加します。

完了すると、Actions secrets ページは次のようになります。

Kong Konnect 関連の Actions secrets

develop ブランチでの変更を staging ランタイム グループに、main ブランチでの変更を production で使用する default ランタイム グループにデプロイします。

これは、リポジトリの .github/workflows/deck.yml にある GitHub Actions ワークフローで行います。

on:
  push:
        branches:
          - main
          - develop
jobs:
  set-env:
        runs-on: ubuntu-latest
        outputs:
          environment: ${{ steps.set-env.outputs.environment }}
          runtime_group: ${{ steps.set-env.outputs.runtime_group }}
        steps:
          - id: set-env
            run: |
              if [[ $GITHUB_REF == "refs/heads/main" ]]; then
                echo "::set-output name=environment::production"
                echo "::set-output name=runtime_group::default"
              else
                echo "::set-output name=environment::staging"
                echo "::set-output name=runtime_group::staging"
              fi
  deploy:
        runs-on: ubuntu-latest
        needs: "set-env"
        environment: ${{ needs.set-env.outputs.environment }}
        steps:
          - uses: actions/checkout@v2
          - uses: kong/setup-deck@v1
            with:
              deck-version: 1.12.0
          - name: Run deck sync
            run: |
              deck sync \
                --konnect-email ${{ secrets.KONNECT_EMAIL }} \
                --konnect-password ${{ secrets.KONNECT_PASSWORD }} \
                --konnect-runtime-group-name ${{ needs.set-env.outputs.runtime_group }}

ワークフローでは、さまざまなことが行われています。順番に見ていきましょう。

  1. main ブランチや develop ブランチへのプッシュでワークフローを実行します。
  2. プッシュされたブランチに応じて、環境変数と runtime_group 変数を設定します。
  3. 適切な環境でデプロイ ジョブを実行します。
    1. リポジトリをクローンします。
    2. kong/setup-deck で decK をインストールします。
    3. deck sync を実行して変更を適用します。

ワークフローの実行

上記のワークフローを実行するには、decK の設定ファイルが必要です。先ほど作成した kong.yaml をリポジトリのルート フォルダーにコピーし、コミットして develop ブランチにプッシュします。

GitHub Actions がこれを検知して、staging 環境に変更を適用します。問題がなければ、その変更を main にマージして default ランタイム グループが更新されるのを確認します。

別の変更をテストする場合は、kong.yaml ファイルの minute の値を変更して develop にコミットします。GitHub Actions がその変更を検出して staging に適用します。

まとめ

この記事では、Kong Konnect の Runtime Groups を使用して、インフラストラクチャの変更を本番環境に適用する前にテストする方法を紹介しました。

宣言型設定により、git リポジトリを設定のソースとして使用し、GitHub Actions と git flow を使用して、開発環境から本番環境に移行する際に、自動的に変更を適用できます。

これらすべては単一の Kong Konnect アカウントで行われ、一貫したユーザー管理とアクセス制御を実現できるだけでなく、最も重要なことは、すべての設定が同じ場所にあることです。

ランタイム グループをぜひお試しください。そして、フィードバックをお寄せください。

Kong Enterprise の概要、価格、およびライセンス体系などの詳細は、こちらを参照してください。

参考記事: 2022 年 7 月 12 日
Michael Heap
© Kong Inc. 2022
「Managing Multiple Environments with Konnect and Runtime Groups」

タイトルとURLをコピーしました