サブスクリプションの自動販売の実装ガイダンス

Azure

この記事では、サブスクリプションの自動販売の自動化するための実装ガイダンスを提供します。サブスクリプションサービスによって、サブスクリプションの要求、デプロイ、管理のプロセスが標準化され、アプリケーションチームはワークロードをより迅速にデプロイできるようになります。

"図 2. Azure 環境の例におけるサブスクリプションの自動販売の実装。"

GitHub icon 開始点として使用すべきサブスクリプション自動販売の Bicep および Terraform モジュールを作成しました。テンプレートは実装のニーズに合わせて変更する必要があります。サブスクリプションの自動販売プロセスの詳細については、サブスクリプションの自動販売機の概要に関する記事を参照してください。

アーキテクチャ

サブスクリプションの自動販売の自動化は、3 つの主要なタスクが達成されるように設計する必要があります。サブスクリプションサービスの自動化では、(1) サブスクリプション要求データを収集し、(2) プラットフォームの自動化を開始し、(3) コードとしてのインフラストラクチャを使用してサブスクリプションを作成する必要があります。これら 3 つのタスクを達成するためにサブスクリプションサービスの自動化を実装するには、いくつかのアプローチがあります。実装例では、Gitflow を使用する 1 つのアプローチを示しています (図 2)。 Gitflow 設計は、多くのプラットフォームチームがプラットフォームを管理するために使用する宣言型アプローチと合致しています。

"図 2. サブスクリプションの自動販売の自動化の実装例。"

実装例 (図 2) では、データ収集ツールによってサブスクリプション要求データが収集されます。サブスクリプション要求が承認されると、プラットフォームの自動化が開始されます。 "プラットフォームの自動化" は、要求パイプライン、ソース管理、デプロイパイプラインで構成されます。 "要求パイプライン" では、データ収集ツールのデータを含む JSON または YAML サブスクリプションパラメーターファイルが作成されます。また、要求パイプラインでは、新しいブランチが作成され、サブスクリプションパラメーターファイルがコミットされて、"ソース管理" で pull request が開かれます。新しいブランチは、ソース管理のメインブランチにマージされます。マージによって "デプロイパイプライン" がトリガーされ、コードとしてのインフラストラクチャモジュールを使用してサブスクリプションが作成されます。

デプロイでは、ガバナンス要件に基づいて、サブスクリプションを正しい管理グループに配置する必要があります (図 1 を参照)。デプロイによって、コスト管理の基礎として暫定的なサブスクリプション予算が作成されます。デプロイでは、ワークロードのニーズに基づいて、空の仮想ネットワークが作成され、リージョンハブへのピアリングが構成される可能性があります。プラットフォームチームは、作成および構成後にアプリケーションチームにサブスクリプションを渡す必要があります。アプリケーションチームは、サブスクリプションの予算を更新し、ワークロードリソースを作成する必要があります。

データを収集する

データを収集する目的は、ビジネス承認を受けて、JSON/YAML サブスクリプションパラメーターファイルの値を定義することです。アプリケーションチームがサブスクリプション要求を送信する際に、データ収集ツールを使用して必要なデータを収集する必要があります。データ収集ツールは、プラットフォームの自動化を開始するために、サブスクリプションの自動販売ワークフロー内の他のシステムとやり取りする必要があります。

データ収集ツールを使用します。 IT サービスマネジメント (ITSM) ツールを使用してデータを収集したり、Microsoft PowerApps のようなローコードまたはコードなしのツールを使用してカスタマーポータルを構築したりできます。データ収集ツールは、サブスクリプション要求を承認または拒否するためのビジネスロジックを提供する必要があります。

必要なデータを収集します。 デプロイを自動化できるように、JSON/YAML サブスクリプションパラメーターの値を定義するのに十分なデータを収集する必要があります。収集する具体的な値は、ニーズによって異なります。要求承認者、コストセンター、ネットワークの要件 (インターネットまたはオンプレミス接続) を把握する必要があります。予想されるワークロードコンポーネント (アプリケーションプラットフォーム、データ要件)、データの機密性、環境の数 (開発、テスト、運用前、運用) をアプリケーションチームに確認すると役立つ場合があります。

データを検証します。 データ収集プロセス中にデータを検証する必要があります。プラットフォームの自動化フェーズの後半では問題に対処することが困難になります。

追跡可能な要求を作成します。 データ収集ツールでは、新しいサブスクリプション (例えば、ITSM ツールのチケット) に対するログに記録される追跡可能な要求を作成する必要があります。この要求には、そのサブスクリプションの要件を満たすために必要なすべてのデータが含まれている必要があります。ビジネスロジックと認可追跡を要求にバインドする必要があります。

他の内部システムとやり取りします。 必要に応じ、データ収集ツールは組織内の他のツールまたはシステムとやり取りする必要があります。目標は、他のシステムからのデータを使用して要求をエンリッチすることです。自動化を実行するためには、ID、財務、セキュリティ、ネットワークのデータが必要な場合があります。たとえば、自動化は IP アドレス管理 (IPAM) ツールとやり取りして、適切な IP アドレス空間を予約できます。

トリガーを作成します。 サブスクリプション要求が承認を受けると、データ転送によってプラットフォームの自動化がトリガーされます。データ収集ツールから必要なデータを含むプッシュ通知を作成することをお勧めします。プロセスを開始するには、Azure Functions や Azure Logic Apps などのミドルウェアレイヤーが必要な場合があります。

プラットフォームの自動化を開始する

データ収集ツールからの通知とデータによって、プラットフォームの自動化がトリガーされます。プラットフォームの自動化の目的は、JSON/YAML サブスクリプションパラメーターファイルを作成し、ファイルをメインブランチにマージし、それをコードとしてのインフラストラクチャモジュールと共にデプロイしてサブスクリプションを作成することです。プラットフォームチームは、プラットフォームの自動化を所有し、維持する必要があります。実装例のプラットフォームの自動化は、要求パイプライン、ソース管理、デプロイパイプラインで構成されています (図 2 を参照)。

JSON または YAML ファイルを使用します。 構造化データファイル (JSON または YAML) を使用して、サブスクリプションを作成するためのデータを格納する必要があります。ファイルの構造を文書化し、将来のニーズをサポートするために拡張できるようにする必要があります。たとえば、次の JSON コードスニペットは、GitHub のいずれかの Bicep モジュールのサブスクリプションパラメーター値を定義します。

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "subscriptionDisplayName": {
      "value": "sub-bicep-lz-vending-example-001"
    },
    "subscriptionAliasName": {
      "value": "sub-bicep-lz-vending-example-001"
    },
    "subscriptionBillingScope": {
      "value": "providers/Microsoft.Billing/billingAccounts/1234567/enrollmentAccounts/123456"
    },
  // Insert more parameters here
  }
}

ファイル全体を表示します。その他の例については、Bicep の例と Terraform の例を参照してください。

サブスクリプション要求ごとに 1 つのファイルを使用します。 サブスクリプションはサブスクリプションの自動販売プロセスにおけるデプロイの単位であるため、サブスクリプション要求ごとに 1 つの専用サブスクリプションパラメーターファイルが必要になります。

pull request システムを使用します。 サブスクリプションパラメーターファイルを作成する Gitflow プロセスでは、次の手順を自動化する必要があります。

サブスクリプション要求ごとに新しいブランチを作成します。
収集したデータを使用して、ブランチ内の新しいサブスクリプションに対する 1 つの YAML/JSON サブスクリプションパラメーターファイルを作成する
ブランチから main への pull request を作成します。
この pull request の状態の変更と参照を使用してデータ収集ツールを更新します。

実装例の要求パイプラインでは、これらの手順が実行されます (図 2 を参照)。ワークフローが複雑な場合は、Azure でホストされているコードベースのソリューションを使用することもできます。

サブスクリプションパラメーターファイルを検証します。 pull request は、要求データを検証するためのリンティングプロセスをトリガーする必要があります。目標は、デプロイが成功したことを確認することです。 YAML/JSON サブスクリプションパラメーターファイルを検証する必要があります。 IP アドレス範囲がまだ使用可能であることを検証することもできます。また、人間の介入を伴う手動レビューゲートの追加が必要になることもあります。最終的なレビューを実行し、サブスクリプションパラメーターファイルに変更を加えることができます。出力は、サブスクリプションを作成するためのすべてのデータを含む JSON/YAML サブスクリプションパラメーターファイルである必要があります。

デプロイパイプラインをトリガーします。 pull request が main ブランチにマージされると、そのマージによってデプロイパイプラインがトリガーされます。

サブスクリプションの作成

サブスクリプションの自動販売の自動化の最後のタスクは、新しいサブスクリプションを作成して構成することです。実装例では、デプロイパイプラインを使用して、JSON/YAML サブスクリプションパラメーターファイルと共にコードとしてのインフラストラクチャモジュールをデプロイします (図 2 を参照)。

コードとしてのインフラストラクチャを使用します。 デプロイでは、コードとしてのインフラストラクチャを使用してサブスクリプションを作成する必要があります。プラットフォームチームは、適切なガバナンスを確保するために、これらのテンプレートを作成して維持する必要があります。サブスクリプション自動販売の Bicep および Terraform モジュールを使用し、実装のニーズに合わせて変更する必要があります。

デプロイパイプラインを作成します。 デプロイパイプラインは、新しいサブスクリプションの作成と構成を調整します。このパイプラインでは、次のタスクを実行する必要があります。

タスクのカテゴリ	パイプラインのタスク
ID	• サブスクリプションの所有権を表す Microsoft Entra リソースを作成または更新する。 • ワークロードチームのデプロイ用に特権ワークロード ID を構成します。
ガバナンス	• 管理グループ階層に配置します。 • サブスクリプション所有者を割り当てます。 • 構成済みセキュリティグループに対するサブスクリプションレベルのロールベースのアクセス制御 (RBAC) を構成する。 • サブスクリプションレベルの Azure Policy を割り当てます。 • Microsoft Defender for Cloud 登録を構成する。
ネットワーク	• 仮想ネットワークをデプロイします。 • プラットフォームリソース (リージョンハブ) への仮想ネットワークピアリングを構成します。
Budgets	• 収集されたデータを使用してサブスクリプション所有者の予算を作成します。
報告	• IPAM などの外部システムを更新して IP 予約にコミットします。 • 最終的なサブスクリプション名とグローバル一意識別子 (GUID) を使用してデータ収集ツール要求を更新します。 • サブスクリプションの準備ができていることをアプリケーションチームに通知する。

プログラムでサブスクリプションを作成するには、商業契約が必要です。商業契約がない場合、サブスクリプションを作成するための手動プロセスを導入する必要がありますが、サブスクリプション構成の他のすべての側面は自動化できます。

ワークロード ID を確立します。 デプロイパイプラインでは、やり取りするすべてのシステムでこれらの操作を実行するためのアクセス許可が必要です。マネージド ID または OpenID Connect (OIDC) を使用して Azure に対する認証を行う必要があります。

配置後

サブスクリプションの自動販売の自動化は、サブスクリプションの作成と構成で終了します。プラットフォームチームは、作成後にアプリケーションチームに新しいサブスクリプションを渡す必要があります。アプリケーションチームは、サブスクリプションの予算を更新し、ワークロードリソースを作成し、ワークロードをデプロイする必要があります。プラットフォームチームは、サブスクリプションのガバナンスを制御し、時間の経過に伴うサブスクリプションガバナンスの変更を管理します。

コスト管理を実施します。 サブスクリプション予算は、コスト管理にとって重要な通知を提供します。デプロイでは、サブスクリプション要求データに基づいて暫定的なサブスクリプション予算を作成する必要があります。アプリケーションチームはサブスクリプションを受け取ります。ワークロードのニーズを満たすために予算を更新する必要があります。詳細については、以下を参照してください:

サブスクリプションガバナンスを管理します。 ワークロードのガバナンス要件の変更に応じて、サブスクリプションを更新する必要があります。たとえば、サブスクリプションを別の管理グループに移動する必要がある場合があります。これらのルーチン操作の一部に対して自動化を構築する必要があります。詳細については、次を参照してください。

次のステップ

サブスクリプションの自動販売により、サブスクリプション作成プロセスが簡略化および標準化され、組織のガバナンスの下に置かれます。アプリケーションチームがアプリケーションランディングゾーンにすばやくアクセスし、ワークロードをより迅速にオンボードできるように、サブスクリプションの自動販売の自動化を実装する必要があります。詳細については、次を参照してください。

Share via