azure

Azure DSC 拡張機能

Azure DSCは、Microsoft Azure PowerShell SDKの一部で、Azure仮想マシン用のPowerShell Desired State Configuration拡張機能です。

Azure DSC Extension v2.8

エクステンションの依存関係を指定して、依存関係のマッピングに従って関連ファイルをダウンロードします。

Azure DSC Extension v2.7

Windows Management Framework 4.0の最新バージョンへのサポートを追加しました。JSONファイルで、「WmfVersion」プロパティでフレームワークのバージョンを指定（4.0、5.0PP、latest）します。（参考：How to use WMF 4 with Azure DSC Extension in Azure Cloud Service Manager (ASM)）

Azure DSC Extension v2.6

いくつかのネットワークの問題を分析するのに役立つデバッグ情報を追加しました。今回のアップデートには追加機能はありません。

Azure DSC Extension v2.5

マイナーアップデートで機能追加はありません。

ネットワーク問題を解析するのに役立つデバッグ情報の追加といくつかの軽微な更新です。

Windows Management Framework 5.0 Production Previewに依存しています。

仮想マシンにインストールするには、「Set-AzureVMDscExtension -Version 2.5」を使用します。

Azure DSC Extension v2.4

機能追加はありません。

Windows Management Framework 5.0 Production Previewに対応しました。

仮想マシンにインストールするには、「Set-AzureVMDscExtension -Version 2.4」を使用します。

Azure DSC Extension v2.3

Windows Server 2016 Technical Previewに対応しました。

Windows Server 2016 で拡張機能を使うのに、WMFが不要になり、仮想マシンの再起動が不要になりました。そのため、拡張機能を使い始めるのにかかる時間がとても短くなりました。

Windows Management Framework 5.0 Preview April 2015に依存しています。

Azure DSC Extension V2.2

Publish-AzureVMDscConfigurationコマンドレットに新しい機能が追加されました。

Azure Resource Manager（ARM）で、Azure DSC拡張機能でデプロイするコマンドレッドセットが提供されます。

リリース履歴(リリースノート)

2015/10/21 Version 2.8

2015/10/01 Version 2.7

2015/09/20 Version 2.6

2015/09/16 Version 2.5

2015/09/01 Version 2.4

2015/08/22 Version 2.3

2015/08/17 Version 2.2

2015/07/21 Version 2.1

2015/06/17 Version 2.0

2015/05/15 Version 1.10.1

2015/04/29 Version 1.9

2015/04/28 Version 1.8

2015/02/24 Version 1.7

2015/02/23 Version 1.6.3

2014/11/20 Version 1.5

2014/10/23 Version 1.4

2014/10/13 Version 1.3

2014/10/07 Version 1.2

2014/09/08 Version 1.1

2014/08/01 Version 1.0

参考サイト

channel9で公開されているde:code2014のセッション動画で、エヴァの井上さんが話された「Azure Mobile Services & Notification Hubs で全てのデバイスにプッシュ通知を送る」をまとめた投稿です。

プッシュ通知とは？

アプリが非アクティブでもバックエンドでデバイスに新しい情報を表示することができる機能が、プッシュ通知です。好きなタイミングで好きなメッセージを送れる機能です。プッシュ通知によって、アプリケーションの起動きっかけを作るのです。

プッシュ通知の仕組み

バックエンドのアプリケーションから直接、端末のアプリケーションに通知を送っているわけではないのです。

バックエンドから、各ベンダーが提供するPNS（Platform Notification Services）経由で端末にプッシュ通知します。Windows 8の場合はWNS、iOSの場合はAPNs、Androidの場合はGCMとそれぞれおベンダーごとにPNSが異なり、プロトコルも異なります。

バックエンドからPNSには、ハンドルごとにリクエストをします。ハンドルは端末固有のトークンで、端末１つにつき１リクエスト送信する必要があります。たとえば、10万台のデバイスに通知する場合には、10万回リクエストを送信しないといけないのです。あるお客さんの例では、リクエストを送信し始めてから送信終了まで、4時間かかったケースもあります。

ハンドルは、アプリケーションがPNSから取得して、それをバックエンドのサーバーに保存して使用するという流れになります。

ハンドルは上記例のように、単なる文字れるです。一番上がAndroid、二つ目がWindowsのハンドルです。

一般的な課題としては、4つです。

プラットフォームごとに対応をしないといけないので、マルチプラットフォーム対応が必要になります。また、正常に送信できたのか失敗したのかをトレースしたいのでエラー処理が必要です。さらに、端末はどんどん買い換えていくのでハンドルが変わっていくので、サーバーにゴミデータがたまるので、データのライフサイクル管理が必要です。そして、大量の宛先に素早く送信するためのリアルタイム大量通知が課題になります。

Azureの2つの通知サービス

Microsoft Azureには2つの通知サービスが提供されています。
2種類の通知サービスが提供されているので、度々理解の混乱のもととなっています。

最初に登場したのが、BaaSの機能の一つとしてMobile Servicesの中でプッシュ通知を提供していました。その後に登場したのが、プッシュ通知に特化した通知ハブ（Notification Hubs）と言うサービスが提供されました。

Mobile Servicesの通知も改良されています。
管理ポータルでMobile Servicesのプッシュタブを見ると、上記画像のように表示されます。今は、通知ハブのAPIを使うように改良されているのです。
今後、通知の機能を使う場合には、通知ハブを意識していただければOKです。

通知ハブになると、いろいろな課題が改良されました。Mobile ServicesはBaaSの一部だったので、通知だけ欲しい顧客には大きすぎたり、あまり課題が改良されていなかったのです。

通知ハブのプッシュ通信

通知ハブはREST APIで操作します。
.NET、Node.jsのSDKが提供されており、直接REST通信をしなくても良いようになっています。

通知ハブは、プッシュ通知のハブとなるサービスです。
バックエンドとPNSの間にあって、様々な処理を受け持ちます。

バックエンドから通知ハブにリクエストを送り、通知ハブにデータベースがありハンドル情報を保持しているので、通知ハブから並列にPNSにリクエストを送信します。

通知ハブにリクエストを送信すると、ゲートウェイノードが受信しキューに登録します。通知ノードがキューを取得し、データストアからハンドルを取得します。ハンドルを取得して、数万とかある大量の通知だと判明すると、自動的に通知ノードがスケールします。通知ノードが自動的に何台も立ち上がって、並列に通知してくれます。

通知が失敗すると、PNSからエラーを受け取って、データストアに格納してくれます。また、ハンドルがどんどん新しいものに変わっていきますので、それも管理してくれます。期限切れしたハンドルは勝手に削除してくれます。

プッシュ通知の課題をしっかりと解決してくれています。
50万通で2040円ぐらいです。
これを自前で実装するには相当の開発と運用工数がかかるため、自前で用意するのが割にあわなくなっています。

どれぐらいスケールするのか。
Bingニュースの事例では、300万台以上の端末に2分以内で通知できています。

通知サービスの実装とテスト

提供されているSDKは、サーバーサイドは.NETとJavaScript、クライアントサイドはだいたい通常使われる端末は用意されています。

重要なクラスが2つあります。

NotificationHubClientクラスは、管理用のクラスです。通知ハブのデータべースの読み書きや通知の送信ができたり、なんでもできるサーバサイドのクラスです。

NotificationHubクラスは、PNSからハンドルをとってきて、通知ハブにハンドルを登録する、フロントのクラスです。

NotificationHubClientクラスは、Microsoft.ServiceBusの中に含まれているので、最初にNuGetで取得してきてください。

クライアントのほうは、Microsot.WindowsAzure.Messaging.Managedに、NotificationHubクラスが含まれているのでインストールしておいてください。

PushNotificationChannelManager.CreatePushuNotificationChannelForApplicationAsyncを呼ぶとPNSからハンドルを取得してきます。
NotificationHubで、通知ハブの名前を設定し、通知ハブの接続情報を指定します。
RegisterNativeAsyncで、ハンドルの情報を渡すと通知ハブのデータベースにハンドルを登録します。

 

Andoroidの場合も、同様の流れで操作できます。これはSDKが提供されているからです。
NotificationHubは同じで、Androidの場合はｍ、gcmからハンドルを取得してきて、通知ハブのデータベースにハンドル情報を登録します。

Microsoft Azureの管理ポータル上から、サーバーサイドの実装をしてなくてもプッシュ通知のテストをしたりすることができます。

サーバーサイドの実装です。
NotificationHubClient.CreateClientFromConnectionStringで、管理者用の接続情報を設定します。

メッセージ本文を設定し、送信します。メッセージ本文は、それぞれの端末の通知の従って記述します。そして、送信メソッドで送信します。
Androidは、SendGcmNativeNotificationAsync
iOSは、SendAppleNativeNotificationAsync
windowsは、SendWindowsNativeNotificationAsync

タグを使用して、特定のユーザーやグループだけに通知を送ることができます。通知ハブにタグを登録しておいて、タグでフィルタリングして送信できます。

タグは文字列です。
タグの登録には、RegisterNativeAsyncで、ハンドルとタグを指定します。

送信には、送信メソッドSendGcmNativeNotificationAsyncに、タグを渡してあげるだけでOKです。

タグのほかの使い方としては、アクセスログから長期間アクセスしていないユーザー全員にプッシュ通知をするというような使い方もできます。

テンプレート機能で一斉に複数プラットフォームにメッセージを変更して、データ送信することもできます。

大量配信のテストをしたいという要望があります。
その場合に裏技として、通知ハブに同じハンドルを大量に登録しておく方法があります。
同じハンドルを100件登録しておけば、100件の送信テストができます。
（同じ端末に100個通知されます…。）

ネタ元：Use port pings instead of ICMP to test Azure VM connectivity

ICMPプロトコルは、Azureのロードバランサーで許可されていないので、インターネットやAzure 仮想マシン内からAzure仮想マシンにpingをしても結果を取得できません。

エンドポイントを設定して、エクスターナルのIPを使用するネットワークトラフィックの場合の話で、Azure仮想ネットワークゲートウェイやExpressRouteを使って接続するときには、ICMPはブロックされません。

接続テストをするには、代わりにポートPingを使用することをお勧めします。
Ping.exeはICMPを使用するので、特定のTCPポートにpingできるPsPing, Nmap, or Telnetのようなツールを使用します。

たとえば、Azure仮想マシン内からyahoo.comにpingするとリクエストタイムアウトします。これは、AzureロードバランサーでICMPがブロックされているからです。

C:\>ping yahoo.com

Pinging yahoo.com [206.190.36.45] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 206.190.36.45:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

しかし、特定のポートに接続テストができるSysinternalツールのPsPingを使用して、Azure仮想マシンからインターネット上のサイトの80番ポートにテストをすると成功します。

C:\Users\craig\Downloads\PSTools>psping yahoo.com:80

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

TCP connect to 206.190.36.45:80:
5 iterations (warmup 1) connecting test:
Connecting to 206.190.36.45:80 (warmup): 53.25ms
Connecting to 206.190.36.45:80: 52.26ms
Connecting to 206.190.36.45:80: 52.14ms
Connecting to 206.190.36.45:80: 52.32ms
Connecting to 206.190.36.45:80: 51.48ms

TCP connect statistics for 206.190.36.45:80:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 51.48ms, Maximum = 52.32ms, Average = 52.05ms

ちなみに、bing.comへのICMP pingだけは例外的に動作します。BingとAzureは両方マイクロソフトが提供するからです。

C:\Users\craig\Downloads\PSTools>psping bing.com

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

Pinging 204.79.197.200 with 32 bytes of data:
5 iterations (warmup 1) ping test:
Reply from 204.79.197.200: 6.85ms
Reply from 204.79.197.200: 2.47ms
Reply from 204.79.197.200: 2.30ms
Reply from 204.79.197.200: 2.95ms
Reply from 204.79.197.200: 2.39ms

Ping statistics for 204.79.197.200:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 2.30ms, Maximum = 2.95ms, Average = 2.53ms

オンプレミスからAzure仮想マシンにテストをすると、同様の結果となります。ICMPトラフィックは、Azureロードバランサーでブロックされ、pingはタイムアウトします。しかし、代わりにポートpingをすれば、仮想マシンが起動していてファイヤーウォールでポートブロックされていなくてエンドポイントがされていれば、成功します。

C:\>ping CLJun21WS12R2A.cloudapp.net

Pinging CLJun21WS12R2A.cloudapp.net [23.100.76.67] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 23.100.76.67:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\>psping CLJun21WS12R2A.cloudapp.net:56972

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

TCP connect to 23.100.76.67:56972:
5 iterations (warmup 1) connecting test:
Connecting to 23.100.76.67:56972 (warmup): 60.44ms
Connecting to 23.100.76.67:56972: 61.28ms
Connecting to 23.100.76.67:56972: 63.41ms
Connecting to 23.100.76.67:56972: 63.69ms
Connecting to 23.100.76.67:56972: 60.41ms

TCP connect statistics for 23.100.76.67:56972:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 60.41ms, Maximum = 63.69ms, Average = 62.20ms

C:\>psping CLJun21WS12R2A.cloudapp.net:5986

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

TCP connect to 23.100.76.67:5986:
5 iterations (warmup 1) connecting test:
Connecting to 23.100.76.67:5986 (warmup): 61.49ms
Connecting to 23.100.76.67:5986: 65.29ms
Connecting to 23.100.76.67:5986: 67.08ms
Connecting to 23.100.76.67:5986: 62.70ms
Connecting to 23.100.76.67:5986: 60.99ms

TCP connect statistics for 23.100.76.67:5986:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 60.99ms, Maximum = 67.08ms, Average = 64.02ms

TechED 2014で、Microsoft Azureの機能追加がいくつか発表されました。その中に、仮想マシン作成時にカスタムスクリプトを実行させられる機能が追加されました。

IISの役割をインストールするpowershellスクリプト（.ps1）を用意し、ローカルディスクかAzureストレージに保存します。

install.ps1
Add-WindowsFeature Web-Server –IncludeAllSubFeature

次に、ポータルからスクリプトを使用するように設定します。

VMエージェントのインストールを選択し、「カスタムスクリプト」オプションを選択し、インストールスクリプトを選択します。他に必要な対応として、Firewallのポートを開けたり、websaiteのパスを変更があるので、それらもスクリプト化すると良いかも。

参考情報：Auto Install IIS in the Microsoft Azure VM that you are creating

Microsoft Azure RemoteApp Previewがアクティブになったので、触ってみた。メニューは管理サービスの上、Traffice Managerの下にある。

Azure RemoteAppで何ができるのかは、「Welcome to the Azure RemoteApp preview」メールに書いてあった。

• いろんなデバイスを使ってあらゆる場所から、会社のアプリケーションにユーザーがアクセスできるようになる
• 巨大な投資をすることなくビジネスの必要性に応じて、素早く対応することができる
• 信用と信頼のあるAzureのプラットフォームで、会社の情報を集中化させ守れる

プレビュー中は、次のような対応となるらしい。

• Azure RemoteAppを無償で提供
• プレビューサービスでは、2つのインスタンスをたて、各インスタンス10ユーザーまで許可する
• 7日連続で使用されなかったら、キャンセルされる
• 何かサービス提供に変更を加える場合は2営業日前に通知する
• プレビュー中に容量を増やしたい場合は、メールでMSに連絡する

とりあえず触ってみる

CREATE A REMOTEAPP SERVICEをクリックする

 

作成する手段は、「QUICK CREATE」と「CREATE WITH VPN」の２通り。

 

QUICK CREATEで提供されているテンプレートイメージは、今のところ「Microsoft Office 2013 Professionl Plus on Windows Server 2012 R2」１つだけ。

 

REGIONも多少少な目。正式サービスインするときには、日本にも来てほしいね！

 

とりあえず、QUICK CREATEで作成する。
ちなみに終わらない！！てイラッとしたけど、注意書きがあった(;´･ω･)
30分かかるよ！っと。

 

プロビジョニングは結構時間がかかって、自分が試した時で35分ぐらい待った。まぁプレビューだしね！

 

とりあえず、ダッシュボードを見てみる。
REMOTE DESKTOP CLIENT URLが書いてあるので、クリックする。

RemoteApp clientをインストールしろ！っといわれる。
RemoteAppを知らなさすぎるので、手探り状態。

 

 

マイクロソフトアカウントでログインする。

 

 

無事、表示された。

 

無事、Azureで動いているWordが起動した！

 

当たり前だけど、ローカルで動いているように見えてもAzure上で動いているので、ファイルを開くでファイル選択ダイアログを表示すると、Azureのインスタンスが対象になる。
おとなしくOneDriveを使いなさいってことですね。

 

アプリを起動しているときに、SESSIONを確認すると次のように表示される。起動するアプリケーション数はセッション数とは関係ないみたい。アプリ2つ立ち上げても、セッションは一つだけだった。

 

REMOTEAPP PROGRAMSを見ると、使用可能なプログラム一覧が表示される。

 

USER ACCESSでマイクロソフトアカウントを追加してあげる。

 

そしてログインすると表示される。素晴らしい素晴らしい！

 

Azure RemoteAppの概要

Windows Apps in the Cloud: Introducing Microsoft Azure RemoteAppを抜粋して紹介。

サポートするクライアント

• Windows用：Microsoft RemoteAppアプリケーションを提供
• iOS、Android用：Microsoft Remote Desktopをアップグレードしてサポート
• Mac、Windows Phone、Windows RTも近々でサポート予定

http://remoteapp.azure.com/からダウンロード可能。

永続ストレージの提供

Azure RemoteAppでは永続領域50GBを提供する。
これのバックエンドはAzureストレージで、安心。

Windows Server 2012 R2

Azure RemoteAppはWindows ServerのRemote Desktop Services上で構築されている。
共通の仮想セッションのもとに提供される共有モデルとなっている。

Office 2013プリインストール

プレビュー中は、Azure RemoteAppにMicrosoft Office 2013 Pro Plusを提供する。

2種類のデプロイメントの選択：クラウドのみか、ハイブリッドか。

Azure RemoteAppでは2種類のデプロイメントモデルを使用できる。

クラウドデプロイメント

Azureのリソースを使うので、OSは絶えず自動アップデートされ、Microsoft Anti-Malwareエンドポイントで防御されている。
Publishボタンを押すと、ほかにも配信したいアプリケーションを選択できる。

 

ハイブリッドデプロイメント

クラウドデプロイメントモデルは、標準的なOfficeへのアクセスを提供します。
ハイブリッドデプロイメントモデルだと、もっとカスタマイズできます。アプリケーション、OSなどの設定をコントロールできます。
テンプレートイメージを直接Azure Portalで管理できます。
ドメインに参加した環境でアプリが動いていたら、オンプレミスのNWとデータにアクセスできます。
Azure ADと統合し、ユーザーはログオンするのに自社の認証を使用できます。

クラウドで動作するアプリケーションが、シームレスにオンプレミスで提供されるデータとリソースにアクセスできます。これは、Azure仮想ネットワークのサイト-サイトVPNで構築されます。

カスタムテンプレートは、Windows Server 2012とRD Session Hostロールサービスをベースにしなければならない。