「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次  †
概要  †
- Azureでは、主にARM テンプレートを利用して、
インフラ~OS レイヤまでのインフラ構築の「自動化(IaC)」を行う
 
詳細  †
機能  †
入力  †
Resource Manager はテンプレートを解析し、
その構文を適切なリソース・プロバイダの REST API 操作に変換する。
出力  †
既存のリソース・グループのテンプレートの取得
- リソース・グループの現在の状態をエクスポート
 
- 特定のデプロイに使用されたテンプレートを表示
 
構造  †
ARMテンプレートとパラメタ・ファイルから構成される
ARMテンプレート  †
作成するリソース群を指定する(template.json)。
ARMパラメタ・ファイル  †
- 可変要素をパラメタ化する(parameters.json)。
 
- テンプレート実行時に外部から値を与える。
 
編集と実行  †
編集  †
Visual Studio Code に ARM Tools プラグインを入れ編集。
実行  †
ポータルから保存・実行すると便利。
※ ローカルで実行するには、PowerShellライブラリのインストールなど環境構築が必要になる。
作り方  †
Automation  †
- スクラッチで記載するのは難しいので、
Automationオプション、Automationスクリプトを使用する。 
- リソースの作成前 or 作成後でやり方が変わってくる。
 
- リソース作成時にテンプレートを引き抜く。
ポータルからのリソース作成時に、Automationオプションを確認 
- リソース作成後にテンプレートを引き抜く。
リソース・グループまたはリソースから、Automationスクリプトを出力 
- 以下のトレード・オフがあるので、
2つの方法を併用して作成する。
 | Automationオプション リソース作成時にテンプレートを引き抜く。 | Automationスクリプト リソース作成後にテンプレートを引き抜く。 | 
| GOOD | 綺麗な JSON が入手できる | 合体(依存関係アリ、構成変更後)のJSONを入手できる。 | 
| BAD | ・一部の新しいリソースでサポートされていない。 ・全てがパラメタライズされた状態の JSON。 ・単体(依存関係ナシ、構成変更前)のJSONしか入手できない。 | ・リソースによっては、JSON化出来ないモノがある。 ・半端にパラメタライズされた状態の JSON。 ・余分な値や、重複した出力がされることがある。 | 
 
サンプル・シナリオ  †
ハブネットワークの ARMテンプレート作成
※ 以下、サンプル・シナリオの手順
手順  †
リソース作成時のテンプレート引き抜き機能を使用する。
- 作成前に、Automationオプションを選択し、
ARMテンプレートとパラメタ・ファイルを引き抜く。 
サブネットの作成  †
既存リソースから、リソース作成後のテンプレート引き抜き機能を使用する。
(作成時は引き抜き不可であるため)
- 先ず、ポータル上でサブネットを3つ構成する(仮想ネットワークのサブ・リソース)。
 
- 作成後に、Automationスクリプトを選択すると、
当該リソースが含まれるリソース・グループ全体を
ARMテンプレートとパラメタ・ファイルに引き抜く。 
- Automationスクリプトの特徴。
- リソース・グループ全体が引き抜かれる。
 
- 既定値や、現在の状態など、余分なパラメタ値が引き抜かれる。
 
- サブ・リソースが独立したリソースとして展開される。
- このため、全体的に冗長になる。
 
- また、依存関係が展開先に変更される。
 
 
 
- Automationスクリプトをテンプレートにマージする。
 
- コチラのテンプレートをベースに、Automationスクリプトを参考にして、
展開されたリソース(サブネット)は、(仮想ネットワークの)サブ・リソース的にマージする。
- ココでは、サービス・エンドポイントの定義が追加されているのでコレもマージする。
 
- 既定値や、現在の状態など、GUIから設定していない余分な値は、移行しないようにする。
 
 
ルート・テーブル(UDR)の作成  †
同様に、既存リソースから、リソース作成後のテンプレート引き抜き機能を使用する。
(リソース依存関係の指定がポイント)
- ポータル上でルート・テーブル(UDR)を構成する。
 
- Automationオプションを確認する(依存関係ナシ、構成変更前)。
 
- 上記のルート・テーブルをポータル上で実際に作成し、
 
- Automationスクリプトを生成する(依存関係アリ、構成変更後)。
 
- Automationスクリプトを確認する。
- ルート・テーブルとルートが生成され、関連付けは、サブネット側に入る。
 
- ルート・テーブルのサブ・リソースのルートが展開され、重複して出力される。
 
 
※ 前段階のAutomationスクリプトとDiffを取るなどすると良さそうではある。
- Automationスクリプトをテンプレートにマージする。
 
- ベースのテンプレートに新規リソースとサブ・リソースの定義だけをマージする。
- ルート・テーブルとルートの作成の定義
 
- サブネットに追加されたルート・テーブル割当の定義
 
 
- 依存関係を分析して、依存関係を設定し直す。
依存関係設定は、親同士の依存関係に置き換えると良い。
- 「サブネット → ルート・テーブル」の依存関係を、
 
- 「仮想ネットワーク → ルート・テーブル」の依存関係に修正。
 
 
再び、リソース作成時のテンプレート引き抜き機能を使用する。
(テンプレートに含めるリソースの範囲がポイント)
- ポータル上でGateway用サブネットに、
VPN Gateway(+パブリックIP)を構成する。
(対向ネットワークが無いと設定できない所は構成しない等) 
- 作成前に、Automationオプションを選択し、
ARMテンプレートとパラメタ・ファイルを引き抜く。 
- Automationオプションをテンプレートにマージする。
 
- リソース作成後のテンプレート引き抜き機能を使用した後に、
リソース作成時のテンプレート引き抜き機能を使用する場合、
(既にあるリソースが前提になっているので)
以下の様に依存関係の修正が必要になることがある。
- 定義にリソースを識別する固定値のIDが使用されている場合、
resourceId関数を使用した動的解決が必要になることがある。 
- また、依存関係設定は、親同士の依存関係に置き換えると良い。
 
 
既存リソースからのテンプレート引き抜き機能に対応していない場合の扱い方
現時点では、上記の引き抜き機能が実装された。
(されていない場合は、リファレンス頼りになる)
- Automationスクリプトをテンプレートにマージする。
 
再び、リソース作成時のテンプレート引き抜き機能を使用する。
(グローバル一意リソースが存在するケース)
- 作成前に、Automationオプションを選択し、
ARMテンプレートとパラメタ・ファイルを引き抜く。 
- Automationオプションをテンプレートにマージする。
 
- ストレージ・アカウントのセクションをテンプレートにマージする。
- virtualNetworkRules?のサブネットの固定値のIDをresourceIdで動的解決する。
 
- コチラの段階で、サブネットにサービスエンド・ポイントが指定されている。
 
- そして、(サブネットではなく)仮想ネットワークへの依存関係を追加する。
 
 
- テンプレートの修正後、実際にリソースを作成する。
(この際、グローバル一意リソース用の変数入力が求められる) 
管理VM用サブネットに管理用の仮想マシンを作成するが、仮想マシンでは、
- リソース作成時のテンプレート引き抜き機能と
 
- リソース作成後のテンプレート引き抜き機能とを
 
併用する(そして、評価式の修正のコツがポイント)。
- 作成前に、Automationオプションを選択し、
ARMテンプレートとパラメタ・ファイルを引き抜く。 
- 仮想マシンは、多数のリソースから構成されることが解る。
 
- また、各リソース間に依存関係もある。
- NIC → (NSG、パブリックIP)
 
- NSG → (-)
 
- パブリックIP → (-)
 
- 仮想マシン → (NIC)
 
 
- Automationオプションをテンプレートにマージする。
 
- パスワードは、グローバル一意リソース同様、
parametersセクションに変数を追加する(が、型はsecureStringにする) 
- parametersセクションに変数の加工が必要な場合、variablesセクションが使用されている。
variablesを使用しないように展開すると、この中に動的解決スべきパラメタを確認できるので、
この値をresourceIdで動的解決する(NICが利用するサブネットやNSGのIDが該当する)。
 
- Automationスクリプトを生成・確認する。
すると、追加で以下の依存関係が確認できる。 
- Automationスクリプトをテンプレートにマージする。
 
- 上記の依存関係を追加するが、同様に、
親同士の依存関係に置き換えると良い(サブネット → 仮想ネットワーク)。 
- テンプレートの修正後、実際にリソースを作成する。
(この際、グローバル一意リソース用の変数入力が求められる) 
DNS等配置用サブネットにDNSサーバ用の仮想マシンを作成するので、
冗長化のタメに可用性セットに2台の仮想マシンを配置するが、
この場合、1台作成してコピペで増やすという方法が採れる。
- 作成前に、Automationオプションを選択し、
ARMテンプレートとパラメタ・ファイルを引き抜く。 
- Automationオプションをテンプレートにマージする。
 
- 作成前に、Automationオプションを選択し、
ARMテンプレートとパラメタ・ファイルを引き抜く。 
- Automationオプションをテンプレートにマージする。
 
- Automationスクリプトを生成・確認する。
すると、追加で以下の依存関係が確認できる。
 
- Automationスクリプトをテンプレートにマージする。
 
- 最後に、仮想マシンをコピペで増やし、リネームし、衝突が無いことを確認する。
(アンチ・マルウェアなどを構成すると、VM名が含まれないリソースが含まれるケースもあるらしい)。 
- テンプレートの修正後、実際にリソースを作成する。
(この際、グローバル一意リソース用の変数入力が求められる) 
- 更に、静的IPを構成して、追加のフィードバックを行う。
- Automationスクリプトを生成・確認する。
 
- スクリプトをテンプレートにDiff&マージ。
 
- 静的IPはNICのコンフィギュレーションらしい。
 
 
ポイントのまとめ  †
Automationを使用してテンプレートを作成する際のポイントのまとめ。
基本的な修正  †
何れの場合も、以下の、基本的な修正を施す。
- テンプレート内のパラメタ値の具体値化を行う。
- template.jsonのresourcesセクションの"[parameters('XXXX')]"を、
parameters.jsonのparametersセクションの具体値に変える。 
- 具体値に変えた、template.jsonのparametersセクションのパラメタを削除する。
 
 
- 既定でGUIからの入力を使用するパラメタの動的値化を行う。
 
- "[parameters('XXXX')]"だった所を"[resourceGroup().XXXX]"に変更する。
(これでテンプレートを実行する際に与えられるパラメタを使用するらしい) 
ユーザ入力を反映する場合  †
グローバル一意リソースが存在する場合などのケースで利用する。
- parametersセクションを使用すると、
実行時にユーザ入力を反映できる。 
- variablesセクションを使用すると、
parametersセクションの変数を加工できる。 
テンプレートの新規作成  †
仮想ネットワーク作成時、
リソース作成時のテンプレート引き抜き機能を使用して、
テンプレートを新規作成。
テンプレートへのマージ  †
- 以降、基本的には、既存リソースから、
リソース作成後のテンプレート引き抜き機能を使用して、
Automationスクリプトをテンプレートにマージ。 
- 再び、リソース作成時のテンプレート引き抜き機能を使用して、
Automationオプションをテンプレートにマージする場合、 
※ 仮想マシン等では、上記2つの方法を併用する。
依存関係の分析と設定  †
- 基本的に、サブ・リソースは使用せず、
親同士の依存関係に置き換えると良い。 
- 再び、Automationオプションを使用する場合、
(既にあるリソースが前提になっているので)依存関係の修正が必要になることがある。
- 定義にリソースを識別する固定値のIDが使用されている場合、
resourceId関数を使用した動的解決が必要になることがある。 
- また、依存関係設定は、親同士の依存関係に置き換えると良い。
 
 
- dependsOnのIDの書き方
文字列と関数の2種類あり、文字列を使用する方法では、
簡便な記述ができるようになっているが、指定が曖昧になり易い。
- 文字列:"Microsoft.Network/virtualNetworks/azrefarc-hub-vnet/subnets/mgmt"
 
- 関数:"[resourceId(resourceGroup().name, 'Microsoft.Network/virtualNetworks/subnets', 'azrefarc-hub-vnet', 'mgmt')]"
 
 
配置が成功するまで、trial and error。  †
- テンプレートが複雑、展開に時間のかかる
リソースは最後にテンプレに追加するようにする。 
テンプレート化は構成が確定してから。  †
- そもそもクラウドのインフラ構築は、
「trial and error」な所があるため、
序盤に着手すると手戻りが大きくなる可能性がある。 
- 故に、構築の序盤にはポータルを使用し、
熟れてから、テンプレート化を開始するようにする。 
参考  †
Microsoft Azure  †
Microsoft Docs  †
Qiita  †
- Azure Resource Manager テンプレートを
 
nakama  †
FgCF > ゼロトラスト型マルチクラウド IT 環境 > Azure による仮想データセンタ構築手法
'> 共通技術 > ネットワーク基盤の構成方法 > ARM テンプレートの利用方法
※ 体系はコチラ、pwdはコチラ
Tags: :インフラストラクチャ, :クラウド, :Azure, :IaC