API Management ランディング ゾーン アクセラレータのプラットフォーム自動化と DevOps
この記事では、API Management ランディング ゾーン アクセラレータを使用するときのプラットフォーム自動化と DevOps に関する設計上の考慮事項と推奨事項について説明します。 プラットフォームの自動化と DevOps では、コードとしてのインフラストラクチャのオプションを使用した環境のデプロイへのアプローチを最新化するための機会を提供します。
詳細については、プラットフォームの自動化と DevOps の設計領域を参照してください。
設計上の考慮事項
- 各 API チームは、独自の開発者リポジトリから独自の開発 API Management インスタンスに更新をプッシュできます。
- これは、ネットワーク計画の観点から何を意味しますか?
- 他の非運用環境 (QA やステージングなど) についてはどうでしょうか。
- 特に複数のチームが同じ製品を使用する場合は、製品やその他のエンティティを管理またはバージョン管理する方法を検討してください。
- API とポリシーのテスト戦略を検討してください。
設計の推奨事項
- 中央チーム (たとえば、API Management 管理チーム) は、運用 API Management 環境を管理します。
- API Management 構成は、Resource Manager テンプレートとしてまたは同等の Bicep または Terraform テンプレートとして表され、コードとしてのインフラストラクチャの考え方を採用する必要があります。
- API Management 管理チームは、API Management 管理チームが所有する Git リポジトリ (パブリッシャー リポジトリ) から、運用 API Management 環境に構成変更を発行します。
- 個々の API チームは、パブリッシャー リポジトリをフォークして、独自の開発者リポジトリを使用できます。
- 各チームは、API Management APIOps または Visual Studio Code 向け API Management 拡張機能を使用して、開発 API Management インスタンスから関連する成果物を抽出できます。 これらの成果物は Azure Resource Manager に基づいており、API チームの Git リポジトリにコミットする必要があります。
注意
API Management Git 統合 は使用しないでください。
- サービス テンプレートと共有テンプレートは、別のリポジトリに配置する必要があります。
- 成果物に対する変更は、抽出された成果物に対して行い、Git にコミットする必要があります。 これらは開発環境にデプロイする必要があります。
- 一元化された環境 (ステージング、運用など) に昇格するために、API チームはプル要求 (PR) を送信して、変更をパブリッシャー リポジトリにマージできます。
- API Management 管理チームが PR を検証します。
- ほとんどの検証は、PR の送信の一環として自動化されるのが理想的です。
- コードとしてのインフラストラクチャ テンプレートは、別のリポジトリに配置し、デプロイ パイプラインにデプロイする必要があります。
- インフラストラクチャのデプロイをアプリケーションのデプロイから分離します。 コア インフラストラクチャの変更は、アプリケーションよりも少なくなります。 それぞれの種類のデプロイを別のフローとパイプラインとして扱います。
- 変更が承認され、正常にマージされると、API Management 管理チームは、合意された API チームのスケジュールと連携して、一元管理された環境 (ステージング、運用) に変更をデプロイできます。
エンタープライズ規模の前提条件
API Management ランディング ゾーン アクセラレータの開発にあたっての前提を次に示します。
- コードとしてのインフラストラクチャ Bicep ファイルを使用して、API Management インフラストラクチャとバックエンドをデプロイします。
- パイプラインを使用したインフラストラクチャ テンプレートのデプロイ。