本記事は、AZ-104の勉強中につまずいたポイントを整理するシリーズの第5回です。
- 第1回：Azureネットワーク接続の違いを整理する
- 第2回：Recovery Services コンテナーとBackup vaultの違いを整理する
- 第3回：Log Analytics workspaceとストレージアカウントの違いを整理する
- 第4回：Entra joined、registered、hybrid joinedの違いを整理する
- 第5回：ARMテンプレートの基本構造と読み方を整理する（本記事）
今回は、Azure Resource Managerテンプレート、いわゆるARMテンプレートを整理します。
ARMテンプレートはJSONで書かれているため、最初に見ると少し読みづらく感じます。
しかし、基本構造を押さえると何を作成するテンプレートなのかを読み取りやすくなります。
この記事では、AZ-104対策として「ARMテンプレートをどこから読めばよいのか」に絞って整理します。
結論
最初にざっくりまとめると、次のようになります。
| 見るところ | 何を見るか |
|---|---|
$schema |
テンプレートのスキーマ |
contentVersion |
テンプレートのバージョン |
parameters |
外から渡す値 |
variables |
テンプレート内で使う値 |
resources |
作成・更新するAzureリソース |
dependsOn |
リソースごとの依存関係 |
outputs |
デプロイ後に返す値 |
AZ-104対策としては、まずresourcesを見て、何のAzureリソースを作成するテンプレートなのかを確認すると分かりやすいです。
そのうえで、parameters、variables、dependsOn、outputsを確認すると、テンプレート全体の流れを読み取りやすくなります。
前提：ARMテンプレートとは
ARMテンプレートとは、Azureリソースを宣言的にデプロイするためのJSONファイルです。
Microsoft Learnでは、ARMテンプレートはプロジェクトのインフラストラクチャと構成を定義するJSONファイルであり、デプロイするリソースとそのプロパティを宣言的に記述すると説明されています。(Microsoft Learn)
「宣言的」とは、リソースを作成する手順を順番に書くのではなく、「最終的にどのようなAzureリソースが存在していてほしいか」を定義する考え方です。
Azureポータルでリソースを作成する場合は、画面上で項目を入力しながら順番に設定していきます。
一方で、ARMテンプレートでは「この名前・このリージョン・このSKUのストレージアカウントが必要」というように、作成したいAzureリソースの完成形をJSONで定義します。
その定義をもとに、Azure Resource Managerが必要な作成・更新処理を実行します。
ARMテンプレートでは次のようなAzureリソースを定義できます。
- 仮想ネットワーク
- サブネット
- ネットワークセキュリティグループ
- ストレージアカウント
- 仮想マシン
- Log Analytics workspace
ARMテンプレートを使うと、定義した構成を再利用しやすくなります。
補足：MicrosoftはBicepを推奨している
ARMテンプレートについて調べていると、Bicepという言葉も出てきます。
Bicepは、Azureリソースを宣言的にデプロイするための言語です。ARMテンプレートと同じ機能を提供しますが、JSON形式のARMテンプレートよりも簡潔に書きやすい構文になっています。
Microsoft Learnでは、ARMテンプレートJSONとBicepのどちらを使うか迷う場合は、Bicepの利用が推奨されています。(Microsoft Learn)
ただし、AZ-104の学習や既存環境の確認では、ARMテンプレートのJSONを見る機会もあります。そのため、Bicepが推奨されているとしても、ARMテンプレートの基本構造を読めるようにしておくと理解しやすくなります。
ARMテンプレートの基本構造
ARMテンプレートは、主に次のような構造になっています。
{
"$schema": "...",
"contentVersion": "1.0.0.0",
"parameters": {},
"variables": {},
"resources": [],
"outputs": {}
}
それぞれの役割は次のとおりです。
| 要素 | 役割 |
|---|---|
$schema |
テンプレートの構文ルールを示す |
contentVersion |
テンプレートのバージョンを示す |
parameters |
デプロイ時に外から渡す値を定義する |
variables |
テンプレート内で使う値を定義する |
resources |
作成・更新するAzureリソースを定義する |
outputs |
デプロイ後に返す値を定義する |
AZ-104の勉強では、これらを全部暗記するというより、それぞれが何のための項目なのかを押さえるのが大事です。
parameters：外から渡す値
parametersとは、デプロイ時に外から渡す値を定義する場所です。
たとえば、リソース名、リージョン、SKU、環境名など、デプロイごとに変わる可能性がある値をparametersにします。
"parameters": {
"storageAccountName": {
"type": "string",
"metadata": {
"description": "Storage account name"
}
},
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]"
}
}
この例では、storageAccountNameとlocationがパラメーターとして定義されています。
storageAccountNameやlocationはデプロイ時に外から渡すことができます。
また、locationにはdefaultValueが設定されており、値が指定されなかった場合はリソースグループの場所が使われます。
parametersで押さえること
AZ-104対策としては、次のポイントを押さえておくとよいです。
- デプロイ時に外から渡す値を定義する
- デプロイごとに変わる値に使う
-
typeで値の型を指定する -
defaultValueを設定できる -
metadataに説明を書ける
ざっくり言うと、parametersは、テンプレートの外から受け取る値です。
variables：テンプレート内で使う値
variablesとは、テンプレート内で使い回す値を定義する場所です。
たとえば、リソース名の組み立てや何度も使う文字列をまとめたい場合に使います。
"variables": {
"storageSku": "Standard_LRS",
"storageKind": "StorageV2"
}
この例では、storageSkuとstorageKindを変数として定義しています。
variablesに定義した値はテンプレート内の他の場所から参照できます。
variablesで押さえること
AZ-104対策としては、次のポイントを押さえておくとよいです。
- テンプレート内で使う値を定義する
- 何度も使う値をまとめられる
- リソース名や設定値の組み立てに使われる
- デプロイ時に外から直接渡す値ではない
-
parametersと組み合わせて使われることがある
ざっくり言うと、variablesは、テンプレートの中だけで使う値です。
resources：作成するAzureリソース
resourcesとは、ARMテンプレートで一番重要な部分です。
ここに作成・更新したいAzureリソースを定義します。
"resources": [
{
"type": "Microsoft.Storage/storageAccounts",
"apiVersion": "2023-01-01",
"name": "[parameters('storageAccountName')]",
"location": "[parameters('location')]",
"sku": {
"name": "[variables('storageSku')]"
},
"kind": "[variables('storageKind')]",
"properties": {}
}
]
この例では、Storage Accountを作成するリソースが定義されています。
resourcesの中では、特に次の項目を見ると読みやすいです。
| 項目 | 見ること |
|---|---|
type |
何のAzureリソースか |
apiVersion |
どのAPIバージョンを使うか |
name |
リソース名 |
location |
作成するリージョン |
sku |
SKUやプラン |
kind |
リソースの種類 |
properties |
リソース固有の設定 |
AZ-104対策としては、まずtypeを見るのが大事です。
たとえば、typeがMicrosoft.Storage/storageAccountsであれば、Storage Accountを作成するテンプレートだと分かります。
resourcesで押さえること
AZ-104対策としては、次のポイントを押さえておくとよいです。
- 作成・更新するAzureリソースを定義する
- ARMテンプレートの中心となる部分
-
typeを見ると何のリソースか分かる -
nameでリソース名を確認できる -
locationで作成先リージョンを確認できる -
propertiesにリソース固有の設定が入る
ざっくり言うと、resourcesは、実際に作るAzureリソースを書く場所です。
dependsOn：リソースの依存関係
dependsOnとは、リソース同士の依存関係を指定するための項目です。
ただし、parametersやvariablesのようにテンプレートのトップレベルに書く項目ではありません。
dependsOnはresources配列の中にある各リソース定義の中で使います。
たとえば、あるリソースを作成する前に、別のリソースが先に作成されている必要がある場合に dependsOn を指定します。
たとえば、仮想マシンを作成する前に、ネットワークインターフェイスや仮想ネットワークが必要になることがあります。
そのような場合、先に作成する必要があるリソースをdependsOnで指定します。
"resources": [
{
"type": "Microsoft.Network/networkInterfaces",
"apiVersion": "2023-05-01",
"name": "[parameters('nicName')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Network/virtualNetworks', parameters('vnetName'))]"
],
"properties": {
"ipConfigurations": []
}
}
]
この例では、対象リソースが仮想ネットワークに依存していることを表しています。
つまり、ネットワークインターフェイスを作成する前に、仮想ネットワークが先に作成されている必要があります。
ARMテンプレートでは、依存関係が分かる場合はAzure Resource Managerが自動的に順序を判断することもあります。
ただし、明示的に依存関係を書きたい場合にdependsOnを使います。
dependsOnで押さえること
AZ-104対策としては、次のポイントを押さえておくとよいです。
- リソースの作成順序を制御する
- 先に必要なリソースを指定する
- 仮想マシン、NIC、VNetなど複数リソースを作るときに出てきやすい
- 依存関係が正しくないとデプロイに失敗することがある
ざっくり言うと、dependsOnは、どのリソースを先に作る必要があるかを示す項目です。
outputs：デプロイ後に返す値
outputsとは、デプロイ後に値を返すための場所です。
たとえば、作成したリソースの名前、接続先URL、IDなどを出力したい場合に使います。
"outputs": {
"storageAccountId": {
"type": "string",
"value": "[resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName'))]"
}
}
この例では、作成したStorage AccountのリソースIDを出力しています。
outputs は必須ではありません。
ただし、デプロイ後に他の処理で使いたい値がある場合に便利です。
outputsで押さえること
AZ-104対策としては、次のポイントを押さえておくとよいです。
- デプロイ後に値を返すために使う
- リソース名、ID、URLなどを返せる
- 必須ではない
- 後続の処理で使う値を出力できる
ざっくり言うと、outputsは、デプロイ後に確認・利用したい値を返す場所です。
ARMテンプレートを読むときの流れ
ARMテンプレートを読むときは、上から順番にすべて読むより、見る順番を決めると分かりやすいです。
| 順番 | 見るところ | 確認すること |
|---|---|---|
| 1 | resources |
何のAzureリソースを作るのか |
| 2 | type |
リソースの種類 |
| 3 | name |
リソース名 |
| 4 | parameters |
外から渡す値 |
| 5 | variables |
テンプレート内で使う値 |
| 6 | dependsOn |
リソースごとの依存関係 |
| 7 | outputs |
デプロイ後に返す値 |
特に最初は、resourcesの中のtypeを見るのがおすすめです。
typeを見ると、そのテンプレートが何を作るためのものなのかが分かります。
たとえば、次のように読みます。
"type": "Microsoft.Storage/storageAccounts"
これはStorage Accountを作るリソースです。
"type": "Microsoft.Network/virtualNetworks"
これはVirtual Networkを作るリソースです。
"type": "Microsoft.Compute/virtualMachines"
これはVirtual Machineを作るリソースです。
このように、まずtypeを見て何のAzureリソースを作るテンプレートなのかを確認すると、全体を読みやすくなります。
実際には1から書くとは限らない
ここまでARMテンプレートの基本構造を見てきましたが、実際にARMテンプレートを使うときには必ずしも1からすべて手書きするとは限りません。
たとえば、Azure portalから既存リソースやリソースグループのARMテンプレートをエクスポートしたり、Microsoftが公開しているAzure Quickstart Templatesを利用したりできます。(Microsoft Learn)
Azure portalからテンプレートをエクスポートすると、既存リソースの設定をもとにARMテンプレートを確認できます。これにより、対象リソースにどのようなtype、apiVersion、propertiesが使われているかを確認しやすくなります。
ただし、エクスポートしたテンプレートは、そのまま別環境で使えるとは限りません。環境ごとに変わる値をparametersに分けたり、不要な設定を削除したりする調整が必要になることがあります。
そのため、AZ-104対策としては「ARMテンプレートを完全に1から書けること」よりも、「既存のテンプレートを見て、何のリソースをどのような設定で作ろうとしているのかを読めること」が重要だと思います。
まとめ
ARMテンプレートは、Azureリソースを宣言的にデプロイするためのJSONファイルです。
最初は読みづらく見えますが、基本構造を押さえると、何を作成するテンプレートなのかを読み取りやすくなります。
| 見るところ | 何を見るか |
|---|---|
$schema |
テンプレートのスキーマ |
contentVersion |
テンプレートのバージョン |
parameters |
外から渡す値 |
variables |
テンプレート内で使う値 |
resources |
作成・更新するAzureリソース |
dependsOn |
リソースごとの依存関係 |
outputs |
デプロイ後に返す値 |
現在は、ARMテンプレートJSONよりも簡潔に書けるBicepもよく使われます。Microsoft Learnでも、ARMテンプレートJSONとBicepのどちらを使うか迷う場合は、Bicepの利用が推奨されています。
ただし、AZ-104の学習や既存環境の確認では、ARMテンプレートのJSONを見る機会もあります。また、実際にARMテンプレートを使う場合でも、Azure portalから既存リソースのテンプレートをエクスポートしたり、Azure Quickstart Templatesを利用したりすることがあります。
そのため、ARMテンプレートを最初から全部書けるようになるよりも、まずはresourcesの中のtypeを見て、何のAzureリソースを作るテンプレートなのかを読み取れることが大事です。
この記事がAZ-104を勉強している方の整理に役立てば嬉しいです。