Windows Azure SDK 1.3 を使用してFull IISなWeb RoleをWindows Azure上に展開した際、Web.configに指定していたMachineKeyが上書きされる（IISによって自動設定される）という問題がありました。
※ただし最初の仮想サイトのみ。追加した仮想サイトや仮想アプリケーションは影響受けない（だったと思う）
さて、こちらの問題ですがこの間リリースされた Windows Azure SDK 1.4 では修正されているので、困ってた方はSDK 1.4を採用することも検討頂くといいのではないでしょうか。
他の問題もいろいろ修正されてるようですし。。。
ただまぁSDK1.2 以降でがらっと変わってる部分もあるので一概にOKとは言えないかもしれませんが。
前回Squidを利用してキャッシュ・リバースプロキシサーバーを構築しましたが、Squid版では以下の問題がありました。
これらはURLのRewriteをリバースプロキシな処理の中で行えば解決しますが、外部公開サイトに対してはいろいろグレー＋Squidだと少し面倒でした。
さて代替方法として（緊急で対応する必要もだいぶ減ったので）IIS＋Application Request Routing 2.0を使用してキャッシュ、リバースプロキシ、URL Rewriteを行いたいと思います。
※今回実装にあたってはMicrosoftさんを始めJAZUな面々、多数の方にご協力頂きました。ありがとうございます。
デプロイパッケージを作成するにあたって実装している点は以下の通りです。
コードはやっつけ仕事もいいとこですね。
成果物はこちらからダウンロードください。
利用方法は上記パッケージをダウンロードしてDeployPackageフォルダにある .cscfg のインスタンス数や対象URL、公開URLを修正してデプロイするだけです。
今は1：1の書き換えしか対応できません。もし1つのサーバーで複数展開する場合は現状のコードでは対応できませんので、RDPの設定をして頂き、展開後手動でIIS+ARRの設定を行ってください。
非常時用ですのでこんな感じです。
CDNを利用する場合や、より細かな対応、本格的にAzure化する為にコンテンツホルダーとの調整が必要な場合等は こちらのサイト を参考にして頂き、Microsoftさんへコンタクトを取っていただくのもよいと思います。
3月11日、東北地方太平洋沖地震が発生しました。私のほうではうまく表現できません。ただ心より祈るばかりです。
とはいっても、できることはないだろうか？と漠然と思っていたところ、日本赤十字社のサイトが過負荷で見えない、という話題が流れていました。
ぱっと思いついたのはとりあえずキャッシュサーバーとリバースプロキシを組み合わせて負荷を軽減できないか？ということでした。
幸い、リソースはWindows Azureですぐに展開できますし、SquidとDelegateは少し触ったことがあったので @halmnm を巻き込んでSquidを構築することに決めました。
並行してMicrosoftさんがAzure Passの９０日無償開放、4インスタンス、転送量無制限という臨時仕様で解放してくれました。ありがとうございます。
タイトルはホッテントリメーカーで生成しました。内容とはあまり関係ないと思われます。
さてWindows Azure CDNが新しくなったので、試してみました。
目玉としては、
だと思うので（QueryStringでどうのこうのもありそうですが検証が大変そうなので今回は置いておきます）、それぞれ見てみようと思います。
ということでWindows Azure SDK 1.4がリリースされました。
変更点等現時点で気づいた点を列挙しておきます。
前回の続きです。前回はこちら → Azure AppFabric ACS v1+ADFS+WCF Data Services
今回は実際にフェデレーション認証を利用するサービスとクライアントを作成します。
サービス側はWCF Data Servicesを利用して、トークンが有効な場合のみデータ（Entity）を返すようにします。
クライアントはActive Federation認証を行いますので、ADFS2.0とACSv1を使用し得られたトークンと利用してWCF Data Servicesにアクセスしデータを取得します。
ではまずサービス側から。
今日はWindows Azure AppFabric Access Controle Service v1 （現行）（以下ACSv1）とActive Directory Federation Services 2.0 （以下ADFS）を組み合わせてWCF Data ServicesをActive Federation認証してみようと思います。
WCF Data Servicesを利用するクライアントは今回はブラウザではなく、Windowsアプリとします。なのでブラウザが自動リダイレクトして認証画面に飛ぶようなPassive Federation認証ではなくActive Federation認証です。（自前でトークンのやり取りします）
そもそも、現行のACSv1はPassive Federationに対応していませんし、マルチテナントを考えるとちょっとWindows Identity Foundation（以下WIF）についてるFederation Utilityは使えないのでほぼコードでいろいろ制御することにします。
はっきりいって、ACSv2が出るまでのつなぎですね。ちなみに今回のネタはWIF トレーニングキットに付属するハンズオンラボ（IntroAppFabricAccessControl）を見ながらやればある程度できると思います。
今回想定している環境はこんな感じです。
※見ての通り（？）、WCF Data ServicesとSQL ServerはWindows Azure＋SQL Azureでもまったく問題ありません。
では準備から。
前回のPOSTをしてからいろいろ教えていただきました。
まずMicrosoft Federation Gatewayが信頼してくれるルート証明機関（CA）ですが、以下のTechNetに記載がある通りとなるようです。
トラブルなしでMicrosoft Federation Gatewayとフェデレーションしたかったら記載のルートCAが発行するX.509証明書のほうがいいでしょうね。
さて結構なお値段がする証明書ですが、価格がお安めの証明書をいくつか教えていただきましたのでこちらも記載しておきます。
この中でMicrosoft Federation Gatewayに対応できそうなのはGoDaddyとCOMDOですかね。GeoTrustは親会社がベリサインですが、CA的にどうなのかは見たことないので不明です。
COMDOは90日間フリーなので使い方次第では凄い助かるかもですねー。
ちなみに先日のニュースリリースでGeoTrustがワンコインSSLなるサービスを発表しています。
※Amazon EC2のユーザーのみ対象ですけどね…
今日ちょっとなやんでしばやん先生に即答してもらったのでメモ。
まずリソースファイルをPublicにしておきます。要確認。
リソースファイルのプロパティでカスタムツールを PublicResXFileCodeGenerator にしてビルドアクションで”埋め込まれたリソース”にしておきます。
あとはデータアノテーションのところでリソース指定するだけ。
例：ASP.NET MVCで既定で生成されるAccountModelなど
[Display(ResourceType = typeof(YOURNAMESPACE.App_GlobalResources.StringResources), Name = "ResUserName")]
public string UserName { get; set; }
超簡単ですね。
ASP.NET MVC3での多言語対応はこちらも参照。
ただこれやって発行したりするとリソースDLLはできてるんだけど読み込めないみたいなんですよね。なんでだろ。。まだ調べてる途中なのでわかったら追記等します。
2011.02.23 追記
いろいろ見てると以下の事がわかりました。
ということでGetGlobalResourceObjectが問題。Webアプリケーションの発行先にApp_GlobalResourcesフォルダ（と.resxファイル）があれば問題なく動作しますが、埋め込みリソースとしてビルドするとアセンブリに埋め込まれて（あとサテライトアセンブリが出来て）発行先にはApp_GlobalResourcesフォルダは含まれません。
で、この状態でGetGlobalResourceObject呼び出すとNGと。嵌ってた状況はこんな感じです。
じゃぁどうやってアクセスするんだ？というと単純にリソースは既にPublic化されているわけですから
@MvcApplication1.App_GlobalResources.StringResources.String1
みたいにしてあげればいいわけですね。やぁ長かったよ。
参考にしたサイトはこちら。
ゼロから始めるといろいろ壁にあたりますね～。
ブチザッキ 