Azure Stack HCI 検証環境を PowerShell で半自動化する

この記事の内容

• Azure Stack HCI の検証環境を何度でも作り直せるように PowerShell スクリプトで半自動化した取り組みを紹介します
• Microsoft 公式の評価ガイドに掲載されているサンプルスクリプトをベースに、自分の環境向けにカスタマイズする方法を解説します
• Hyper-V 上に VM を作成し、OS インストール後の初期設定からドメイン参加・Hyper-V 有効化まで自動化するフローを紹介します
• 「作って壊して作って」を繰り返す検証作業こそ自動化が効いてくる、という考え方を共有します
• 本番環境の展開でも同様のアプローチが応用できることを解説します

背景：検証が失敗して環境が壊れた

Azure Stack HCI の検証を試みたところ、うまくいかずに環境を壊してしまいました。これから同じ作業を何度も繰り返すことが予想されたため、「作って壊して作って」のサイクルをできる限り自動化しようと考えた、というのが今回の取り組みのきっかけです。

Microsoft 公式の評価ガイドを活用する

まず参考にしたのは、Microsoft が公開している Azure Stack HCI の評価ガイドです。このガイドには以下のような内容が含まれており、非常に充実しています。

• 無償での試用方法や構築手順の説明
• 各種設定を自動化する PowerShell スクリプトのサンプル
• ネットワーク構成の設定手順
• ドメインコントローラーの作成手順

サンプルスクリプトは幅広い用途をカバーしていますが、今回は自分の環境に合わせてカスタマイズする必要がありました。

今回の構成と前提環境

検証に使用しているサーバーは、HPE ProLiant SE350 を評価機として借用しているものです。この物理サーバーを固定のベースとして使い続け、その上に Azure Stack HCI をインストールする VM を Hyper-V で作成する構成です。

自動化の対象範囲は以下の通りです。

• Hyper-V 上への VM の作成
• VM に対する OS（Azure Stack HCI）のインストール準備
• OS インストール後の初期設定からドメイン参加まで
• Hyper-V フィーチャーの有効化

OS インストール自体は手動で行う部分として残してあります。完全自動化するにはさらに仕込みが必要になるため、ここは現状手動としています。

自動化スクリプトの流れ

1. 既存 VM の削除

スクリプトを実行すると、まず既存の VM を停止して削除します。「何度でも作り直せる」ことが目的なので、既存の VM が動いていても問答無用で削除する設計です。

# 既存 VM を停止・削除するイメージ（スクリプト全体は後日公開予定）
Stop-VM -Name "AzureStackHCI-Node1" -Force
Remove-VM -Name "AzureStackHCI-Node1" -Force

2. VM の新規作成

削除後、新しい VM を作成します。主な設定は以下の通りです。

• プロセッサ数の設定
• データディスクの作成
• ISO イメージ（Azure Stack HCI の OS イメージ）のマウント
• VM の起動

ディスクやイメージのパスは環境に合わせてカスタマイズしています。たとえば C: ドライブではなく D: ドライブに配置する、2 台構成にするといった変更を加えています。

3. OS インストール（手動）

VM が起動したら、マウントした ISO イメージから Azure Stack HCI の OS をインストールします。この部分は手動での作業です。

インストール完了後、初回ログイン時にパスワードの設定が求められます。パスワードを設定すると、次のスクリプトフェーズへ進む準備が整います。

4. OS インストール後の自動設定

OS のインストールとパスワード設定が終わったら、スクリプトが自動的に以下の処理を順番に実行します。

# スクリプトの処理フロー（概要）
# 1. ローカル管理者の認証情報で VM に接続
# 2. コンピューター名の変更
# 3. ドメインへの参加（ドメイン管理者認証情報を使用）
# 4. 再起動
# 5. オンライン復帰の確認（VM が応答するまで待機）
# 6. Hyper-V フィーチャーの有効化
# 7. 再起動

スクリプトは VM がオンラインになるまで待機し、オンラインを検知してから次の処理へ進む設計になっています。OS が起動してから IP に到達できるようになるまで少し時間がかかるため、この待機処理が重要です。

5. 2 台目の VM も同様に処理

1 台目の処理が完了すると、自動的に 2 台目の VM に対しても同じフローが実行されます。2 台ともクラスター構成の前提条件（Hyper-V 有効化、ドメイン参加、コンピューター名設定）が整った状態になります。

カスタマイズしたポイント

公式サンプルスクリプトをそのまま使うのではなく、以下のような点を自分の環境向けにカスタマイズしました。

自動化のメリット

今回のような半自動化を行うことで、以下のメリットが得られます。

時間の節約：スクリプトを実行したらあとはほっておけます。OS インストールの手動作業が終われば、その後は人間が操作しなくても設定が進んでいきます。

再現性の確保：毎回同じ手順で同じ状態の環境が作れます。「前回の環境と今回の環境で設定が違う」というミスがなくなります。

本番環境への応用：検証環境に限らず、前提条件が決まっている本番環境の展開にも同じアプローチが使えます。Azure Stack HCI のようにアップグレードもボタン一つでできる環境では、展開作業の標準化・自動化は特に効果的です。

Hyper-V 環境での自動化における注意点

物理サーバー上の Hyper-V をベースにした構成では、以下のような固有の依存関係が生じます。

• IP アドレスの割り当て
• 仮想スイッチの名前

これらはホスト環境に依存するため、スクリプトを別の環境に持ち込む際には修正が必要です。ただし、VM の内側の世界（コンピューター名、ドメイン参加、フィーチャー設定など）は環境に依存しないため、その部分のスクリプトは再利用が可能です。

クラウド環境（Azure）では、すべてが API 経由で制御できるためさらに自動化しやすい状況です。Hyper-V の場合はオープンソースのプロビジョニングツールのサポートがまだ発展途上なこともあり、現状では PowerShell で書くのが一番手早いという判断になりました。

まとめ

今回は Azure Stack HCI の検証環境を PowerShell スクリプトで半自動化した取り組みを紹介しました。

• Microsoft 公式の評価ガイドには豊富なサンプルスクリプトが用意されており、これをベースにカスタマイズするのが効率的です
• VM の作成・削除・OS インストール準備から、ドメイン参加・Hyper-V 有効化まで一連の流れを自動化できます
• OS インストール自体は手動が残りますが、それ以外の設定作業はほぼノータッチで完了します
• 「何度も繰り返す作業こそ自動化する」という考え方は、検証環境だけでなく本番環境の展開にもそのまま応用できます

小さなところから自動化を積み上げていくことで、インフラ構築の品質と速度を着実に向上させることができます。Hyper-V や物理サーバーを使ってオンプレミス環境で Azure Stack HCI の検証をしている方には、ぜひこのアプローチを参考にしていただければと思います。