今日の13時にWindows Azure AppFabric本番環境のメンテが終わり、ついにACSv2がプロダクションとして正式サービスにきました!!まってました!
Cloud
CSPack を使って CSRun したり Startup Tasks を使ったりしたい
CSPack で Windows Azure デプロイパッケージを作成する
なぜ Windows Azure Tools for Visual Studio があるのにわざわざCSPackなのか。答えはそこに運用があるから。
とか適当に言ってみましたが、今日はCSPackのお話しです。
CSPack.exeは簡単にいうとWindows Azureのホストサービス上に、展開する際に必要な各ロールのファイル群が固まっているデプロイ用パッケージファイル(.cspkf)を作成する、Windows Azure SDKに含まれるコマンドラインツールです。
結局のところ Windows Azure Tools for Visual Studio も発行メニューから最終的なパッケージを作る際にCSPackを呼び出すか同等の事をやっています。
で、最初の一言に戻りますが、なんでVisual Studio等のIDEで簡単にやってくれるのにわざわざコマンドラインツールが必要なの?というところですが、逆に言うとVisual Studioなりのツールない人はどうするの?という問題を解決するにはこのCSPackしかないのですよね。
小規模であれば、開発する人、Windows Azureにデプロイする人、Azureに関連する技術に詳しい人は同一人物か、もしくは少人数なので対して問題にはなりませんがそれなりの規模を回すとなると必ず分業することになってくると思います。
今回はそういった分業する際のある程度の指針と、実装方法を考えると共にCSPackでのパッケージ作成を紹介したいと思います。
Windows Azure の Full IIS で MachineKeyが上書きされる件
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とは言えないかもしれませんが。
Windows Azure + ARR で勝手キャッシュ・リバースプロキシサーバーを構築する
前回Squidを利用してキャッシュ・リバースプロキシサーバーを構築しましたが、Squid版では以下の問題がありました。
- Locationヘッダ等によるリダイレクトを抑制できない
- 絶対パスのリンクを書き換えられない
これらはURLのRewriteをリバースプロキシな処理の中で行えば解決しますが、外部公開サイトに対してはいろいろグレー+Squidだと少し面倒でした。
さて代替方法として(緊急で対応する必要もだいぶ減ったので)IIS+Application Request Routing 2.0を使用してキャッシュ、リバースプロキシ、URL Rewriteを行いたいと思います。
※今回実装にあたってはMicrosoftさんを始めJAZUな面々、多数の方にご協力頂きました。ありがとうございます。
デプロイパッケージを作成するにあたって実装している点は以下の通りです。
- WebPICmdLineツールを使用してStartup TasksでARRのインストール(依存するWeb Farm Frameworkもインストール)
- 設定の簡略化のためにApplicationHost.configを直接書き換え(そのためにRoleのEntryPointが特権で動作するように設定)
コードはやっつけ仕事もいいとこですね。
成果物はこちらからダウンロードください。
利用方法は上記パッケージをダウンロードしてDeployPackageフォルダにある .cscfg のインスタンス数や対象URL、公開URLを修正してデプロイするだけです。
今は1:1の書き換えしか対応できません。もし1つのサーバーで複数展開する場合は現状のコードでは対応できませんので、RDPの設定をして頂き、展開後手動でIIS+ARRの設定を行ってください。
非常時用ですのでこんな感じです。
CDNを利用する場合や、より細かな対応、本格的にAzure化する為にコンテンツホルダーとの調整が必要な場合等は こちらのサイト を参考にして頂き、Microsoftさんへコンタクトを取っていただくのもよいと思います。
Windows Azure + Squid による勝手キャッシュ&リバースプロキシサーバーの構築
3月11日、東北地方太平洋沖地震が発生しました。私のほうではうまく表現できません。ただ心より祈るばかりです。
とはいっても、できることはないだろうか?と漠然と思っていたところ、日本赤十字社のサイトが過負荷で見えない、という話題が流れていました。
ぱっと思いついたのはとりあえずキャッシュサーバーとリバースプロキシを組み合わせて負荷を軽減できないか?ということでした。
幸い、リソースはWindows Azureですぐに展開できますし、SquidとDelegateは少し触ったことがあったので @halmnm を巻き込んでSquidを構築することに決めました。
並行してMicrosoftさんがAzure Passの90日無償開放、4インスタンス、転送量無制限という臨時仕様で解放してくれました。ありがとうございます。
誰も知らなかったWindows Azure CDN
タイトルはホッテントリメーカーで生成しました。内容とはあまり関係ないと思われます。
さてWindows Azure CDNが新しくなったので、試してみました。
目玉としては、
- Web/VMロールでCDNサポート
- HTTPSなエンドポイントをサポート
だと思うので(QueryStringでどうのこうのもありそうですが検証が大変そうなので今回は置いておきます)、それぞれ見てみようと思います。
Windows Azure SDK 1.4 now Available!
ということでWindows Azure SDK 1.4がリリースされました。
変更点等現時点で気づいた点を列挙しておきます。
Azure AppFabric ACS v1+ADFS+WCF Data Services (2)
前回の続きです。前回はこちら → Azure AppFabric ACS v1+ADFS+WCF Data Services
今回は実際にフェデレーション認証を利用するサービスとクライアントを作成します。
サービス側はWCF Data Servicesを利用して、トークンが有効な場合のみデータ(Entity)を返すようにします。
クライアントはActive Federation認証を行いますので、ADFS2.0とACSv1を使用し得られたトークンと利用してWCF Data Servicesにアクセスしデータを取得します。
ではまずサービス側から。
Azure AppFabric ACS v1+ADFS+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でもまったく問題ありません。
では準備から。
