Azureを触り始めたLinuxエンジニアがよく感じる疑問です。VM間でデータを共有したい、バックアップを保存したい、大量のログをまとめておきたい——それぞれの用途によって使うべきストレージが違います。
この記事では、AzureのBlob StorageとManaged Diskの2つに絞って、Linuxから実際に操作する手順を解説します。azコマンド(Azure CLI)を使ったBlobのアップロード・ダウンロードと一覧確認、Managed DiskのアタッチからXFSフォーマット・UUIDを使ったfstab永続マウント設定、さらにVMを止めずにディスクをオンライン拡張する手順まで、実機の出力例つきで紹介します。
この記事のポイント
・Blob StorageはAWS S3相当のオブジェクト保存、Managed DiskはEBS相当のブロックストレージ
・az storage blob upload/download でLinuxから直接Blobを操作できる
・Managed DiskはazコマンドでVMにアタッチしてXFSフォーマット・UUIDでfstab永続マウントする
・az disk update + growpart + xfs_growfsでVMを停止せずオンラインでディスクを拡張できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
AzureストレージはBlob Storage、Managed Disk、Files の3種類が基本
AzureのストレージはAWS S3やEBSに相当するものが、それぞれ別の名前で提供されています。まずこの3種類の使い分けを頭に入れておくと、後の操作が迷いなく進みます。・Blob Storage(オブジェクトストレージ):ファイルや画像、ログ、バックアップなどのファイルをオブジェクトとして保存する。AWSのS3に相当。
・Managed Disk(ブロックストレージ):VM専用の仮想ディスク。AWSのEBSに相当。VMにアタッチしてOSまたはデータディスクとして使う。
・Azure Files(ファイルストレージ):SMBプロトコルで複数VMから同時にマウントできる共有ストレージ。AWSのEFSに相当。
AWSを使い慣れたエンジニアには、次の対応表が全体把握の早道になります。
| AWS | Azure | 役割 |
|---|---|---|
| S3(Simple Storage Service) | Blob Storage | ファイル・画像・ログ・バックアップのオブジェクト保存 |
| EBS(Elastic Block Store) | Managed Disk | VM専用ブロックストレージ(OSディスク・データディスク) |
| EFS(Elastic File System) | Azure Files | 複数VMから同時にマウントできる共有ストレージ |
| (AWSアカウント単位) | ストレージアカウント | Blob/Filesを格納する親リソース。Azureのみに存在する概念 |
この記事ではLinuxエンジニアが最も頻繁に扱うBlobとManaged Diskを取り上げます。
Azure CLI(az コマンド)の準備とストレージアカウント作成
1. Azure CLIのインストール
RHEL/Rocky Linux系とUbuntu系のそれぞれにインストール手順があります。ここではRPMパッケージとaptパッケージの両方を紹介します。RHEL 9.x / Rocky Linux 9.x の場合:
# Microsoftのリポジトリを追加してインストール sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc sudo dnf install -y https://packages.microsoft.com/config/rhel/9.0/packages-microsoft-prod.rpm sudo dnf install -y azure-cli # バージョン確認 az --version
# Microsoftの署名キーとリポジトリを追加 curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash # バージョン確認 az --version
$ az --version azure-cli 2.61.0 core 2.61.0 telemetry 1.1.0 Python location '/opt/microsoft/azure-cli/bin/python3' Extensions directory '/home/azureuser/.azure/cliExtensions' Python (Linux) 3.11.9 (main, Apr 2 2024, 08:25:16) [GCC 11.4.1 20231218 (Red Hat 11.4.1-3)]
2. az login でAzureにサインイン
az login
--use-device-code を使うとデバイスコードでのサインインができます。# ブラウザが使えないサーバーでのログイン az login --use-device-code # → To sign in, use a web browser to open the page https://microsoft.com/devicelogin # and enter the code XXXXXXXX to authenticate.
3. ストレージアカウントの作成
Blob StorageはAzureの「ストレージアカウント」の配下に作成します。まずリソースグループとストレージアカウントを用意します。# リソースグループの作成(Japan Eastリージョン) az group create \ --name myStorageRG \ --location japaneast # ストレージアカウントの作成 # 名前は英小文字+数字のみ、3~24文字、グローバルで一意である必要がある az storage account create \ --name mystorageaccount20260701 \ --resource-group myStorageRG \ --location japaneast \ --sku Standard_LRS \ --kind StorageV2 \ --access-tier Hot
| SKU名 | 冗長化 | 特徴 |
|---|---|---|
| Standard_LRS | ローカル冗長(同一DC内3コピー) | 最安。開発・テスト向け |
| Standard_ZRS | ゾーン冗長(同一リージョンの3AZ) | AZ障害に耐性あり。本番推奨 |
| Standard_GRS | 地理冗長(別リージョンへ非同期コピー) | リージョン障害に対応。ミッションクリティカル向け |
| Standard_GZRS | 地理ゾーン冗長(ZRS+GRS) | 最高レベルの可用性。コスト高め |
・Hot アクセス層:頻繁にアクセスするファイル向け(ストレージ単価高め・転送単価低め)。
・Cool アクセス層:アクセス頻度の低いログや長期バックアップ向け(ストレージ単価低め・転送単価高め)。30日以上保存が前提。
Blob StorageをLinuxから操作する(az storage blob)
1. コンテナの作成
Blob Storageのファイルは「コンテナ」という単位でまとめて管理します。S3のバケットに相当するものです。# アカウントキーを変数に取得(コマンドを短くするため) export AZURE_STORAGE_ACCOUNT=mystorageaccount20260701 export AZURE_STORAGE_KEY=$(az storage account keys list \ --account-name mystorageaccount20260701 \ --resource-group myStorageRG \ --query '[0].value' -o tsv) # コンテナの作成(パブリックアクセスなし) az storage container create \ --name mycontainer \ --public-access off
{ "created": true }
--public-access の設定は3段階あります。・off:プライベート。認証済みリクエストのみ許可(推奨デフォルト)
・blob:BlobのURLを知っていれば匿名で読み取り可能
・container:コンテナ内の一覧表示も可能(本番環境では使わない)
特別な理由がない限り
--public-access off で作成し、外部共有が必要な場合はSASトークン(後述)を使うのが安全です。2. ファイルのアップロード(upload)
# 単体ファイルのアップロード az storage blob upload \ --container-name mycontainer \ --file /var/log/messages \ --name logs/messages-2026-07-01.log # ディレクトリごと一括アップロード(--pattern でワイルドカード指定可) az storage blob upload-batch \ --source /var/log/ \ --destination mycontainer/logs \ --pattern "*.log"
{ "etag": "\"0x8DC9A1B2C3D4E5F6\"", "lastModified": "2026-07-01T09:30:00+00:00" }
3. ファイルの一覧確認(list)
# コンテナ内のBlob一覧を表示 az storage blob list \ --container-name mycontainer \ --output table # プレフィックスで絞り込み(logsフォルダ以下のみ) az storage blob list \ --container-name mycontainer \ --prefix "logs/" \ --output table
Name Blob Type Blob Tier Length Content Type Last Modified -------------------------------- ----------- ----------- -------- ------------------------ ------------------------- logs/messages-2026-07-01.log BlockBlob Hot 185432 application/octet-stream 2026-07-01T09:30:00+00:00 logs/secure-2026-07-01.log BlockBlob Hot 12089 application/octet-stream 2026-07-01T09:31:05+00:00
4. ファイルのダウンロード(download)
# 単体ファイルのダウンロード az storage blob download \ --container-name mycontainer \ --name logs/messages-2026-07-01.log \ --file /tmp/messages-restored.log # バッチダウンロード(コンテナのlogsフォルダを丸ごとローカルへ) az storage blob download-batch \ --source mycontainer \ --destination /tmp/blob-restore/ \ --pattern "logs/*"
{ "deleted": false, "metadata": {}, "name": "logs/messages-2026-07-01.log", "properties": { "blobType": "BlockBlob", "contentLength": 185432 } }
5. SAS URLでの一時公開(期限付きURL)
Blobをパブリック公開せず、期限付きで外部から参照できるようにするには、SAS(Shared Access Signature)URLを使います。AWSのPresigned URLに相当する機能で、URLを知っている人だけが指定した期間だけアクセスできます。# 1時間だけ有効なダウンロードURL(読み取り権限のみ)を生成 # --expiry には UTC時刻を ISO8601 形式で指定する EXPIRY=$(date -u -d '+1 hour' '+%Y-%m-%dT%H:%MZ') az storage blob generate-sas \ --container-name mycontainer \ --name logs/messages-2026-07-01.log \ --permissions r \ --expiry $EXPIRY \ --full-uri \ --output tsv
https://mystorageaccount20260701.blob.core.windows.net/mycontainer/logs/messages-2026-07-01.log?se=2026-07-01T10%3A30Z&sp=r&sv=2022-11-02&sr=b&sig=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
SASの
--permissions には複数の権限を組み合わせて指定できます。・r:読み取り(read)
・w:書き込み(write)
・d:削除(delete)
・l:一覧(list)
6. RBACによるアクセス権の設定
SASが一時的なURL共有であるのに対し、長期的かつ恒久的なアクセス権を管理するにはRBAC(ロールベースのアクセス制御)を使います。AWSのIAMに相当する機能です。# ユーザーにBlob読み取りロールを割り当て(コンテナ単位) az role assignment create \ --assignee "user@example.com" \ --role "Storage Blob Data Reader" \ --scope "/subscriptions/<サブスクリプションID>/resourceGroups/myStorageRG/providers/Microsoft.Storage/storageAccounts/mystorageaccount20260701/blobServices/default/containers/mycontainer" # 割り当て確認 az role assignment list \ --scope "/subscriptions/<サブスクリプションID>/resourceGroups/myStorageRG" \ --output table
・Storage Blob Data Reader:Blobの読み取りのみ。S3のGetObjectに相当
・Storage Blob Data Contributor:読み取り・書き込み・削除。S3フルアクセスに相当
・Storage Blob Data Owner:コンテナのACL変更権限を含む最上位ロール
本番環境では、アカウントキー(
AZURE_STORAGE_KEY)よりもRBACまたはManaged Identityを使った認証が推奨です。アカウントキーが漏洩するとストレージ全体へのフルアクセスを許してしまいます。Managed DiskをLinux VMにアタッチしてマウントする
Managed DiskはVMの「追加データディスク」として使うブロックストレージです。「Managed(マネージド)」の名のとおり、ストレージアカウントの管理やレプリケーション設定をAzureが自動で担うため、Unmanaged Diskより運用がシンプルです。Blob Storageと違い、直接ファイルシステムをフォーマットしてマウントポイントを設定します。作業に入る前に、AzureのLinux VMに最初からアタッチされているディスク構成を押さえておきましょう。この2本を混同すると意図せずデータを失う可能性があります。
・/dev/sda — OSディスク(Managed Disk):OSがインストールされているディスク。VMを停止・削除してもデータは消えない有料リソース。
・/dev/sdb — 一時ディスク(Temporary Disk):Azure側が無料で提供する揮発性ストレージ。VMの再起動・サイズ変更・再デプロイ時にデータが消えることがある。高速だが永続化には絶対に使わないこと。
今回追加するManaged Diskは
/dev/sdc 以降のデバイスとして認識されます。データディスクのSKU(ストレージ種別)は用途に応じて選択します。
| SKU名 | 特徴 | 主な用途 |
|---|---|---|
| Standard_LRS | HDDベース・低コスト | 開発環境・バックアップ・アーカイブ |
| StandardSSD_LRS | SSDベース・安定したIOPS | Webサーバー・軽量データベース |
| Premium_LRS | 高速SSD・低レイテンシ | 本番データベース・業務アプリ |
| UltraSSD_LRS | 最高IOPSと帯域幅 | SAP HANAなど超高負荷DB |
1. Managed Diskの作成とVMへのアタッチ
以降のコマンドで繰り返し使う値を変数に設定しておくと、コマンドが短くなってミスも減ります。# 変数の設定(環境に合わせて変更してください) RG=myStorageRG VM_NAME=myLinuxVM DISK_NAME=myDataDisk LOCATION=japaneast # 100GBのManaged Disk(Premium SSD)を作成 az disk create \ --resource-group $RG \ --name $DISK_NAME \ --sku Premium_LRS \ --size-gb 100 \ --location $LOCATION \ --query "{Name:name, SizeGB:diskSizeGb, State:diskState}" \ -o table
Name SizeGB State ------------ -------- ----------- myDataDisk 100 Unattached
不要になったディスクは
az disk delete --resource-group $RG --name $DISK_NAME --yes で明示的に削除してください。VMを削除してもManaged Diskは自動削除されず、課金が継続します。# 既存VMにアタッチ(--lun は論理ユニット番号、省略すると最小番号が自動割り当て) az vm disk attach \ --resource-group $RG \ --vm-name $VM_NAME \ --name $DISK_NAME # アタッチ結果の確認 az vm show \ --resource-group $RG \ --name $VM_NAME \ --query "storageProfile.dataDisks[].{LUN:lun, Name:name, SizeGB:diskSizeGb}" \ -o table
LUN Name SizeGB ----- ------------ -------- 0 myDataDisk 100
2. Linux側でディスクを認識して確認
アタッチ後、VMにSSHで接続してディスクが認識されているか確認します。# ブロックデバイスの一覧でアタッチされたディスクを確認 lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 30G 0 disk ├─sda1 8:1 0 1G 0 part /boot ├─sda2 8:2 0 2G 0 part [SWAP] └─sda3 8:3 0 27G 0 part / sdb 8:16 0 100G 0 disk ← 新しく追加されたManaged Disk
/dev/sdb として認識されています(VM環境によっては /dev/sdc 等になる場合があります)。パーティションテーブルがない状態(子エントリなし)なので、これからパーティションを作成します。アタッチ直後に表示されない場合は、数秒待ってから再実行してください。3. パーティションの作成とフォーマット
partedコマンドでGPTパーティションテーブルとパーティションをワンライナーで作成します。100GB超のディスクでは特にGPT推奨です。# GPTパーティションテーブルを作成(ディスク全体を1パーティションとして使用) sudo parted /dev/sdb --script \ mklabel gpt \ mkpart primary xfs 0% 100% # パーティションが作成されたことを確認 lsblk /dev/sdb
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sdb 8:16 0 100G 0 disk └─sdb1 8:17 0 100G 0 part
xfs_growfs)がマウントしたまま実行できる点が現場で便利です。# XFSでフォーマット sudo mkfs.xfs /dev/sdb1
meta-data=/dev/sdb1 isize=512 agcount=4, agsize=6553472 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 data = bsize=4096 blocks=26213888, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=12799, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0
sudo mkfs.ext4 /dev/sdb1 でフォーマットできます。その場合、後述の拡張コマンドは xfs_growfs の代わりに resize2fs /dev/sdb1 を使います。4. マウントとfstab設定
# マウントポイントの作成 sudo mkdir -p /data # 動作確認のため仮マウント sudo mount /dev/sdb1 /data # マウント確認 df -h /data
Filesystem Size Used Avail Use% Mounted on /dev/sdb1 98G 24K 93G 1% /data
fstab の編集ミスは VM を起動不能にする最も危険な操作のひとつです。必ずバックアップを取ってから編集してください。
# fstab を編集前に必ずバックアップする sudo cp /etc/fstab /etc/fstab.bak # アンマウントしてからUUIDを確認 sudo umount /data sudo blkid /dev/sdb1 # 出力例 /dev/sdb1: UUID="a1b2c3d4-e5f6-7890-abcd-ef1234567890" BLOCK_SIZE="4096" TYPE="xfs" PARTUUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # fstabにUUID指定で追記 echo 'UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890 /data xfs defaults,nofail 0 2' | sudo tee -a /etc/fstab # 構文チェックをしてからマウントを反映(エラーが出なければ成功) sudo mount -a && echo "OK - fstab設定に問題なし"
nofail を付けておくとディスクがない状態でも起動に失敗しなくなります。本番環境では必須のオプションです。ディスクサイズをオンラインで拡張する方法
Azureでは実行中のVMを停止することなくディスクサイズを拡張できます(Premium SSD・Standard SSD対応)。ただし、Azure側で拡張しただけではLinux上のファイルシステムには反映されません。az側とLinux側の両方で作業が必要です。まずAzure側でディスクサイズを変更します。
# ディスクを100GB→200GBに拡張(アタッチされたままでも実行可能) az disk update \ --resource-group $RG \ --name $DISK_NAME \ --size-gb 200 # Azure側の拡張確認 az disk show \ --resource-group $RG \ --name $DISK_NAME \ --query "{Name:name, SizeGB:diskSizeGb}" \ -o table
Name SizeGB ------------ -------- myDataDisk 200
growpart を実行します。# カーネルにディスクサイズの変更を通知(SCSI再スキャン) echo "1" | sudo tee /sys/class/block/sdb/device/rescan # 拡張後のサイズが反映されているか確認(sdbは200GBになっているがsdb1はまだ100GB) lsblk /dev/sdb # growpartでパーティションを拡張(sdb の 1番パーティションを指定) sudo growpart /dev/sdb 1 # XFSファイルシステムをオンラインで拡張(マウントしたまま実行できる) sudo xfs_growfs /data # 拡張後のサイズを確認 df -h /data
Filesystem Size Used Avail Use% Mounted on /dev/sdb1 200G 533M 200G 1% /data
xfs_growfs はマウントしたまま実行できるため、データベースやWebサーバーを稼働したままディスクを拡張できます。ext4 の場合は sudo resize2fs /dev/sdb1 を使います(こちらもオンライン拡張対応)。ディスクをデタッチして別VMへ移す方法
Managed DiskはVMとは独立したリソースです。デタッチしたディスクはAzure上に残り、別のVMにアタッチして再利用できます。データ移行やVM移行時に活用できます。# まずLinux側でアンマウントする(このステップを省略するとデタッチが失敗する場合がある) sudo umount /data # Azure側でデタッチする az vm disk detach \ --resource-group $RG \ --vm-name $VM_NAME \ --name $DISK_NAME # 別VMにアタッチする az vm disk attach \ --resource-group $RG \ --vm-name newserver \ --name $DISK_NAME
lsblk を確認してマウントポイントを作成すれば、以前のデータがそのまま利用できます。fstabへのUUID登録は新しいVM側でも必要です。Blob StorageとManaged Diskのコスト比較と使い分け判断
| 用途 | 推奨ストレージ | 理由 |
|---|---|---|
| VMのOSディスク・データディスク | Managed Disk(Premium SSD) | ブロックストレージが必要。fsシステム直接マウント |
| ログ・バックアップの長期保存 | Blob Storage(Cool層) | ストレージ単価が安く、月額コストを最小化できる |
| Web資産(画像・CSS・JS)の配信 | Blob Storage(Hot層)+ CDN | 静的コンテンツ配信はBlob+Azure Front Doorが定番 |
| 複数VMで同じファイルを共有 | Azure Files | SMBマウントで複数VMから同時アクセス可能 |
| スクリプト・CLIでのファイル転送 | Blob Storage(az storage blob) | azコマンドで操作しやすい。SAS URLで一時共有も可能 |
トラブルシュート:よくあるエラーと対処
「AuthorizationPermissionMismatch」が出る
ストレージアカウントキーまたはSASトークンが正しく設定されていない場合に発生します。# エラー例 The request is not authorized to perform this operation using this permission. ErrorCode: AuthorizationPermissionMismatch # 対処: 環境変数が正しくセットされているか確認 echo $AZURE_STORAGE_ACCOUNT echo $AZURE_STORAGE_KEY # または --account-name / --account-key を明示的に指定 az storage blob list \ --container-name mycontainer \ --account-name mystorageaccount20260701 \ --account-key "XXXXXXXX..."
az login)でサインインしているが、RBACロールが未割り当ての場合にも同じエラーが出ることがあります。その場合は現在のユーザーにロールが付いているかを確認します。# 現在のサインインユーザーのオブジェクトIDを確認 az ad signed-in-user show --query id -o tsv # ロール割り当て一覧を確認 az role assignment list \ --scope "/subscriptions/<サブスクリプションID>/resourceGroups/myStorageRG/providers/Microsoft.Storage/storageAccounts/mystorageaccount20260701" \ --output table
az role assignment create で Storage Blob Data Contributor などを割り当ててください。「認証モードが合わない」エラー(--auth-mode)
--auth-mode login(Azure AD認証)で操作しようとしているが、環境変数にアカウントキーがセットされていると認証が競合することがあります。認証方法を明示的に指定して切り分けます。# Azure AD認証を明示(RBACロールが必要) az storage blob list \ --container-name mycontainer \ --account-name mystorageaccount20260701 \ --auth-mode login # アカウントキー認証を明示(開発・検証環境向け) ACCOUNT_KEY=$(az storage account keys list \ --account-name mystorageaccount20260701 \ --resource-group myStorageRG \ --query '[0].value' -o tsv) az storage blob list \ --container-name mycontainer \ --account-name mystorageaccount20260701 \ --account-key "$ACCOUNT_KEY" \ --output table
Managed Diskアタッチ後にlsblkで見えない
VMへのアタッチが完了しているように見えてもカーネルがデバイスをスキャンできていない場合があります。# SCSIバスを強制リスキャン(全ホストを対象) for host in /sys/class/scsi_host/host*; do echo "- - -" | sudo tee $host/scan done # デバイスが認識されたか再確認 lsblk
az vm show \ --resource-group $RG \ --name $VM_NAME \ --query "storageProfile.dataDisks[].{LUN:lun, Name:name, SizeGB:diskSizeGb}" \ -o table
/dev/sdc・/dev/sdd など別のデバイス名になっている可能性があります。lsblk -o NAME,SIZE,TYPE,SERIAL でシリアル番号まで表示すると特定しやすくなります。fstab設定後にVMが起動しない
fstabにUUIDを間違えて記入した場合にVMが起動しなくなることがあります。未然に防ぐには、fstab書き込み前に構文チェックを行うことが重要です。# fstabの構文チェックだけ行う(実際のマウントはしない) sudo mount --fake -a -v # エラーがなければ続行、エラーが出たら fstab を修正してから再試行 sudo mount -a
--fake オプションを付けると実際のマウントをせずに構文チェックだけ実行します。エラー箇所とともにメッセージが出るので、fstab の該当行を修正してください。万が一VMが起動しなくなった場合はAzureポータルの「シリアルコンソール」から復旧できます。操作手順:Azureポータル >> VM >> 診断 >> シリアルコンソール。ログイン後にバックアップから復元します。
# バックアップからfstabを復元する sudo cp /etc/fstab.bak /etc/fstab # 再起動する sudo reboot
sudo cp /etc/fstab /etc/fstab.bak)が必須です。また、本番環境では nofail オプションを必ず付けてください。ディスクが一時的にデタッチされた状態でもVMの起動が継続できます。ディスク拡張後にdfの値が変わらない
Azure側でaz disk update を実行しても、Linux側の growpart と xfs_growfs(または resize2fs)を忘れるとファイルシステムのサイズは変わりません。# Azure側のディスクサイズを確認(200GBになっているはず) az disk show --resource-group $RG --name $DISK_NAME --query diskSizeGb # Linux側のパーティションサイズを確認(まだ100GBのまま) lsblk /dev/sdb # growpartでパーティション拡張 → xfs_growfsでFS拡張の順に実行する sudo growpart /dev/sdb 1 sudo xfs_growfs /data
本記事のまとめ
| やりたいこと | コマンド・方法 |
|---|---|
| ストレージアカウントを作成 | az storage account create --name ... --sku Standard_LRS |
| Blobコンテナを作成 | az storage container create --name mycontainer |
| Blobにファイルをアップロード | az storage blob upload --container-name ... --file ... |
| Blob一覧を確認 | az storage blob list --container-name ... --output table |
| Blobをダウンロード | az storage blob download --container-name ... --name ... |
| 期限付きSAS URLを生成 | az storage blob generate-sas --permissions r --expiry $EXPIRY --full-uri |
| RBACでアクセス権を付与 | az role assignment create --role "Storage Blob Data Contributor" |
| Managed Diskを作成する | az disk create --size-gb 100 --sku Premium_LRS |
| VMにディスクをアタッチする | az vm disk attach --vm-name VM名 --name ディスク名 |
| パーティションを作成する | sudo parted /dev/sdb --script mklabel gpt mkpart primary xfs 0% 100% |
| XFSでフォーマットしてマウント | sudo mkfs.xfs /dev/sdb1 → sudo mount /dev/sdb1 /data |
| fstabに自動マウント設定 | UUID取得後に /etc/fstab へ nofail オプション付きで追記 |
| Azure側でディスクサイズを拡張 | az disk update --size-gb 新サイズ |
| Linux側でパーティション・FSを拡張 | sudo growpart /dev/sdb 1 → sudo xfs_growfs /data |
| ディスクをデタッチして別VMへ移す | az vm disk detach → az vm disk attach --vm-name newserver |
Blob StorageとManaged Diskは役割がまったく異なります。VMのデータディスクとして高速アクセスが必要ならManaged Disk、ログや画像などのオブジェクト保存ならBlob Storageという切り分けを軸に選んでください。
AzureのストレージはLinuxエンジニアが避けて通れない実務スキルです。Blob Storageのオブジェクト操作からManaged DiskのマウントとオンラインサイズまでをCLIで体系的に身につけておくことで、現場でのトラブル対応速度が大きく変わります。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 次のページへ:AzureのPrivate DNSゾーンを設定する方法|VNet内の名前解決をazコマンドで構成する
- 前のページへ:AzureのNSGとSSH公開鍵認証でLinux VMを安全に保護する方法|ネットワークセキュリティグループの設定と実践例
- この記事の属するカテゴリ:Azureへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます