Azure Virtual Desktop のプラットフォーム自動化と DevOps に関する考慮事項
Azure Virtual Desktop は、デスクトップ仮想化環境用の Microsoft コントロール プレーンを提供するマネージド サービスです。
この記事では、Azure Virtual Desktop 環境を実行するために必要な運用タスクについて説明します。 この記事の各推奨事項は、個別に適用できます。 自動化が価値のあるものにするために、すべての推奨事項を実装する必要はありません。
設計上の考慮事項
Azure Virtual Desktop 環境の計画および設計時に、次の考慮事項を確認します。
DevOps との統合
自動化は DevOps との統合を必ずしも意味するわけではありませんが、統合には多くの利点があります。 ゴールデン イメージのビルド プロセスを自動化することは、複数の理由から投資する価値があります。
- DevOps パイプラインを使用すると、自動化フローをより適切に管理できます。
- DevOps パイプラインからデプロイに関するレポートとアラートを受け取ることができます。
- パイプラインを構成してテスト フレームワークと統合し、自動化プロセスのステージの承認ゲートを作成できます。
- パイプラインは、新しいギャラリー イメージのリリース、アプリケーション、設定されたスケジュールの使用など、多くの定義済みイベントから開始できます。
- ホスト プールの作成を自動化すると、新しい場所が利用可能になったときに、ホスト プールのメタデータを新しい地理的な場所に簡単に移動できます。
コードとしてのインフラストラクチャ
DevOps プラクティスを採用する前に、Azure リソースをデプロイするツールを選択する必要があります。 2 つの異なる IaC ツールのカテゴリがあります。 推奨されるオプションは、宣言型の IaC ツールです。
Azure には、ARM テンプレートと Azure Bicep を使用したネイティブ オプションが用意されています。
HashiCorp の Terraform など、サードパーティの IaC ツールもあります。
プールと個人用
組織が環境をスケールアウトした場合、ほとんどのワークロードは個人用構成ではなくプールされた構成に該当します。
多くの場合、個人用構成は、プールされた構成よりも実行コストが高くなります。 これらは通常、管理者特権のアクセス許可が必要な開発者などの特定のワークロード ユーザーに適しています。 パーソナル モードでホスト プールを実行する場合は、物理デスクトップを維持するようにマシンを維持して、環境内で必要なツールの量を減らしてください。
プールされた構成は、デスクトップ仮想化で最も一般的であるため、この記事の焦点です。 プールされた環境は、従来の環境とは異なる方法で更新する必要があります。 仮想マシン (VM) は、組織にとって適切な頻度でゴールド イメージから更新します（通常は 1 から 3 か月ごと）。 組織が高度に自動化されている場合は、必要に応じて週単位または夜間に頻度を増やすことができます。
イメージの作成
Azure Virtual Desktop 環境をスケールアップするときは、ゴールド イメージからホスト プールを作成します。これは、自動化されたプロセスを通じて作成するのが理想的です。
ビルド チェックリストを使用してスケールアップすることもできます。 大規模な環境がある場合、チェックリスト プロセスは開発/テストの初期セットアップの一部である必要があります。 ゴールド イメージの作成を自動化すればするほど、ビルドの精度と環境の安定性に自信を持つことができます。
既存のイメージを使用して、新しいアプリケーションと構成の変更で更新し、"新しい" ゴールド イメージとして使用するためにキャプチャする VM を作成することはお勧めしません。 このシナリオの維持には大きなリスクが伴い、デスクトップ仮想化環境が静的で脆弱になる主な要因です。
この記事の後半で説明する Packer プロセスを含め、ゴールド イメージを作成するために使用できる多くの自動化ツールがあります。 組織に最も適したツール セットを使用します。 選択したツールに関係なく、ゴールド イメージの作成を可能な限り自動化して、Azure Virtual Desktop 環境の正常性をより簡単に維持できるようにします。
アプリケーションのインストール
アプリケーションは、イメージにインストールするか、ユーザーごとに動的に配信するかの 2 つの方法によってユーザーが使用できるようになります。
イメージにインストールされるアプリケーションは、ユーザーと自動イメージ作成プロセスの一部に共通である必要があります。 イメージでインストールするアプリケーションには、セキュリティ製品や Microsoft 365 スイートを含めることができます。
ユーザーごとに動的に配信されるアプリケーションには、より柔軟なアプローチを必要とする他のすべてのものを含める必要があります。 動的に配信されるアプリケーションには、特定のグループに制限されたアプリケーションや他のアプリケーションと互換性のないアプリケーションを含めることができます。
言語のデプロイ
Azure Virtual Desktop 環境がスケールアウトしていくと、イメージをユーザーのネイティブ言語にローカライズする必要が生じる場合があります。 必要に応じてローカル言語から始めたり、ビルド時にイメージに言語を追加したりできます。 基本イメージを選択する場合は、次の要件を考慮してください。 たとえば事前に最適化された Windows 10 ギャラリー イメージ (Microsoft 365 有りまたは無し) は、米国英語 (en-US) でのみ提供されます。
Note
Windows 10 Enterprise マルチセッションを使用している場合、別の言語を使用してビルドすることはできません。 この場合は、提供されたギャラリー イメージを調整する必要があります。 既存の en-US ギャラリー イメージを調整するには、他のアプリケーションをインストールする前に追加の言語をインストールします。
デプロイの場所
Azure Virtual Desktop では、従来のデスクトップ環境よりもホスト プールの地理的配置について自由度が大きくなります。 この自由が存在する理由は、すべての Azure の場所で Azure Virtual Desktop がサポートされるからです。 ワイド エリア ネットワーク (WAN) をまたいでイメージから VM を作成しないようにするには、ユーザーと同じ場所でゴールド イメージを使用できるようにします。
ホスト プールのゴールド イメージの更新
特定のホスト プール内の VM の基になっているゴールド イメージを更新するには、2 つの方法があります。
方法 1:
- 2 つ目のホスト プールをデプロイし、準備ができたら新しいホスト プールにユーザーをカット オーバーします。
- ロールバックが必要な場合は、古いホスト プールを使用できます。
- 古いホスト プールは、新しいホスト プールが正しく動作していることを組織が確認した後に削除できます。
方法 2:
- ホスト プールで既存の VM をドレイン モードに設定します。
- 更新されたゴールド イメージから同じホスト プールに新しい VM をデプロイします。
- 1 つのホスト プール内の VM の数を 2 倍にするときに、リソースの制約や API 調整制限に達することがないよう注意してください。
設計の推奨事項
組織の Azure Virtual Desktop 環境を設計するときに、次の推奨事項を確認してください。
ソース コード管理
Git を使用してソース コードを管理し、単純な分岐戦略を維持することをお勧めします。環境に Git を使用する場合:
- 会社のポリシーでリポジトリがパブリックでなければならないと指定されていない限り、Git リポジトリおよび Azure DevOps プロジェクトは非公開にする必要があります。
- プロジェクトに関する情報の入力を開始できるように、README ファイルを使用してリポジトリを初期化します。
- 他のチーム メンバーにアクセスを許可するには、プロジェクトのアクセス許可を修正します。
- パイプラインを開発し、ワークロードを合理化し続ける基本的な作業項目プロセスを採用します。
- 少なくとも、ゴールド イメージ ビルドを管理するためのリポジトリと、Azure Virtual Desktop デプロイを管理するためのリポジトリという 2 つのリポジトリを維持する必要があります。
Pipelines
パイプライン デプロイ システムは、選択したソース コード管理システムによって決まります。
組織が Azure DevOps で標準化されている場合は、Azure Pipelines を使用します。 組織が GitHub で標準化されている場合は、GitHub Actions を使用します。 どちらのオプションも、ネットワーク内にセルフホステッド エージェントをデプロイする機能を提供します。これには、次のようないくつかの利点があります。
- ビルド時間が長い場合の許容量
- ネットワーク内のリソースにアクセスする機能
デプロイ パイプラインをゲートして、検証ホスト プールにデプロイするよう自動的にトリガーされるようにしますが、明示的な承認なしに運用ホスト プールに自動的にプッシュされることはありません。
変数と Azure Key Vault
Azure Pipelines で作業する際、変数グループを使用します。
- 変数グループを使用すると、シークレットやファイルの場所のような、パイプラインに反復可能なパラメーターを設定できます。
- 変数グループ内の変数はキーと値のペアとして保存できますが、推奨される方法は、デプロイ パイプラインで使用するシークレットをプルするため、Azure Key Vault に変数グループをリンクすることです。
Azure Virtual Desktop イメージの作成
Azure Image Builder (AIB) サービスを使用して、ゴールド イメージのビルド、更新、sysprep、配布プロセスを自動化します。 このサービスでは、各ビルドに Azure Marketplace からサポートされている基本イメージを使用して、最新の更新プログラムを確実に取得できます。
Note
Azure Image Builder は現在、リージョンの選択内で使用できますが、これらのリージョンの外部にイメージを配布できます。
ゴールド イメージ ビルド プロセスの一環として、インストールする必要があるすべてのアプリケーションを検討し、スクリプトを使用してインストールできるかどうかを判断します。 PowerShell でスクリプト化され、Git リポジトリにコミットされたアプリケーション インストール コマンドがあることを確認します。 パブリック インターネット経由でアプリケーション インストーラーをダウンロードできない場合は、アプリケーションを Azure Blob Storage に配置することを検討してください。 アプリケーションのインストール プロセスにシークレットが必要な場合は、それらを Azure Key Vault に配置することを検討してください。
Azure Image Builder の使用を開始するには、「Azure VM Image Builder と PowerShell を使用した Azure Virtual Desktop イメージの作成」を参照してください
CI/CD パイプラインを使用して Azure Image Builder を呼び出すには、Azure Pipelines の場合は Azure Image Builder サービスの DevOps タスクを、または GitHub Actions の場合は Azure 仮想マシン イメージ操作の作成 を使用します。
HashiCorp Packer は、オープンソースの代替手段です。 Azure Compute Gallery に配布する機能など、Azure Image Builder (HashiCorp Packer の上に構築) と同じ機能が提供されます。
Packer の詳細については、Packer の Web サイトを参照してください。
Packer メソッドには次の前提条件があります。
- Azure DevOps ライセンスは、Packer ツールの完全なスイートを使用する必要があります。
- Microsoft Entra ID で、ユーザーに適切なロールを割り当てる必要があります。
- サービス プリンシパルにサブスクリプションへの共同作成者アクセス権を付与する必要があります。
- シークレットを保存する Azure Key Vault を持つ必要があり、アクセス ポリシーでサービス プリンシパル シークレット管理を指定します。
デプロイ パイプラインで Packer を使用する場合は、次のようにします。
- デプロイ パイプラインで使用するビルド エージェントに Packer ツールをインストールします。
- パイプラインで検証ステージを作成すると、ビルドが動作することを検証できます。
- 検証後、検証ステージを複製し、デプロイモードを [増分] に設定します。
Packer ファイル ストレージに関するその他の考慮事項:
- Packer ファイルと規定を、Azure Pipelines からアクセスできる一元的な場所に保存します。 これらのファイルを安全に格納するには、Azure ファイル共有を使用することをお勧めします。
- Azure Files のアクセス資格情報を Key Vault に保存します。 パイプライン変数を使用して、ビルド時に Key Vault からアクセス資格情報をプルできます。
- さらに、Azure DevOps の変数グループにリンクされているキー コンテナーに Packer ファイルの名前とアカウント キーを保存します。 パイプラインはこれらの資格情報にアクセスし、イメージの作成に使用される VM に Packer ファイルをダウンロードします。
- UNC パスを変数として Azure DevOps 変数グループに保存します。
Azure Virtual Desktop イメージの保存
Azure Compute Gallery サービスは、ゴールデン イメージの構造と組織をビルドするための最も簡単な方法です。 次の機能を提供します。
- さまざまな Azure リージョンへのイメージのグローバル レプリケーション。
- Azure Virtual Desktop セッション ホスト (VM) のデプロイ先リージョンにイメージがデプロイされていることを確認します。
- 管理を容易にするイメージのバージョン管理とグループ化。 バージョン管理とグループ化は、Azure Virtual Desktop ホスト プールを以前のイメージ バージョンにロールバックする場合に役立ちます。
- Availability Zones がサポートされるリージョンでのゾーン冗長ストレージ (ZRS) アカウントによる高可用性イメージ。 ZRS では、ゾーンの障害に対する回復性の向上が提供されます。
- ロールベースのアクセス制御 (RBAC) を使用して、サブスクリプション間、および Microsoft Entra テナント間で Azure Virtual Desktop イメージを共有します。
- 各リージョン内のイメージ レプリカを使用したデプロイのスケーリング。
- 同時にデプロイする予定の 20 個の VM ごとに 1 つのレプリカのデプロイを計画します。
詳細については、Azure Compute Gallery サービスの概要に関するページを参照してください。
Azure Virtual Desktop イメージでのアプリケーションのインストール
- ゴールド イメージにインストールされているユニバーサル アプリケーションの場合は、この記事で前述した Packer メソッドを使用します。
- 現在、App-V が、ユーザーごとにアプリケーションをストリーミングするための Microsoft でサポートされている方法です。
- FSLogix アプリケーション マスクを使用して、アプリケーションが App-V でうまく動作しない場合に、それらのアプリケーションやプラグインを非表示にしたり、表示したりします。
- 可能な限り MSIX アプリのアタッチを使用して、ユーザーにアプリケーションを動的に配信し、ゴールド イメージの全体的なサイズを小さくします。 CI/CD パイプラインを使用して、アプリケーションを MSIX 形式にパッケージ化するプロセスを自動化することもできます。 詳細については、「概要」を参照してください。
Azure Virtual Desktop イメージでの言語のデプロイ
Microsoft では、言語パックを手動または自動でインストールするためのプロセスが用意されています。 管理オーバーヘッドをできるだけ少なくし、言語のインストールプロセスを自動化することをお勧めします。
プロセスには、イメージに変換される VM に PowerShell スクリプトをダウンロードすることが含まれます。 自動化スクリプトの例については、Microsoft のドキュメントを参照してください。 Packer パイプラインの推奨事項に従っている場合は、このプロセスを追加のビルド タスクとして含めることができます。
Windows 10 Enterprise マルチセッションに言語パックをインストールする方法の詳細については、Azure Virtual Desktop での Windows 10 VM への言語パックのインストールに関するページを参照してください。
Azure Compute Gallery イメージから Azure Virtual Desktop ホスト プールを作成する
Azure Virtual Desktop リソースのデプロイとカスタマイズに、コードとしてのインフラストラクチャ (IaC) アプローチを使用します。 デプロイの一貫性を確保するため、可能な場合は使用する必要があります。 ARM テンプレートを使用すると、CI/CD パイプライン タスクの一部として Azure Virtual Desktop リソースをデプロイできます。 また、Azure portal、Azure PowerShell、または Azure CLI を使用する場合にも使用できます。
推奨されるホスト プールの更新方法を次に示します。
- Azure Compute Gallery にゴールド イメージをビルドして配布するための CI/CD パイプラインを設定します。
- CI/CD パイプラインを使用して、検証ホスト プールを指定し、新しいセッション ホストを検証ホスト プールにデプロイします。
- 検証ホスト プールを使用して自動化をテストします。
- セッション ホストにビルド番号またはイメージ バージョンをタグ付けして、実行しているイメージのバージョンを識別します。
- デプロイする前に、サブスクリプション内に十分なコンピューティング クォータがあることを検証 (または確認) します。
- 検証プールでテストが成功したら、既存のセッション ホストをドレイン モードにします。タグ付けされた VM は簡単に識別できます。
- 新しいセッション ホストをデプロイし、ユーザーが接続できるようにします。
- 運用環境でのテストが成功したら、古いセッション ホストの割り当てを解除してコンピューティング料金が発生しないようにし、最終的に削除してマネージド ディスクの料金が発生しないようにします。
- 削除されたセッション ホストは、Azure からのみ削除されます。 コンピューター オブジェクトは AD に残るので、これらのコンピューター オブジェクトは手動またはスクリプトを使用して削除する必要があります。
上記の例では、Azure DevOps と継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインを使用したイメージの自動化の 1 つの方法を示しています。 これはクラウドネイティブのアプローチであり、ダウンタイムなしで新しいセッション ホストのより中断の少ないロールアウトを提供します。 古いイメージを段階的に除外し、新しいイメージをオンラインにするときに、仮想マシン数の急増を考慮する必要があることに注意をすることが重要です。
上記で説明したように、Azure Compute Gallery は、イメージを中心として構造や組織をビルドするのに役立つサービスです。 これらのイメージは、Azure Virtual Desktop セッション ホストの IaC デプロイで参照できます。 このサービスでは、イメージのバージョン管理、グループ化、レプリケーションを行うことができます。
ARM テンプレートまたは Terraform を使用してセッション ホストをデプロイする場合は、ギャラリーで作成したイメージのリソース ID を VM カスタム イメージ ソース ID として使用することをお勧めします。 使用しているイメージは、Azure Compute Gallery サービスを介して、Azure Virtual Desktop ホスト プールをデプロイしている Azure リージョンにレプリケートする必要があります。
次のステップ
エンタープライズ規模のシナリオにランディング ゾーン アクセラレータを使用して Azure Virtual Desktop をデプロイする方法について確認します。