この記事では、DevOps のプラクティスを損なうことなく仮想マシンのコンプライアンスを管理する方法について説明します。 Azure VM Image Builder と Azure Compute Gallery を使用すると、システム イメージからのリスクを最小限に抑えることができます。
Architecture
このソリューションは、次の 2 つの処理で構成されています。
- ゴールデン イメージの公開処理
- 仮想マシン (VM) のコンプライアンスを追跡するプロセス
このアーキテクチャの Visio ファイルをダウンロードします。
データフロー
ゴールデン イメージの公開処理は毎月実行され、次の手順が含まれています。
- この処理では、Azure Marketplace から基本イメージをキャプチャします。
- VM Image Builder によって、イメージがカスタマイズされます。
- イメージ タトゥー処理では、ソース、公開日などのイメージのバージョン情報が追跡されます。
- 自動テストによってイメージが検証されます。
- イメージのテストが失敗した場合は、修復のためのカスタマイズ手順に戻ります。
- 公開処理により、完成したイメージが公開されます。
- Compute Gallery で、DevOps チームがイメージを使用できるようになります。
このアーキテクチャの Visio ファイルをダウンロードします。
VM コンプライアンスの追跡処理には、次の手順が含まれます。
- Azure Policy によって、ポリシー定義が VM に割り当てられ、VM のコンプライアンス対応状態が評価されます。
- Azure Policy によって、VM とその他の Azure リソースのコンプライアンス データが Azure Policy ダッシュボードに公開されます。
Components
VM Image Builder は、システム イメージをカスタマイズするためのマネージド サービスです。 このサービスでは、DevOps チームが使用するイメージをビルドして配布します。
Compute Gallery を使用すると、カスタム イメージを構築して整理することができます。 このサービスでは、リポジトリにイメージを格納することで、イメージへの制御されたアクセスを提供します。 組織内のユーザーと組織外のユーザーが使用できます。
Azure Policy ではポリシー定義が提供されます。 これらの定義を使用して、組織の標準を適用し、大規模にコンプライアンスを評価することができます。 Azure Policy ダッシュボードに Azure Policy による評価の結果が表示されます。 このデータにより、リソースのコンプライアンス対応状態を常に把握することができます。
Azure Policy の Azure Automanage マシン構成機能を使用すると、コードを使用して構成を動的に監査したり、マシンに割り当てたりすることができます。 通常、この構成には、環境またはオペレーティング システムの設定が含まれています。
代替
サードパーティ製のツールを使用して、コンプライアンスを管理できます。 ただし、この種類のツールでは、通常、ターゲット VM にエージェントをインストールする必要があります。 また、ライセンス料の支払いが必要になる場合もあります。
カスタム スクリプト拡張機能を使用して、VM にソフトウェアをインストールしたり、デプロイ後に VM を構成したりすることができます。 ただし、各 VM または仮想マシン スケール セットでは、1 つのカスタム スクリプト拡張機能のみを持つことができます。 また、カスタム スクリプト拡張機能を使用すると、DevOps チームがアプリケーションをカスタマイズすることができなくなります。
シナリオの詳細
各企業には、独自のコンプライアンス規制と標準があります。 セキュリティに関して、各会社には独自のリスク許容度があります。 セキュリティの標準は、ある組織と別の組織、あるリージョンと別のリージョンで異なる場合があります。
オンプレミス システムとは異なり、クラウド環境を動的にスケーリングする際には、さまざまな標準に従うことがより困難になることがあります。 チームで DevOps プラクティスを使用する場合、通常、VM などの Azure リソースを作成できるユーザーの制限は少なくなります。 このことにより、コンプライアンスの課題が複雑になります。
Azure Policy とロールベースのアクセス制御の割り当てを使用することにより、企業は Azure リソースに対して標準を適用できます。 ただし、VM では、これらのメカニズムは制御プレーンまたは VM へのルートにのみ影響します。 VM で実行されるシステム イメージでも、セキュリティ上の脅威が発生します。 一部の企業は、開発者が VM にアクセスできないようにしています。 このアプローチでは機敏性が損なわれるため、DevOps プラクティスに従うのが難しくなります。
この記事では、Azure で実行される VM のコンプライアンスを管理するためのソリューションについて説明します。 このソリューションでは、コンプライアンスを追跡するだけでなく、VM 上で実行されるシステム イメージからのリスクを最小限に抑えることができます。 同時に、このソリューションは DevOps プラクティスと互換性があります。 コア コンポーネントには、Azure VM Image Builder、Azure Compute Gallery、Azure Policy が含まれます。
考えられるユース ケース
このソリューションは、次のタスクを実行する Azure ランディング ゾーンを持つ組織に適用されます。
- DevOps チームに "ゴールデン イメージ" を提供する。 ゴールデン イメージは、マーケットプレース イメージの公開されたバージョンです。
- DevOps チームが使用できるようにする前に、イメージをテストして検証する。
- 各 DevOps チームで使用するイメージを追跡する。
- 生産性を低下させることなく、会社の標準を適用する。
- DevOps チームで最新のイメージ バージョンが使用されていることを確認する。
- メンテナンス集中型の "ペット サーバー" や簡単に置き換えることができる "家畜サーバー" のコンプライアンスを管理する。
アプローチ
以下のセクションでは、ソリューションのアプローチの詳細について説明します。
ペットと家畜を識別する
DevOps チームでは、ペットと家畜と呼ばれる比喩を使用して、サービス モデルを定義します。 VM のコンプライアンス対応状態を追跡するには、まず、それがペット サーバーまたは家畜サーバーのいずれであるかを判別します。
ペットには細心の注意が必要となります。 それらは簡単に供給できません。 ペット サーバーを回復するには、かなりの時間と資金を投資する必要があります。 たとえば、SAP が実行されているサーバーは、ペットである可能性があります。 サーバーで実行されるソフトウェアだけでなく、その他の考慮事項によってサービス モデルが判別されることもあります。 フォールト トレランスが低い場合、リアルタイム システムやほぼリアルタイムのシステムの実稼働サーバーもペットであることがあります。
家畜サーバーは同じグループに属しています。 それらは簡単に置き換えることができます。 たとえば、仮想マシン スケール セットで実行される VM は家畜です。 セット内に十分な数の VM がある場合、システムは稼働し続け、各 VM の名前を把握する必要はありません。 次の条件を満たすテスト環境のサーバーは、家畜の別の例です。
- 自動化された手順を使用して、サーバーを最初から作成する。
- テストの実行が完了したら、サーバーの使用を停止する。
環境には、ペット サーバーだけを含めることも、家畜サーバーだけを含めることもできます。 これに対し、環境内の一連の VM がペットになることがあります。 同じ環境内の別の一連の VM が家畜であることがあります。
コンプライアンスを管理するには:
- ペットのコンプライアンスは、家畜のコンプライアンスよりも追跡するのが困難な場合があります。 通常、ペットの環境とサーバーのコンプライアンスを追跡して管理することができるのは、DevOps チームのみです。 ただし、この記事のソリューションでは、各ペットの状態の可視性が向上しているため、組織内のすべてのユーザーがコンプライアンスを追跡しやすくなります。
- 家畜環境の場合は、VM を更新し、定期的に最初から再構築します。 これらの手順は、コンプライアンスに適合している必要があります。 この更新サイクルを DevOps チームの通常のリリース周期に合わせることができます。
イメージを制限する
DevOps チームが Azure Marketplace の VM イメージを使用することを許可しないでください。 Compute Gallery によって公開される VM イメージのみを許可します。 この制限は、VM のコンプライアンスを確保するために不可欠です。 Azure Policy のカスタム ポリシーを使用すると、この制限を適用できます。 サンプルについては、イメージの公開元の許可を参照してください。
このソリューションの一部として、VM Image Builder で Azure Marketplace イメージを使用する必要があります。 Azure Marketplace で入手可能な最新のイメージを使用することが重要です。 そのイメージの上にカスタマイズを適用します。 Azure Marketplace のイメージは頻繁に更新され、各イメージには特定の事前設定された構成があり、イメージが既定でセキュリティで保護されます。
イメージをカスタマイズする
ゴールデン イメージは、Compute Gallery に公開されるマーケットプレース イメージのバージョンです。 ゴールデン イメージは DevOps チームが使用できます。 イメージを公開する前に、カスタマイズを行います。 カスタマイズのアクティビティは各企業に固有です。 一般的なアクティビティには、以下のものがあります。
- オペレーティング システムの強化。
- サード パーティ製ソフトウェア用のカスタム エージェントのデプロイ。
- エンタープライズ証明機関 (CA) ルート証明書のインストール。
VM Image Builder を使用してイメージをカスタマイズするには、オペレーティング システムの設定を調整し、カスタム スクリプトとコマンドを実行します。 VM Image Builder では、Windows と Linux のイメージがサポートされます。 イメージのカスタマイズの詳細については、「Azure Virtual Machines 用の Azure Policy 規制コンプライアンス コントロール」を参照してください。
イメージ タトゥーを追跡する
イメージ タトゥーは、VM で使用されるすべてのイメージのバージョン管理情報を追跡するプロセスです。 この情報は、トラブルシューティング時に非常に貴重であり、次のような情報が含まれます。
- イメージの元のソース (公開元の名前やバージョンなど)。
- オペレーティング システムのバージョン文字列。インプレース アップグレードを行う場合に必要となります。
- カスタム イメージのバージョン。
- 公開日。
追跡する情報の量と種類は、組織のコンプライアンス レベルによって異なります。
Windows VM のイメージ タトゥーの場合は、カスタム レジストリを設定します。 必要なすべての情報をこのレジストリ パスにキーと値のペアとして追加します。 Linux VM では、環境変数またはファイルにイメージ タトゥー データを入力します。 そのファイルを /etc/ フォルダーに配置します。このフォルダーは、開発者の作業やアプリケーションと競合しません。 Azure Policy を使用してタトゥー データまたはそれに関するレポートを追跡する場合は、データの各部分を一意のキーと値のペアとして格納します。 Marketplace イメージのバージョンを確認する方法については、Marketplace イメージ のバージョンを検索する方法に関する記事を参照してください。
自動テストを使用してゴールデン イメージを検証する
一般に、ゴールデン イメージは毎月更新して、Azure Marketplace イメージの最新の更新プログラムと変更が適用された状態にする必要があります。 このためには、繰り返しのテスト手順を使用します。 イメージ作成プロセスの一環として、テストに Azure パイプラインまたは他の自動化されたワークフローを使用します。 毎月の月初の前に、テスト実行用の新しい VM をデプロイするためのパイプラインを設定します。 このテストでは、公開して使用される前に、余分なものを削ぎ落としたイメージを確認する必要があります。 テスト自動化ソリューションを使用するか、VM でコマンドまたはバッチを実行することで、テストを自動化します。
一般的なテスト シナリオは次のとおりです。
- VM の起動時間を検証します。
- オペレーティング システムの構成設定やエージェントのデプロイなど、イメージのカスタマイズを確認します。
テストに失敗したら、プロセスが中断される必要があります。 問題の根本原因に対処した後に、テストを繰り返します。 テストが問題なく実行されたら、テスト プロセスを自動化すると、常に良好な状態に維持するための労力が削減されます。
ゴールデン イメージを公開する
DevOps チームが使用できるマネージド イメージとして、または仮想ハード ディスク (VHD) として、Compute Gallery で最終的なイメージを公開します。 以前のイメージを古いイメージとしてマークします。 Compute Gallery のイメージ バージョンの EOL 日付を設定していない場合は、最も古いイメージを廃止することができます。 この判断は会社のポリシーによって異なります。
Compute Gallery を使用する場合に適用される制限の詳細については、「Azure Compute Gallery でイメージを格納、共有する」を参照してください。
もう 1 つの良いプラクティスは、さまざまなリージョンに最新のイメージを公開することです。 Compute Gallery を使用すると、さまざまな Azure リージョンでのイメージのライフサイクルとレプリケーションを管理できます。
Compute Gallery の詳細については、「Azure Compute Gallery でイメージを格納、共有する」を参照してください。
ゴールデン イメージを更新する
アプリケーションにイメージを使用する場合、基になるオペレーティング システム イメージを最近のコンプライアンスの変更で更新することが難しい場合があります。 厳しいビジネス要件の場合、基になる VM を更新するプロセスが複雑になる可能性があります。 VM がビジネスにとって重要な場合は、更新も複雑です。
家畜サーバーは供給可能なので、DevOps チームと調整して、計画メンテナンス時間にこれらのサーバーを通常どおりの業務として更新できます。
ペット サーバーの更新はより困難です。 イメージを廃止すると、アプリケーションが危険にさらされる可能性があります。 スケールアウト シナリオでは、Azure で個別のイメージを見つけることができず、エラーが発生します。
ペット サーバーを更新する場合は、次のガイドラインを考慮してください。
ベスト プラクティスについては、Azure Well-Architected Framework の「信頼性の重要な要素の概要」を参照してください。
プロセスを効率化するには、次のドキュメントで説明されている原則を参照してください。
各ペット サーバーをペットとしてタグ付けします。 更新中にこのタグを考慮に入れるように、Azure Policy にポリシーを構成します。
可視性の向上
一般に、コントロール プレーンのコンプライアンス アクティビティを管理するには、Azure Policy を使用する必要があります。 また、Azure Policy は次の用途にも使用できます。
- VM のコンプライアンス対応の追跡。
- Azure エージェントのインストール。
- 診断ログのキャプチャ。
- VM のコンプライアンス対応に関する可視性の向上。
イメージのカスタマイズ中に行った構成の変更を監査するには、Azure Policy の Azure Automanage マシン構成機能を使用します。 ドリフトが発生すると、影響を受ける VM が Azure Policy ダッシュボードで非準拠として一覧表示されます。 Azure Policy では、イメージ タトゥーを使用して、古いイメージやオペレーティング システムがいつ使用されたかを追跡できます。
各アプリケーションのペット サーバーを監査します。 Azure のポリシーを監査効果と共に使用すると、これらのサーバーの可視性を向上させることができます。 会社のリスク許容度と内部リスク管理プロセスに従って、監査プロセスを調整します。
各 DevOps チームは、Azure Policy ダッシュボードでアプリケーションのコンプライアンス レベルを追跡し、適切な是正措置を実行できます。 これらのポリシーを管理グループまたはサブスクリプションに割り当てるときに、割り当ての説明に会社全体の Wiki にアクセスできる URL を指定します。 aka.ms/policy-21 のような短い URL を使用することもできます。 Wiki には、VM をコンプライアンス対応にするために DevOps チームが実行する必要がある手順を示します。
また、IT リスク マネージャーとセキュリティ責任者は、Azure Policy ダッシュボードを使用して、会社のリスク許容度に応じて会社のリスクを管理することもできます。
Azure Policy の Azure Automanage マシン構成機能を修復オプションと共に使用すると、是正措置を自動的に適用できます。 ただし、VM に頻繁に問い合わせを行う場合、またはビジネス クリティカルなアプリケーションに使用する VM に変更を加える場合は、パフォーマンスが低下する可能性があります。 実稼働ワークロードの修復アクションは慎重に計画してください。 すべての環境のアプリケーションのコンプライアンスの所有権を DevOps チームに与えます。 このアプローチは、ペット サーバーと環境 (通常は長期的な Azure コンポーネント) に不可欠です。
考慮事項
これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
スケーラビリティ
Compute Gallery に格納する各イメージのレプリカの数を構成できます。 レプリカの数が多いほど、複数の VM を同時にプロビジョニングする場合のスロットリングのリスクが最小限に抑えられます。 適切な数のレプリカのスケーリングと構成に関する一般的なガイダンスについては、Azure Compute Gallery のスケーリングに関する記事を参照してください。
回復性
このソリューションでは、リージョン レベルで自動的な回復性があるマネージド コンポーネントを使用します。 回復性に優れたソリューションの設計に関する一般的なガイダンスについては、回復性に優れた Azure 用アプリケーションの設計に関するページを参照してください。
コスト最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
Ansible や Terraform などのサードパーティのサービスを使用しない限り、このアプローチはほとんど無料です。 ストレージとエグレスのコストが適用される場合があります。 また、次のコンポーネントでは料金が発生することがあります。
Azure Policy と Azure Automanage マシン構成は、Azure リソースに対しては無料です。 会社でハイブリッド アプローチを使用する場合は、Azure Arc リソースに対して追加で課金されます。
パブリック プレビュー期間中、VM Image Builder では、1 vCPU と 3.5 GB の RAM を備える単一のコンピューティング インスタンスの種類が使用されます。 データの保存と転送に料金が適用される場合があります。
Compute Gallery では、以下を除き、料金は発生しません。
- レプリカの格納コスト。
- イメージをレプリケートするためのネットワーク エグレスの料金。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Yunus Emre Alpozen | プログラム アーキテクト
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
- Azure ランディング ゾーン
- Azure Policy を使用してリソースを制御および監査する
- Azure VM Image Builder
- Azure Compute Gallery
- Azure Policy とポリシー ダッシュボード
- Azure Automanage マシン構成