Internal Load Balancing（内部向け負荷分散）がGA（一般提供）されました。
はやかったですね。ご利用はAzure PowerShell等でどうぞ。
JAZUG
Azure のネットワークACLの挙動
こういうお話がありました。
結論からいうと、LBとかじゃなくてホストサーバー上の設定なのでVNET（特に拒否の設定）指定ができちゃいます。
とはいえちょっと気になったので見てみることにします。こんなVNET to VNETなネットワークをAzure上で組んでみました。
ca1-srv1-vnet1 なインスタンスにIISを入れてHTTP（tcp/80）なエンドポイントを定義します。（LBは省略しました）
ネットワークACL（エンドポイントACL）を何も設定しない際に各インスタンスで内部のIPアドレスと外部のFQDN（図だとca1.cloudapp.net）にブラウザで接続してIISの既定のページが見れることは確認済みな状態とします。（Azure外のクライアントも当然OK）
※ようは疎通できてる状態
さて、以下の表のような感じでACLを定義したときに、それぞれのインスタンスから内部IPとFQDNでアクセスしてどうなるかを見てみました。
| ACLの状態 | ca1-srv1-vnet1 | ca1-srv2-vnet1 | ca2-src1-vnet1 | ca3-srv1-vnet2 | 外部PC | ||||
| 内部IP | FQDN | 内部IP | FQDN | 内部IP | FQDN | 内部IP | FQDN | FQDN | |
| vnet1のみ許可 | OK | OK | OK | OK | OK | NG | OK | NG | NG |
| vnet1のみ拒否 | OK | OK | NG | OK | NG | OK | OK | OK | OK |
| vnet2のみ許可 | OK | OK | OK | OK | OK | NG | OK | NG | NG |
| vnet2のみ拒否 | OK | OK | OK | OK | OK | OK | NG | OK | OK |
| 外部PCのみ許可 | OK | OK | OK | OK | OK | NG | OK | NG | OK |
| 外部PCのみ拒否 | OK | OK | OK | OK | OK | OK | OK | OK | NG |
| ca1のGIPのみ許可 | OK | OK | OK | OK | OK | NG | OK | NG | NG |
| ca1のGIPのみ拒否 | OK | NG | OK | NG | OK | OK | OK | OK | NG |
| ca2のGIPのみ許可 | OK | OK | OK | OK | OK | OK | OK | NG | NG |
| ca2のGIPのみ拒否 | OK | OK | OK | OK | OK | NG | OK | OK | OK |
| ca3のGIPのみ許可 | OK | OK | OK | OK | OK | NG | OK | OK | NG |
| ca3のGIPのみ拒否 | OK | OK | OK | OK | OK | OK | OK | NG | OK |
※クラウドサービスのグローバルIPアドレスは一応インスタンス上からインターネットにアクセスした際に使用されるIPアドレスを確認して設定
本来ネットワークACLは許可だけが設定されたらそのルールにマッチしないものは拒否になるはずですが、VNETを許可した場合はその辺うまく動作してない様子。
例えばvnet1だけ許可した場合だと、vnet2にいるインスタンスからもアクセスできてしまっています。（期待値としては拒否してほしい）
ただ拒否設定の場合は想定どおりになるようなので、何とも不可思議な挙動です。（表中で怪しいところをわかりやすくしようと思ったけど、面倒くさくなったので放置）
但し、ネットワークACLのドキュメントを見る限りでは
仮想ネットワークに対して ACL を指定したり、仮想ネットワーク内にある特定のサブネットに対して ACL を指定したりすることはできません。
とあるので今のところこのあたりの挙動は想定外なのかもです。今後に期待。
また、ネットワークACLのパケットフィルタ処理はホストノード上で実行されるようです。
ACL を作成して仮想マシンのエンドポイントに適用するとき、パケット フィルターが VM のホスト ノードで実行されます。これは、リモート IP アドレスからのトラフィックのフィルター処理が、VM 上ではなく、ホスト ノードによって実行され、ACL ルールとの照合が行われることを意味します。これにより、パケット フィルターの処理で VM が重要な CPU サイクルを消費するのを防ぐことができます。
上位のFWとかルータじゃなかったのねー。
まぁとりあえず現状はVNETに対するACLは微妙にノンサポートという感じですので、もし制限したい場合はご注意ください。（意図せず外部はOKになったりする可能性があります）
Azure Web Sites周りいろいろアップデート
Updateはいつも唐突に。
というわけで現行ポータルでWebサイトにアクセスするとこんなメッセージがでるようになりました。
Oh…
今回のUpdate内容も基本はプレビューポータルでの話ですね。
AzureのPublishSettingsの証明書
元ネタはこちら
思うに、秘密鍵へのアクセスが制限されてるからな気がする。
実際に証明書をインポートして、Certmgrとかからエクスポートしようとしても秘密鍵のエクスポートが許可されてないのでアクセスできません。
Azure上で動かないのは下記のKBあたりが原因かな？
アプリケーションプールの実行ユーザーに適切な権限が無かったりユーザープロファイルがロードされてないのが原因ぽいです？ 秘密鍵にコードからアクセスできないからそこは良しなにしようとするけど、それもできずに例外吐いてるのかなー。
とか思いました。Webサイトじゃなくてクラウドサービスならあるいは。
まぁPublishSettingsの中の証明書が変わるかしないとしんどいかな。しかしアレはアレで面倒なのでどっちつかずであります。
Azure ブラジル南部リージョンが一般利用開始（GA）
Azureの新しいデータセンターとしてブラジル南部リージョンがGAしました。
いつの間にか文字化けも直ってますね。。
というわけで、どんどんDCが増えますね。まぁDC増えるのもいいのですが、全リージョンで機能レベルを合わせてほしいです。。。
追記：ブラジルGEOとしてはブラジル南部（サンパウロ）と、現状は米国中南部（テキサス）への片方向レプリケーションのようです。(Microsoft Azure のトラスト センター)
※あと、このあたりの影響かどうかはわかりませんが、アメリカ中北部とかのIPアドレスの所在地がブラジルにあると認識されちゃったりするっぽい？のでSR投げるかしてあげると良いのではないでしょうか。
※経路が腐ってたり、TrafficManagerがおかしな挙動するとかだと大変アレです。
Azure 自習書シリーズ
いわゆるMicrosoftさんが出してる自習書なるドキュメントです。ハンズオン形式で自分で試しながら勉強できます。
中身はこんな感じです。
- 01: Microsoft Azure 仮想マシンの立ち上げ、基本的な使用方法 (Windows Server 編)
- 02: Microsoft Azure 仮想マシンの立ち上げ、基本的な使用方法 (Linux 編)
- 03: 物理環境にある Windows Server の仮想化及び Microsoft Azure への移行
- 04: 企業内システムと Microsoft Azure の VPN 接続
- 05: 企業内システムと Microsoft Azure の VPN 接続、Active Directory 連携
- 06: 企業内システムと Microsoft Azure の VPN 接続、ADFS、Office365 との連携
- 07: 企業内システムと Microsoft Azure の VPN 接続、ファイルサーバー連携
- 08: 企業内システムと Microsoft Azure の VPN 接続、Active Directory、ファイルサーバー連携
- 09: Azure バックアップを利用した Microsoft Azure 仮想マシンのバックアップ
- 10: Microsoft Azure 上の仮想マシンおよびファイルサーバーのデータを vhd ファイルとしてバックアップ
- 11: Azure バックアップを利用したオンプレミス Windows Server のバックアップ
- 12: Microsoft Azure SQL Server の活用(IaaS 環境における設定や運用のベストプラクティス)
ダウンロードサイトからゲットしてください。（諸般の事情により個別にダウンロードとなるようです）
とりあえず//Build/あたりのUpdateは最低限入ってると思われます。TechEd 2014 NAはどうだったかな？
Webサイトとかは更新が早いのでなかなか。あと今の一覧見て分かる通り、どちらかというとエンタープライズ向けです。（企業向け）
Azure HDInsight が Hadoop 2.4をサポート
したようです。
Hadoop Summitで発表があったみたいですね。
詳細はこちら
Azure Web Sites のAntimalware
ってされてるんですか？という話題があったので適当に見てみました。
EICARテストファイルを作ってどんな挙動になるかというのを見てみます。
こんな感じでWebサイト上に作ります
そもそも普通に作成できました。実行してみましょう。
普通に実行できました。まぁ実際に動作するファイルじゃないわけで結果は妥当な感じ。（アンチウィルスのチェックとしてはダメですが）
さてローカルPCで見てみましょう。
中身を入力して保存したタイミングでWindows Defenderさんが反応します。
実行するとちゃんとウィルスの可能性があるから実行しないよ的なメッセージになります。
しばやん先生によるとAzure Webサイト上はWindows Defenderが手動開始になっているようで、動作してないっぽいですね。
というわけで注意しましょう。
Visual Studioを使った仮想マシンのデバッグとデプロイ
今更感がありますがVisual Studioを使うと仮想マシンのデバッグとデプロイが簡単にできます。
※Visual Studio 2013 Update2以降とAzure SDK 2.3、Azure PowerShell 0.7.4(Windows PowerShell 3.0)以降が必要ですが。
具体的にどう簡単になったかというと、新規でWebアプリケーションを作成する際のダイアログで、「クラウド内のホスト」にチェックを付けて仮想マシンを選ぶと仮想マシンをデプロイしてWebDeployが有効な状態にしてくれます。
こんな感じでIISとWeb配置の有効化を行うと、IISのインストールとWebDeployの準備をしてくれます。
※「OK」ってした段階で仮想マシンが作られますので注意。
実際に作成された仮想マシンを見てみると
てな感じでWebアプリケーションで必要な設定が行われてます。
また自分だけの環境にならないように、仮想マシン作成＆デプロイ用のスクリプトも生成されます。
※Webサイトにした場合もどうようのスクリプトが生成されます。
Azure Resource Managerと違いますが、設定がJSONで保存されてます。このあたり統合されていくんでしょうかね…まだわかりませんが。
さて、実際にどうやってデプロイ等しているかというと、同じく生成されるPowerShellスクリプトモジュール（.psm1）にデプロイ用のモジュールと、実際にそのモジュールを使ってデプロイするスクリプトを使います。
このスクリプトモジュール、よくできてると思うので早く本家にマージされるといいですね。
なおスクリプトに関する詳細はこちら
さて仮想マシンのデプロイが終わったら、後は通常のWebアプリケーションと同じようにWebDeployで発行できますし、Zipパッケージにして、生成されたPowerShellスクリプトを使って発行することもできます。
開発者がいちいち管理ポータルでちまちま仮想マシンやらWebサイトやら作る必要もなく、開発だけに専念して展開や本番環境の調整は別の人が行ったり、スクリプトを使って自動化したりできるのは嬉しいですね。
Azureの説明の際にどんとPaaS/IaaSといいだした背景は案外こんなところかもしれません。
デバッグ方法
そいやデバッグ方法について記載してなかった感（タイトル詐欺）。
Visual Studioのサーバーエクスプローラーから対象の仮想マシンを選択して「デバッグの有効化」を行った後、デバッガをアタッチしてデバッグしたいプロセス（w3wpとか）にアタッチするだけです。はい。
簡単ですね。
Azure Resource Manager
Azure Resource Managerって何ですか？ というのをいつも通り適当に書いておきたいと思います。
適当は嫌じゃ、という方は //build/ 2014 と TechEd 2014 NA のセッションとかを見たほうが早いかもしれません。
ブチザッキ 