Azure Virtual Machines v2

v2というタイトルを付けましたが要はAzure Resource Manager(ARM)で管理できるようになったVirtual Machineの話です。

詳細はまぁこちらを参照ください。

さてさておさらい。クラシックポータル(いわゆる現行ポータル)はいつものようにシンプルなウィザードで作成できます。で、ポータル(いわゆるプレビューポータル)ではIPアドレスの指定などできるようになったけど基本的には普通のVMができあがります。

作成時の画面例:

imageimageimageimageimage

今までAzure PowerShellからだけ指定できていた固定IPアドレスやパブリックIPアドレスの予約など細かい指定ができるようになった以外は通常のVMです。できあがったあとはクラシックポータルからも管理することができます。

image

なおクラウドサービスも当然存在します。

image

 

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アドレスなどの要素がリソースになって個別に分かれたというだけですが。

image

現状あまり情報が無いので何となくですが。(主に依存関係メインで)

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>

例:

https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2Fazure-quickstart-templates%2Fmaster%2F101-simple-windows-vm%2Fazuredeploy.json

GitHubにあるテンプレート集のDeploy to Azureボタンの動作です。

例えばシンプルなVMを作るテンプレートで実際にしてみると、以下のような感じです。

テンプレートのGitHubのページにあるDeploy to Azrueをクリックします。

image

指定されたテンプレート(JSONファイル)の内容が表示されるので必要に応じてカスタマイズして保存します。

image

あとはテンプレートで入力が必要となっている項目に値を入力したりデプロイ先のサブスクリプションやリソースグループを選択すればデプロイできます。

image

テンプレートをよりよくすれば入力する手間も減りますし簡単ですね。

 

Azure ポータルでの見た目

Azure ポータル上では例えば Virtual Machines (v2) のように、v2が付いた項目がARMで作成したリソースになります。(明確に区別されます)

なので、ARMで作成したVMはv2扱いとなりクラシックポータルではまったく見ることも管理することもできません。

 

image

各リソースはv2が付いたもので見ることができます。

シンプルなVMの場合、リソースグループは例えば以下のようになります。

image

システムを構成するVMやNIC、IPアドレス、VNET、ストレージが含まれているのがわかります。

VMとVMの設定を見てみます。

image

パブリックIPアドレスやNICが割り当てられているのがわかります。

パブリックIPアドレスのリソースみてみるとDNS名や割当先(NICやVM)がわかります。

image

 

とまぁこんな感じで依存関係を追っていったり詳細を見ていくことができます。もうちょっと視認性が良くても(まとまってても)いいかもしれませんが現状はこうということで。

FQDNも先ほど説明したとおりの割り当てとなっています。

image

また明示的にロードバランサー配下にしたりNSGを使わない場合、直接公開されているようなものなので上記FQDNの3389につなげばRDPできます。またOS側でファイアウォールをオフにすればPingも飛びます(手抜き)

image

何気にほいほい公開してるとえらい目みる可能性が高いので注意しましょう。(ARMの特性考えるとそういう使い方は少ない気もしますが)

 

その他

ARMのテンプレート内のループで連番付与などできるようになりました。

"copy": {
       "name": "nicLoop",
       "count": "10" 
   },

Copyで定義して

"name": "[concat('nic', copyindex())]",

のようにcopyindex()でループ内で定義した連番を使うことができます。(この場合nic1 nic2 nic3…のように連結された文字列にできます)

 

FAQ

 

まとめ

ARMを使うとリソースを個別に管理できるようになり、かなりきめ細かくシステムを構成・管理していくことが可能です。その分多少複雑さが増しますが、テンプレートの活用などで負荷を下げていくとよいでしょう。

今後ポータルでGUIでの管理もどんどん良くなるのでマシにはなると思いますが、概念を正しく理解し利用することでよりよい運用ができるかと思います。またAzure Stackなどオンプレミス側でも同様なことができるようになることが想定されるので今のうちに慣れておくといいんじゃないでしょうか。(日本まだ未サポートだけど)

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中