今日は、実際にWindowsAzureでアプリケーションを開発する上でのポイントを書きます。
開発環境（仮想環境）での作成は簡単です。
新しいプロジェクト→Cloud→WindowsAzureCloudService
で、WebRoleを追加
WebRoleというのが従来のASP.NET部分です。
違う点といえば、自動的にWebRole.cs（C#の場合。vbは.vb）というクラスファイルが自動的に追加されていて、
中を見るとRoleEntryPointを継承しているクラスで、OnStartとRoleEnvironmentChangingという２つのメソッドが予め記載されています。
これはWebRoleが開始された時に、設定ファイルが変更された時のイベントハンドラを追加するのと、
設定ファイルが変更された時にWebRoleを再起動するようにする処理が記載されています。
ログを出力したい場合等は、OnStartメソッドに色々と追記します。
ここらへんは下記の記事が詳しいです。
それ以外は通常のASP.NETと変わりませんので、ASPXを追加して色々開発しましょう。
で、F5押したら仮想環境が起動して、アプリもブラウザで開きます。
開発したアプリは折角ですのでAzureにデプロイしましょう。
DBもStorageも使ってない場合、何もかえずともデプロイは可能です。
ただし、依存するDLLが独自のものであったり、サードパーティ製だったりするものについてはデプロイパッケージへ配置が必要です。
MS謹製であっても、後からインストールが必要なライブラリについては配置する必要があります。
BugLogではグラフをMSChartのSystem.Web.DataVisualization.dllを使用して表示しているのですが、
これも配置が必要でした。
参照設定で.NETのタブにあるからって安心してはいけません。
デプロイしてステータスがReadyになるまで大体10~15分かかるのですが、
DLLが足りなかったり設定ファイルがよろしくなかったりすると、ReadyにならずにStoppingとかStoppedになったりします。
20分超えてもReadyになってなかったら失敗してる可能性大です。
失敗してもリトライしてループするので、そもそも失敗しているかどうかはわかりません。
いたずらに時間を浪費しないためにも、Stoppingとか見えたら配置ファイルを見直しましょう。
発行先のフォルダに「buglog（プロジェクト名）.csx」というフォルダが出来ていて、その中にすべての配置されるファイルが入っています。
Staging（テスト用）にデプロイした場合、発行されるURLは一時的なもので、
Azureのアカウントを持ったクライアントからでないとアクセスできません。
StagingからProductionへ移すのは、真ん中にあるswap的なボタンを押せばOKです。
次回はWindowsAzureのStorageを使用して、ASP.NETのForm認証（MemberShip）を実現する方法を書こうと思います。
※追記9/24 18:29※
ProductionへのSwapについて、Productionに配置済みの場合、Stagingの版と入れ替わります。
これは、ProductionとStagingの仮想IPを入れ替える仕組みだからだそうな。
で、EndPointが変わったりするとSwapできませんとDrWatsonに怒られる。
こうゆうときはおとなしくProdctionを削除してからSwapするか、両方消して直にProductionに配置するとかしましょう。
0 件のコメント:
コメントを投稿