v2というタイトルを付けましたが要はAzure Resource Manager（ARM）で管理できるようになったVirtual Machineの話です。
詳細はまぁこちらを参照ください。
- Developing Hyper Scale Applications on Microsoft Azure (Ignite 2015)
- Azure Virtual Machines Deep Dive (Build 2015)
- Azure リソース マネージャーにおける Azure コンピューティング、ネットワーク、ストレージ プロバイダー
さてさておさらい。クラシックポータル（いわゆる現行ポータル）はいつものようにシンプルなウィザードで作成できます。で、ポータル（いわゆるプレビューポータル）ではIPアドレスの指定などできるようになったけど基本的には普通のVMができあがります。
作成時の画面例：
今までAzure PowerShellからだけ指定できていた固定IPアドレスやパブリックIPアドレスの予約など細かい指定ができるようになった以外は通常のVMです。できあがったあとはクラシックポータルからも管理することができます。
なおクラウドサービスも当然存在します。
VM作るのもAzure ポータルで楽にできるようになりました。（※なおリソースグループが選択できますがv2ということではありませんので注意）ということでここまでがおさらい。
では新しいほうの話を。
Azure Virtual Machine v2（Preview）
ARMを使うとテンプレート（JSONファイル）を使用してパラメーターなどを宣言的にできるほか継続的なデプロイに使えたりロールベース制御（RBAC）で不要な権限を渡さずに管理ができたりなど最近の時流にそった管理を行うことができます。（JSON云々はおいといて）
またVMだけに限らずWeb Appsやストレージなどもまとめて管理できるので、単体のインスタンスではなくシステムとして構成できるのも大きな特徴です。
さてさて、では一体何が新しくなったのでしょうか？
Azure リソース マネージャーにおける Azure コンピューティング、ネットワーク、ストレージ プロバイダー にも記載がありますが、以下のような拡張がされています。
- 大量の Virtual Machines の並列デプロイメントが可能に
- 可用性セットで 3 つの障害ドメインがサポート
- カスタム スクリプト拡張機能が強化され、パブリックにアクセスできるカスタム URL からのスクリプトの指定が可能に（これまではカスタムスクリプトは内包する必要があったので外部URLを参照できるのはすごくいい）
- Virtual Machines と Azure Key Vault が統合（スクリプトに埋め込みたくない情報をKey Vaultで安全に管理・利用できる）
- API を使用したネットワーキングの基本的なビルディングブロックを提供、再利用可能
- 最上位のリソースとしてのロード バランサーによって IP アドレスの割り当てが可能
- 粒度の細かい Virtual Network API によって、個々の Virtual Network の管理が容易に
- LinuxでSSH-2 RSAフォーマットのSSH Keyをサポート
という感じです。簡単にまとめるとNICやPublicIP、VNET、可用性セット、ロードバランサーなどの要素がリソースになってあれこれ自由に構成できるようになりました。ということです。
※何気にちまちま1インスタンスしかデプロイできなかったのがARMだと並列してどんといけるのがいいですね。
上記リンクにもありますが、基本的に以下のような部分が変わります。
- VM用のクラウドサービス
- 従来は外側の枠としてのクラウドサービスが必須でしたが、不要になります。外部からの接続に使うFQDNなどは別のものがパブリックIPアドレスのリソースに割り当てられます。（VMには直接割り当てられません）
- 可用性セット
- Microsoft.Computeプロバイダーなリソースとして定義できます。障害ドメインはこれまでの2つから3つになります
- アフィニティグループ
- Virtual Networkで必要になっていましたがそもそもRegional Virtual Networkで指定する必要もなくなったので、単純化するためにv2ではなくなりました。
- ロードバランサー（負荷分散）
- 従来は暗黙的にロードバランサー配下でしたがMicrosoft.Networkプロバイダーで提供されるようになりました。負荷分散が必要であれば割り当てることができます。
- 仮想IPアドレス
- 従来はクラウドサービスに割り当てられていた仮想IPアドレスですが、Microsoft.Networkプロバイダーで提供されるようになりました。静的（予約済み）・動的を選ぶことができます。
- パブリックIPアドレスは静的モードで作成できます。現状の予約IPアドレスと同じ動作になります。またロードバランサーに割り当てることができるのは静的パブリックIPアドレスのみです。ネットワークセキュリティグループ（NSG）で保護できます
- インスタンス毎のパブリックIPアドレスもだいたい同様な感じです
- エンドポイント
- 従来はエンドポイントで定義していましたが、ロードバランサーに受信NATルールを構成することで行います。
- 例えばロードバランサー使わずにシンプルにパブリックIPアドレス（仮想IPアドレス）を割り当ててデプロイするとインターネット直接続のようなイメージになります。（OSのFWオフにしたら全公開みたいなイメージ）
- DNS名
- 従来はクラウドサービスに割り当てた名前（ xxxx.cloudapp.net ）でしたが、v2ではパブリックIPアドレスのリソースに割り当てられます。（省略可能）
- ＜ドメインラベル＞.＜リージョン＞.cloudapp.azure.com のようになります。
- ネットワークインターフェース
- 従来はVMに紐づいていたのが個別のネットワークインターフェースなリソースとして構成できます（VMとは別に構成して割り当てるイメージ）※ライフサイクルも別
結構大幅な変更です。概念を理解するのがムズカシイデスネ。
概念
簡単な概念を説明しておきます。基本的にはNICやIPアドレスなどの要素がリソースになって個別に分かれたというだけですが。
現状あまり情報が無いので何となくですが。（主に依存関係メインで）
NIC、VNET、LBはNSGの構成に依存してます（LBはたぶん）
これらの要素がバラバラに構成して接続していくというイメージですかね。VMにNICをアサインして、NICにはLBとVNETとNSGをアサインして、、という感じでしょうか。
まぁそのうちきれいな公式ドキュメントが出てくることでしょう。。（IgniteのPPTXも参照ください）
※シンプルな場合、Public IP Addressすら不要な気もする（必須ではないはず）
デプロイ方法
デプロイ方法は従来のARMのようにAzure PowerShellやAzure CLIのARMモードを使う方法の他にVisual Studio＋Azure SDKを使う方法、REST APIを使う方法の他にAzure ポータルからも行えます。
他の方法は割愛してAzure ポータルから行う方法ですが、現状はARMのテンプレートであるJSONファイルへのURLを以下のURLに渡すことでカスタムデプロイを行うことが可能です。
https://portal.azure.com/#create/Microsoft.Template/uri/＜テンプレートのJSONファイルのURL＞
例：
※GitHubにあるテンプレート集のDeploy to Azureボタンの動作です。
例えばシンプルなVMを作るテンプレートで実際にしてみると、以下のような感じです。
テンプレートのGitHubのページにあるDeploy to Azrueをクリックします。
指定されたテンプレート（JSONファイル）の内容が表示されるので必要に応じてカスタマイズして保存します。
あとはテンプレートで入力が必要となっている項目に値を入力したりデプロイ先のサブスクリプションやリソースグループを選択すればデプロイできます。
テンプレートをよりよくすれば入力する手間も減りますし簡単ですね。
Azure ポータルでの見た目
Azure ポータル上では例えば Virtual Machines (v2) のように、v2が付いた項目がARMで作成したリソースになります。（明確に区別されます）
なので、ARMで作成したVMはv2扱いとなりクラシックポータルではまったく見ることも管理することもできません。
各リソースはv2が付いたもので見ることができます。
シンプルなVMの場合、リソースグループは例えば以下のようになります。
システムを構成するVMやNIC、IPアドレス、VNET、ストレージが含まれているのがわかります。
VMとVMの設定を見てみます。
パブリックIPアドレスやNICが割り当てられているのがわかります。
パブリックIPアドレスのリソースみてみるとDNS名や割当先（NICやVM)がわかります。
とまぁこんな感じで依存関係を追っていったり詳細を見ていくことができます。もうちょっと視認性が良くても（まとまってても）いいかもしれませんが現状はこうということで。
FQDNも先ほど説明したとおりの割り当てとなっています。
また明示的にロードバランサー配下にしたりNSGを使わない場合、直接公開されているようなものなので上記FQDNの3389につなげばRDPできます。またOS側でファイアウォールをオフにすればPingも飛びます（手抜き）
何気にほいほい公開してるとえらい目みる可能性が高いので注意しましょう。（ARMの特性考えるとそういう使い方は少ない気もしますが）
その他
ARMのテンプレート内のループで連番付与などできるようになりました。
"copy": {
"name": "nicLoop",
"count": "10"
},
Copyで定義して
"name": "[concat('nic', copyindex())]",
のようにcopyindex()でループ内で定義した連番を使うことができます。（この場合nic1 nic2 nic3…のように連結された文字列にできます）
FAQ
- 現状、既存の（従来のサービス管理APIやポータルで作成した）ストレージやVNETにv2の仮想マシンはデプロイできません
- 現状、ARMのAPIで従来のサービス管理APIやポータルで作成したVMイメージを利用することはできません（イメージのコピーは可能）
- ARMで作ったVMやVNET、ストレージアカウントのクォータは既存のものとは別物として区別されます
- 既存のデプロイスクリプトは使える？
- ARM用に修正が必要です。こちらを参照 → Mac、Linux、および Windows 用 Azure CLI での VM 操作に使用するリソース マネージャーおよびサービス管理コマンドの対応
- 現状ExpressRouteには接続できません。
- 現時点で日本のリージョンは未サポートです。
まとめ
ARMを使うとリソースを個別に管理できるようになり、かなりきめ細かくシステムを構成・管理していくことが可能です。その分多少複雑さが増しますが、テンプレートの活用などで負荷を下げていくとよいでしょう。
今後ポータルでGUIでの管理もどんどん良くなるのでマシにはなると思いますが、概念を正しく理解し利用することでよりよい運用ができるかと思います。またAzure Stackなどオンプレミス側でも同様なことができるようになることが想定されるので今のうちに慣れておくといいんじゃないでしょうか。（日本まだ未サポートだけど）
