Azure Resource Manager テンプレート (ARM テンプレート) の管理をモジュール化すると、繰り返しを減らし、インフラストラクチャ開発のベスト プラクティスをモデル化し、一貫した標準デプロイを実現できます。
この種のモジュール化を実装するユース ケースの例には、T シャツ サイズのたとえを使用した仮想マシン (VM) のデプロイがあります。 数十台または数百台の VM をデプロイしたとします。 これらのデプロイでは、バージョン 1.0.0 のテンプレートを使用し、古いシリーズの標準 "M" サイズがあります。 新しいシリーズに移行するには、新しいテンプレートをデプロイしただけの場合、サービスの短時間の停止が必要になる可能性があります。 ただし、バージョン 1.5.0 をビルドし、モジュール化を使用することで、古いインフラストラクチャをデプロイ可能な状態に保ちながら、更新された標準を使用して新しいインフラストラクチャをデプロイできます。 古いバージョンのインフラストラクチャを使用可能にしておくと、製品チームとアプリケーション チームは、時間ができたときに新しいバージョンにアップグレード中に、既知の正常な構成を利用できます。
リポジトリのレイヤー ケーキ: 企業の例
テンプレートの移動先、テンプレートの更新方法などに強い希望がある理由については、"分岐" と "インナーソーシング" という 2 つの主な考慮事項があります。
分岐。 このシナリオ例では、Gitflow と GitHub フローをサポートする Git 分岐モデルを実行します。 Gitflow の詳細については、Jeff Kreeftmeijer のブログ投稿である「Git-flow を使用して Git 分岐ワークフローを自動化する」を参照してください。 GitHub フローの詳細については、GitHub ドキュメントの「GitHub フロー」を参照してください。
インナーソーシング。 2 つ目は、オープンソース ソフトウェア開発のコラボレーティブ プラクティスを社内開発に持ち込む "インナーソーシング" です。 このようなシナリオでは、異なるテンプレートとモジュールのソース コードをより確実に共有できます。デプロイ モデル自体のアクセス許可について必ずしも心配する必要はありません。 インナーソース開発の詳細については、GitHub の「インナーソースの概要」を参照してください。
Bicep は、Azure リソースをデプロイするための宣言型言語です。 Bicep の再利用可能なコードでは、バージョン管理された ARM テンプレートをホストするためのプライベート レジストリとして Azure Container Registry を使用できます。 このように Container Registry を使用することで、企業はインフラストラクチャの継続的インテグレーションと継続的デリバリー (CI/CD) のプロセスを用意することができます。 CI プロセスの一環として統合テストと単体テストを実行できます。コンテナー レジストリは、モジュールが正常にビルドされた後にモジュールを受け取ることができます。 アプリ チームは、アップグレードの準備ができるまで古いバージョンを引き続き使用できます。または、新しいバージョンのテンプレートの機能を利用するように更新することもできます。
このコンテナー レジストリの使用の他に、このモデルを Azure 検証済モジュールのようなものと組み合わせることもできます。 実装は、パブリック レジストリから使用することも、可能であればパブリック リポジトリをモニターし、将来の使用に備えてプライベート レジストリに変更をプルすることもできます。 独自のコンテナー レジストリに変更をプルすると、パブリック モジュールに対してテストを実行すると同時に、品質とセキュリティのプラクティスが組み込まれるまで運用環境で使用されないようにすることができます。
レイヤー
このシナリオ例で提案されているモデルは、スタックされているモデルです。 レイヤーがスタックの上部に近いほど、デプロイの頻度とデプロイのカスタマイズが増えます。 Bicep コードでは、一貫性のあるデプロイが提供されます。 開発チームは、貢献のためにレイヤーで作業し、以下のレイヤーで提供されるサービスとインフラストラクチャから構築します。 下位レイヤーでは、上位レイヤーのリソースを利用できません。 レイヤー 0 から 3 は、順にグローバル ライブラリ、グローバル インフラストラクチャ (グローバル共有サービス)、製品プラットフォーム (共有サービス)、アプリケーションです。
このモデルでは、"アライメントを使用した自律性" が作成されます。これには、以下のものがあります。
企業向けの一般的なツール。 たとえば、だれもがソース管理に git を使用し、CI/CD に GitHub Actions を使用します。 ただし、やりすぎません。 たとえば、すべてのチームが Bicep を使用することを義務付けるわけではありません。Terraform、ARM テンプレート、その他のツールを使用できます。
ベスト プラクティスを共有できること。 ARM テンプレート、ゴールデン イメージ、またはコード スニペットの形式を取ることができます。 ベスト プラクティスは、具体的な手法のドキュメントでもあります。 たとえば、環境内のキーをローテーションする方法や、コードをテストする方法などです。
一部のサービスはスタック内で下方に移動します。 たとえば、アプリ チームは最初に Kubernetes クラスターをデプロイするためのテンプレートを開発します。これは後で、共有サービスとして製品プラットフォームにプルされます。 このテンプレートは非常に便利になるので、サンプルのライブラリにプルされます。
レイヤー 0 - グローバル ライブラリ
一番下のレイヤーは "グローバル ライブラリ" です。これは、運用環境にデプロイされていない便利な情報のリポジトリです。 アクセス制御の観点から、読み取りアクセスは、それを要求する会社の任意のユーザーに提供されます。 変更や提案などについては、クラウドのセンター オブ エクセレンス (CCoE) が PR を承認し、他の製品と同様にバックログを管理します。
レイヤー 0 には、以下のものは含めるべきでは "ありません"。
- 運用環境にデプロイされるテンプレート。
- シークレットまたは環境固有の構成。
レイヤー 0 には、以下のものが含まれている "必要があります"。
- コード スニペット (Python、C# など)。
- Azure Policy のサンプル。
- サンプルとして使用できる ARM テンプレート、Bicep テンプレート、または Terraform ファイル。
この例は、会社が環境固有の情報なしで 3 層アプリケーションのデプロイを記述する方法を示すサンプル アーキテクチャです。 このサンプル アーキテクチャには、タグ、ネットワーク、ネットワーク セキュリティ グループなどが含まれます。 環境に関する特定の情報を除外できると便利です。これは、すべてのものをモジュールに配置できる、または配置する必要があるとは限らないためです。 そうしようとすると、過剰なパラメーター化が生じる可能性があります。
さらに、レイヤー 0 は、Terraform レジストリや Azure Resource Modules など、他の既知の適切なサンプル コードのソースにリンクできます。 組織でそれらのソースのいずれかからコードまたはパターンを採用する場合は、パブリック ソースから直接プルするのではなく、コードまたはパターンを独自のレイヤー 0 にプルすることをお勧めします。 レイヤー 0 を利用すると、独自のテスト、微調整、セキュリティ構成を作成できます。 パブリック ソースを利用しないと、予期せず削除される可能性があるものに依存するリスクが軽減されます。
適切なサンプル コードと見なされるために、テンプレートとモジュールは、セキュリティと組織の要件に対する入力検証など、適切な開発プラクティスに従う必要があります。 このレベルの厳格さを維持するには、提案された変更に対してプル要求 (PR) とコード レビューを要求するポリシーをメイン ブランチに追加する必要があります。これにより、マージされた場合にメイン コンテナー レジストリに変更が流れます。
レイヤー 0 は、Azure Pipelines または GitHub Actions にフィードされ、Azure Container Registry でバージョン管理された成果物を自動的に作成します。 Git コミット メッセージの自動化を構築して、成果物の セマンティック バージョニングを実装できます。 これが正しく機能するには、<service>.bicep などの確定的な名前付け標準を用意して、長期にわたって自動化を保守可能にする必要があります。 適切なブランチ ポリシーを使用すると、コード レビューの前提条件として統合テストを追加することもできます。 これは、Pester などのツールを使用してインストルメント化できます。
このようなポリシーと保護が用意されていれば、コンテナー レジストリは、使用する準備ができている企業内のすべてのインフラストラクチャ モジュールの信頼できる情報源になることができます。 このコードを検出できるように、変更ログと使用可能なコード サンプルのインデックスを標準化することを検討する必要があります。 不明なコードとは、使用されていないコードです。
レイヤー 1 - グローバル インフラストラクチャ: グローバル共有サービス
レイヤー 1 は、"お使いの" Azure ランディング ゾーン構成体用のリポジトリです。 Microsoft は Azure ランディング ゾーンのデプロイ用のテンプレートを提供していますが、特定のコンポーネントを変更し、パラメーター ファイルを指定する必要があります。 これは、前述のように、パブリック レジストリとモジュール リポジトリをレイヤー 0 にプルする方法に似ています。
Azure Container Registry は、このアーキテクチャの重要な部分です。 会社でコンテナーを使用する予定がない場合でも、Bicep テンプレートのバージョン管理を成功させるには、Container Registry をデプロイする必要があります。 Container Registry を使用すると、エンタープライズ レベルのセキュリティとアクセス制御を提供しながら、モジュールの大幅な柔軟性と再利用性が可能になります。
レイヤー 1 には、以下のものが含まれている必要があります。
- 管理グループまたはサブスクリプションのレベルで適用されるポリシーの割り当てと定義。 これらのポリシーは、コーポレート ガバナンスの要件と一致している必要があります。
- ExpressRoute、VPN、仮想 WAN、仮想ネットワーク (共有またはハブ) などのコア ネットワーク インフラストラクチャ用のテンプレート。
- DNS。
- コアな監視 (Log Analytics)。
- エンタープライズ コンテナー レジストリ。
このリポジトリに変更をプッシュする機能を制限するようにブランチ保護を構成する必要があります。 他の開発者からの PR の承認を CCoE またはクラウド ガバナンスのメンバーに制限します。 このレイヤーの共同作成者は、主に、このレイヤー内のコンポーネントに従来関連付けられているグループのメンバーです。 たとえば、ネットワーク チームはネットワークのテンプレートを構築し、運用チームはモニターを構成します。 ただし、他のグループの開発者がコア インフラストラクチャの変更を提案できるようにする必要があるため、要求する個人に読み取り専用アクセス権を付与する必要があります。 これらの個人が改善をもたらす可能性がありますが、変更をマージするには承認とテストが必要です。
これらのファイルは、標準コンポーネントのコンテナー レジストリ内のモジュールを使用する必要があります。 ただし、企業の Azure ランディング ゾーンの実装または同様のガバナンス構造に合わせてカスタマイズされた Bicep ファイルまたは一連の Bicep ファイルもあります。
レイヤー 2 - 製品プラットフォーム: 共有サービス
製品プラットフォームであるレイヤー 2 を、特定の製品ラインまたは事業単位の共有サービスと見なすことができます。 これらのコンポーネントは組織全体に共通でなく、特定のビジネス ニーズに適合させるためのものです。 これは、レイヤー 1 グローバル インフラストラクチャのハブとのピアである仮想ネットワークに適したレイヤーです。 このレイヤーのもう 1 つのコンポーネント例は、キー コンテナーです。 キー コンテナーは、ストレージ アカウント、またはこのプラットフォーム内の別々のアプリケーションで共有されるデータベースに、共有シークレットを格納できます。
レイヤー 2 には、以下のものが含まれている必要があります。
- 製品固有の要件に一致するようにサブスクリプションまたはリソース グループで適用されるポリシーの割り当て。
- キー コンテナー、ログ分析、SQL データベース (製品内のさまざまなアプリケーションがデータベースを使用している場合)、および Azure Kubernetes Service 用の ARM テンプレート。
このリポジトリに変更をプッシュする機能を制限するアクセス許可を実装する必要があります。 他のレイヤーと同様に、ブランチ保護を使用して、製品リーダーまたは所有者が他の開発者からの PR を承認できることを確認する必要があります。 製品プラットフォームへの読み取りアクセスに関する固定のルールはありませんが、少なくとも、アプリケーション チームの開発者には、変更を提案できるように読み取りアクセス権を付与する必要があります。 レイヤー 2 には専用のアーキテクチャや同様の情報が含まれている可能性があるため、プラットフォームを使用する組織内のユーザーにアクセスを制限することを選択できます。 ただし、その場合は、グローバル ライブラリであるレイヤー 0 と共有するために、このリポジトリから適切なプラクティスとスニペットを収集するプロセスを確実に構築する必要があります。
レイヤー 3 - アプリケーション
アプリケーション層であるレイヤー 3 には、製品プラットフォームの上に構築されたコンポーネントが含まれます。 これらのコンポーネントは、ビジネスで要求される機能を提供します。 たとえば、ストリーミング プラットフォームの場合、あるアプリが検索機能を提供し、別のアプリが推奨事項を提供します。
レイヤー 3 には、以下のものが含まれている必要があります。
- C#、Python などのアプリケーション コード。
- 個々のコンポーネントのインフラストラクチャ (このアプリケーションでのみ使用されます): 関数、Azure Container Instances、Event Hubs。
このリポジトリに変更をプッシュする機能に対するアクセス許可は制限されます。 ブランチ保護を使用して、このアプリケーションのチーム メンバーが別のチーム メンバーによって行われた PR を承認できるようにする必要があります。 チーム メンバーは、自分の変更を承認することはできません。 このレイヤーには専用のアーキテクチャ、ビジネス ロジック、または同様の情報が含まれている可能性があるため、このアプリケーションを構築する組織内のユーザーにアクセスを制限することを選択できます。 ただし、その場合は、グローバル ライブラリであるレイヤー 0 と共有するために、このレイヤーから適切なプラクティスとスニペットを収集するプロセスも構築する必要があります。
レイヤー間の共通点
この記事では、レイヤーごとに具体的な詳細について説明していますが、すべてのレイヤーに対して考慮すべきいくつかの性質もあります。
インフラストラクチャは、アプリケーションであるかのように動作する必要があります。 つまり、単体テスト、スモーク テスト、統合テストを使用して、新機能を十分にテストする継続的インテグレーション (CI) プロセスが必要です。 これらのテストに合格したコードのみをメイン リリース ブランチにマージする必要があります。
また、便宜上でも、個人がプロセスを回避するのを防ぐためにブランチ ポリシーが設定されていることを確認する必要があります。 CI プロセスが障害と見なされる場合は、対処する必要がある技術的負債が発生したことを意味します。 ポリシーと保護を除去する必要があるという意味ではありません。
最後に、すべてのリポジトリとその中のコードのインデックスがない場合でも、組織はリポジトリへのアクセスを個人が要求するためのプロセスを作成する必要があります。 特定のルールを完全に自動化できます。 たとえば、製品のアプリケーションについて、製品チーム内の共同作成者に、レビューなしで読み取りアクセス権を付与するルールを実装できます。 このようなルールは、多くの場合、環境でグループベースのメンバーシップとグループベースのロール割り当てを使用して実装できます。 この種のアクセスを構成すると、インナーソーシングと組織のナレッジを容易に実現するのに役立ちます。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
- Tim Sullivan | シニア クラウド ソリューション アーキテクト
その他の共同作成者:
- Gary Moore | プログラマー/ライター
次の手順
- 設計領域: プラットフォームの自動化と DevOps
- チーム構造を成熟させる
- コードとしてのインフラストラクチャとは
- Azure/ResourceModules: このリポジトリには、完成度が高くキュレート済みの Bicep モジュールの CI プラットフォームとコレクションが含まれています。 このプラットフォームでは、Azure Resource Manager と Bicep の両方がサポートされており、その機能をGitHub アクションと Azure Pipelines で使用できます。
- Bicep モジュール用のプライベート レジストリを作成する