この記事では、サブスクリプションの自動販売の自動化するための実装ガイダンスを提供します。 サブスクリプション サービスによって、サブスクリプションの要求、デプロイ、管理のプロセスが標準化され、アプリケーション チームはワークロードをより迅速にデプロイできるようになります。
"図 2. Azure 環境の例におけるサブスクリプションの自動販売の実装。"
開始点として使用すべきサブスクリプション自動販売の 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 に対する認証を行う必要があります。
配置後
サブスクリプションの自動販売の自動化は、サブスクリプションの作成と構成で終了します。 プラットフォーム チームは、作成後にアプリケーション チームに新しいサブスクリプションを渡す必要があります。 アプリケーション チームは、サブスクリプションの予算を更新し、ワークロード リソースを作成し、ワークロードをデプロイする必要があります。 プラットフォーム チームは、サブスクリプションのガバナンスを制御し、時間の経過に伴うサブスクリプション ガバナンスの変更を管理します。
コスト管理を実施します。 サブスクリプション予算は、コスト管理にとって重要な通知を提供します。 デプロイでは、サブスクリプション要求データに基づいて暫定的なサブスクリプション予算を作成する必要があります。 アプリケーション チームはサブスクリプションを受け取ります。 ワークロードのニーズを満たすために予算を更新する必要があります。 詳細については、以下を参照してください:
サブスクリプション ガバナンスを管理します。 ワークロードのガバナンス要件の変更に応じて、サブスクリプションを更新する必要があります。 たとえば、サブスクリプションを別の管理グループに移動する必要がある場合があります。 これらのルーチン操作の一部に対して自動化を構築する必要があります。 詳細については、次を参照してください。
次のステップ
サブスクリプションの自動販売により、サブスクリプション作成プロセスが簡略化および標準化され、組織のガバナンスの下に置かれます。 アプリケーション チームがアプリケーション ランディング ゾーンにすばやくアクセスし、ワークロードをより迅速にオンボードできるように、サブスクリプションの自動販売の自動化を実装する必要があります。 詳細については、次を参照してください。