Skip to content

MS_AzureQuickSetup

Jump to bottom
nishi_74322014 edited this page Aug 19, 2026 · 1 revision

Azure上に素早く環境を構築する

概要

Azure 上に素早く環境を構築する系のトピックを列挙。

  • VHD を退避して（ディスク）、VM 作成に使用する的な。
  • Sysprepによる iso（イメージ）作成も可能。

補足（本ページを貫く「イメージ」と「ディスク」の対比）: 本ページは
全体を通じて2 つの方式を対比している。混同しやすいので先に整理する。

イメージ（マイ・イメージ） ディスク（マイ・ディスク）
元になるもの Sysprep 済みの VM 稼働していた VM そのまま
呼び方 汎用化（generalized） 特殊化（specialized）
コンピュータ名・SID 展開時に再生成される 元のまま
用途 同じ構成を N 台量産する 1 台を退避・復元・移設する
例えるなら 金型 バックアップ

つまり、

  • 「10 台同じ開発環境を配る」 → イメージ
  • 「この VM を別サブスクリプションへ移す」「壊す前に取っておく」 → ディスク

判断を誤ると、同じ SID・同じコンピュータ名の VM が
ドメインに複数参加するといった事故になる
（Sysprep が必要な理由がこれである）。

ギャラリー

  • Microsoft Azure に用意されたギャラリーから OS イメージを選択して作成できる。
    • 新規作成した仮想マシンには新しい NIC が取付けられ、MAC アドレス、TCP/IP 設定は引継がれない。
    • このため、ネットワーク関連の設定は、新規仮想マシンの作成後に設定を行う。
  • 参考

既定のOSイメージ

既定の OS イメージには、Windows や Linux などの OS が用意されている。

  • この既定の OS イメージをコピーして、新しい仮想マシンを作成することで、
    OS インストールの時間をかけずに、迅速に仮想マシンを作成できる。
  • ただし、用意されている既定の OS イメージは、すべて英語版。

利用時の動作

  • Azure 仮想マシンを新規作成する際に、ギャラリーから既定の OS イメージを選択する。
  • 利用者の Azure 環境（具体的には利用者の Azure Storage の BLOB）へコピーされる。
  • 仮想マシンのシステム ドライブに取り付けられ、仮想マシンが起動する。

問題点

  • 既定の OS イメージは、すべて英語版。
    • 日本語環境の手順やメッセージを確認するためには、日本語化する必要がある。
    • 日本語化の作業に 1〜2 時間かかるため、必要な都度、日本語化していては効率が悪い。
  • 既定の OS イメージは、時々 Windows Update が当てられ更新される。
    • 例えば半年経過した頃に、同じ OS イメージから仮想マシンを再度作成した場合、
      Windows Update が当てられ更新されている可能性がある。
    • 更新モジュールを固定することができない。

補足（最新化：日本語版イメージは提供されている）: 「すべて英語版」という
記述は当時のもので、現在は Marketplace に
日本語版の Windows Server イメージ
（例: "Windows Server 2022 Datacenter - Japanese"）が提供されている。
言語パックの適用に 1〜2 時間かける必要は無くなった。

なお、「更新モジュールを固定できない」という指摘は
今も有効である。ギャラリーのイメージは随時更新されるため、
再現性が要る場合はマイ・イメージ（後述）で固定するか、
イメージのバージョンを明示指定する必要がある。

# 特定バージョンを指定する例
az vm create ... --image MicrosoftWindowsServer:WindowsServer:2022-datacenter-azure-edition:20348.2402.240607

# 利用可能なバージョンの一覧
az vm image list --publisher MicrosoftWindowsServer --offer WindowsServer --all --output table

latest を指定すると、実行時期によって中身が変わる。
IaC で環境を再現したい場合、これはバージョン固定漏れと同じ問題になる。

マイ・イメージ

  • テンプレートになる自作の OS イメージを予めマイ・イメージとして登録
  • テンプレートから多数の仮想マシンを作成する場合に適している。

機能概要

  • 予め、OS イメージ化対象の VM を Azure IaaS 上に構築しておく必要がある。
  • OS イメージを利用者の Azure 環境（具体的には利用者の Azure Storage の BLOB）へコピー
  • Sysprep済の OS イメージを登録することもできるので、
    Sysprep 対応のアプリケーションをインストールした状態での展開が可能。
  • ギャラリーの既定の OS イメージと異なり、Windows Update が適用されない。

用途

後から再利用しそうな OS イメージについて、
あらかじめ日本語化し、マイ・イメージにキープしておくとよい。

補足（最新化：Azure Compute Gallery）: 「マイ・イメージ」（Managed Image）は
現在も使えるが、Azure Compute Gallery（旧 Shared Image Gallery）が
後継として推奨されている。違いは次のとおり。

マイ・イメージ Azure Compute Gallery
バージョン管理 無い（別イメージとして作り直す） ある（1.0.0, 1.0.1…）
複数リージョンへの複製 手動 自動レプリケーション
スケール 同時展開数に限界 大量展開に対応（レプリカ数を指定）
共有 サブスクリプション内 サブスクリプション／テナントを越えて共有可

本文が別項で扱っている
「サブスクリプション間でマイ・イメージを移動」という手間は、
Compute Gallery を使えば共有設定だけで済む。

さらに、イメージの作成自体を自動化する
Azure VM Image Builder（Packer ベース）もあり、
「元 VM を手で作って Sysprep して取り込む」という
手作業を無くせる（クラウド・インフラ自動化）。

ストレージ

既定のディスク

そんなものはない

マイ・ディスク

機能概要

  • ギャラリー上の OS イメージではなく既存 VM の VHD を、新 VM にアタッチする。
  • この、既存 VM の VHD を、「特殊化された VHD」と言う。
  • なお、NIC などのコンフィグはリセットされるので、そこはイメージと変わらない。

移行メモ（体裁）: 原典の「既存VMのVHDをを、」は
「を」が重複していたため修正した。

用途

  • 既存 VM の VHD を（個人 PC、業務 PC、業務サーバ等）のバックアップ・リストアなど。
  • 若しくは、既存 VM をサブスクリプション間で移動する場合など。
  • スナップ・ショットを使用して、ベース・イメージとすることもできる。

移行メモ（体裁）: 原典の「-若しくは、-既存VMを」は
箇条書き記号が重複していたため整理した。

手順

マイ・イメージ

シェルでマイ・イメージを作成

サブスクリプション間でマイ・イメージを移動

...

マイ・ディスク

ポータルでスナップショットして別VMを作成

  • 管理ディスクをコピーする
    管理ディスクからスナップショットを作成し、
    そのスナップショットから管理ディスクを作成。
    • 管理ディスクを選択し上のメニューから［スナップショットの作成］を選択。
      • ［名前］を入力、［リソース グループ］を選択。
      • ［スナップショットの種類］で［フル］を選択。
      • ［アカウントの種類］で［Standard (HDD)］を選択。
      • ［作成］を選択してスナップショットを作成。
    • ［リソースの作成］か、［すべてのリソース］から［追加］を選択し、
      検索窓に「Managed Disks」と入力し、表示された管理ディスクの［作成］を押下
      • ［名前］を入力、［リソース グループ］を選択。
      • ［ソースの種類］で、［スナップショット］を選択。
      • それ以外は、コピー元の管理ディスクに合わせる。
      • ［作成］を選択して管理ディスクを作成。
  • 管理ディスクからの VM 作成
    管理ディスクが作成されたら、ポータルを使用して VM を作成できる。
    • 使用する管理ディスクを選択し［概要］ページで、
      ［DISK STATE］（ディスクの状態）が［未接続］であることを確認。
    • ページの一番上にあるメニューで、［VM の作成］を選択。
    • VM サイズ等を選択して、［確認および作成］を選択。
      その他は既定値の状態（管理ディスクは作成済みのため）
    • VM 構成が検証に合格したら、［作成］を選択してデプロイを開始。
  • 作成した VM の起動と実行の確認
    作成した VM が、起動し、RDP などで接続できることを確認する。

補足（［未接続］の確認が要点）: 手順中の
「［DISK STATE］が［未接続］であることを確認」は読み飛ばしやすいが、
管理ディスクは同時に 1 台の VM にしか接続できないため必須の確認である
（共有ディスクを有効にした場合を除く）。

元の VM が動いたままだと、そのディスクは Attached のままで
新 VM の作成に使えない。
スナップショットから新しい管理ディスクを作るという
本手順の遠回りに見える段取りは、

  • 元 VM を止めずに済む（スナップショットは稼働中でも取れる）、
  • コピーなので元ディスクに影響しない

という 2 点を満たすためのものである。

なお、スナップショットの種類で
**［フル］**を選んでいる点にも意味がある。

種類 内容
フル 完全なコピー。単独で復元でき、元を消しても残る
増分 前回からの差分のみ。安価だが元ディスクと同一リージョンに依存

「別 VM を作る」目的ではフルが扱いやすい。

サブスクリプション間でマイ・ディスクを移動

  • 一方のサブスクリプションから、
    招待＆共同管理者に設定（Azure Subscriptionの管理手順@エンプラ）してもらう。

  • Azure CLIでログイン

    az login

  • SASトークンを取得。
    オプションに --subscription の指定が必要になることがある。
    名称が重複しているなどの場合、サブスクリプションを識別できない模様

    az disk grant-access --duration-in-seconds 3600 --name <ディスク名> --resource-group <リソースグループ名>
{
  "accessSas": "accessSas の URL"
}

  • サブスクリプション間コピー

    • コピー先ストレージ・アカウント、コンテナは予め作成しておく。
    • なお、パブリック・ネットワークからのアクセスを許可しておく必要がある。
    • 同様に、--subscription の指定が必要になることがある。
    az storage blob copy start --account-name <コピー先ストレージ アカウント名> --account-key <コピー先ストレージのアクセス キー> --destination-container <コピー先のコンテナー名> --destination-blob <コピー後の VHD 名>.vhd --source-uri "生成した accessSas の URL"

  • コピー状況の確認

    • 何気に、結構長い時間がかかる（リージョンを跨ぐ等）。

    • ステータス取得には、PowerShell が必要なので、
      Azure Cloud Shell 辺りを使用して以下のように行う。

      $storageContext = New-AzureStorageContext -StorageAccountName 'aaaa' -StorageAccountKey 'bbbb'
Get-AzureStorageBlobCopyState -Context $storageContext -Container "xxxx" -Blob "yyyy"

    • ...と思ったら、コピー先のポータルから操作すれば確認できるもよう。
      進捗は確認できないが、最終更新日付、コピー状態、完了時間で完了しているかどうか解る。

    ※ Status : Pending のまま、BytesCopied が TotalBytes まで増えていく。

補足（この手順が長い理由と、現在の近道）: 「SAS トークンを発行して
BLOB としてコピーする」という段取りが必要なのは、
管理ディスクは直接 URL でアクセスできない（マネージド リソースである）ためで、
grant-access で一時的に読み取り用の SAS URL を露出させている。

現在は、より簡単な手段がいくつかある。

手段 内容
az disk copy（拡張機能） ディスクのリージョン／サブスクリプション間コピーを 1 コマンドで
AzCopy az storage blob copy より格段に速い。大容量 VHD ではこちらを推奨
Azure Compute Gallery イメージなら共有設定だけで他サブスクリプションから使える
リソースの移動 同一テナント内ならディスクごと移動できる（後掲の参考）

なお、コマンド例の New-AzureStorageContext / Get-AzureStorageBlobCopyState は
旧 AzureRM モジュールのもので、現在は Az モジュールの
New-AzStorageContext / Get-AzStorageBlobCopyState を使う
（Azure PowerShell）。

また、--account-key をコマンドラインに書くのは
履歴に残るため望ましくない。
可能なら --auth-mode login（Microsoft Entra ID 認証）を使う。

ページBlobのVHDから復元する。

※ VHD は、Hyper-Vを使用し、1MB * N のサイズの VHD として作成しておく。
　（後々、リサイズ等をしたら、動かなくなることがあったので。127GB が良いのか？）

  • ページ Blob の VHD より管理ディスクを作成

    • VHD のフル URL は、SASトークンではないので注意。
    • 作成元の管理ディスクに合わせて以下を設定
      • --hyper-v-generation "V1 or V2"
      • --sku "Premium_LRS or StandardSSD_LRS or Standard_LRS or UltraSSD_LRS"
    • 私の場合、--subscription と --location の指定が必要だった。
      • location に指定する値は、az account list-locationsで出力。
      • ただし、Docs などの HP の方が見易い。--output table を付けるとマシになる。
    az disk create --resource-group <リソース グループ名> --name <作成する管理ディスク名> --source <VHD のフル URL> --sku "Premium_LRS or StandardSSD_LRS or Standard_LRS or UltraSSD_LRS" --hyper-v-generation "V1 or V2"

  • 管理ディスクより VM を作成

    • ポータルから実行しようとしたら、
      VM 作成ボタンが非活性だったため CLI で実行。
    • ここでも、念の為、--subscription と --location を指定。
    • インバウンドを開けない場合は「--public-ip-address ""」を指定。
    • VM のサイズは、--size に指定するが、
      • 指定する値は、az vm list-sizesで出力。
      • ただし、Docs などの HP の方が見易い。--output table を付けるとマシになる。
      • また、サイズによっては、Premium_LRS をサポートしていないことがある。
    az vm create --name <VM 名> --resource-group <リソース グループ名> --attach-os-disk <管理ディスク名> --size "VM のサイズ" --os-type "Windows or Linux"

  • 起動しない場合は、ブート診断

    • 私の場合、ココまでやって、始め OS が起動せず（以下の切り分けでクリアした）。

    • ポータルからスナップショットをソースにして、作成した管理ディスクに、
      「az vm create」コマンドを実行した場合は上手く動作した。

    • ポータルから BLOB をソースにして、作成した管理ディスクに、
      「az vm create」コマンドを実行した所、同様に上手く動作した。

      ...ポータルには、「Gen2」と指定する部位があったため、
      CLI の「az disk create」でも「Gen2」を指定する必要があるものと思われる。

    • 参考

補足（この節の教訓は「Gen1/Gen2 の取り違え」）: 末尾の推測
「az disk create でも Gen2 を指定する必要があるものと思われる」は
正しい。--hyper-v-generation の既定値は V1 であり、
Gen2（UEFI ブート）の VHD を V1 として取り込むと、

  • ブート方式が BIOS になるため UEFI パーティションを読めず、
  • 結果として起動しない（画面に何も出ない）

という症状になる。まさに本文の「始め OS が起動せず」である。

切り分けの要点をまとめておく。

症状 疑うもの
ブート診断のスクリーンショットが真っ黒／何も出ない Gen の不一致、ブート パーティション破損
OS のロゴは出るが進まない ドライバ、ディスク署名の衝突
INACCESSIBLE_BOOT_DEVICE ストレージ コントローラ ドライバ
ログイン画面までは来るが RDP できない NSG、RDP サービス、ファイアウォール

ブート診断は最初に有効化しておくこと
（Azureの評価環境を入手するの構成例でも「オン」になっている）。
スクリーンショットとシリアル コンソールが使えるかどうかで、
切り分けの手数がまったく変わる。

また、冒頭の「1MB * N のサイズの VHD として作成しておく」も重要である。
Azure のページ BLOB は 1MiB の倍数である必要があり、
端数があるとアップロード時に弾かれる。
ツールでリサイズすると端数が出ることがあるため、
**固定サイズ VHD（VHDX ではなく VHD）**で作るのが安全である。

参考

Azureの評価環境を入手する

VM起動後の開発環境のセットアップ

クラウド・インフラ自動化

Microsoft Docs

マイ・イメージ

マイ・ディスク

リソースの移動

補足（移動は「できるもの」と「できないもの」がある）: リソースの移動には
サービスごとに可否があり、移動できないものが少なくない。

例 可否
管理ディスク、スナップショット、VM 概ね可（条件あり）
パブリック IP（Standard SKU） 不可（Basic は可）
Azure Bastion 不可
VNET 可（ただし依存リソースを全て一緒に動かす必要がある）

したがって、実務では

  • 移動より、IaC で作り直す方が早いことが多い、
  • 移動中は対象リソース グループがロックされる（他の操作ができない）

という前提で計画するとよい。
ここでも、クラウド・インフラ自動化の
「再現可能にしておく」という方針が効いてくる。

Tags: 移行, インフラストラクチャ, クラウド, Azure

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally