その呼び方は千差万別であり、あるときは「選択的同期」、またあるときは「環境」と呼ばれますが、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 ページは次のようになります。
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 }}
ワークフローでは、さまざまなことが行われています。順番に見ていきましょう。
main
ブランチやdevelop
ブランチへのプッシュでワークフローを実行します。- プッシュされたブランチに応じて、環境変数と
runtime_group
変数を設定します。 - 適切な環境でデプロイ ジョブを実行します。
- リポジトリをクローンします。
kong/setup-deck
で decK をインストールします。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」