なぜ 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に詳しくない Web開発者がWebアプリを作成
- Windows Azureに詳しい開発者がサービス定義ファイルや細かな設定、ロール固有の部分を作成
- 開発系は疎いITProがパッケージの作成とデプロイを行う
Webアプリケーションの作成
ではですね、非Azureな環境でWebアプリを開発していきます。
まぁサンプルなので手をほとんどいれずやります。
- 普通にVisual Studioを使用してASP.NET Webアプリケーションを作成
- 発行メニューを使用してWebアプリケーションを発行
以上です。書くほどでもないですね。
発行されたファイル群は運用担当の方（ITPro）に渡しましょう。（ということにして進めます）
ロールエントリーポイントの作成
次にWindows Azure固有の部分の開発です。
Visual Studio等でクラスライブラリプロジェクトを作成し、RoleのEntryPointを作成します。
※.NET Framework のターゲットは3.5もしくは4.0である必要があるので注意
RoleEntryPointを継承したクラスを作成して適当に実装してきましょう。Windows Azureに関連するアセンブリはWindows Azure SDKの以下のフォルダにありますので必要に応じて参照します。
C:\Program Files\Windows Azure SDK\v1.4\ref
分業でするならたとえばストレージへのアクセスだとか、そういうのも担当してもいいですね。
以下サンプルです。
using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.WindowsAzure;
using Microsoft.WindowsAzure.Diagnostics;
using Microsoft.WindowsAzure.ServiceRuntime;
namespace AzureEntryPoint
{
public class WebRole : RoleEntryPoint
{
public override bool OnStart()
{
//ToDo:必要な処理を追加しましょう
return base.OnStart();
}
}
}
さてコードかけたらビルドして出来上がったDLLを運用担当の方に渡しましょう。（ということにして進めます）
パッケージの作成とデプロイ
では本題のCSPackを使用してパッケージを作成する、運用担当の方の出番です。
運用担当の方はWindows Azure上で動作させるためのサービス定義ファイル及びサービス設定ファイルの作成、パッケージの作成と配置を行います。
※サービス定義・設定ファイルはAzureに詳しい人が書いてもいいと思いますが。
まずMSDNとニラメッコしてサービス定義ファイルを作成しましょう。
ServiceDefinition.csdef
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="CSPackTest" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WebRole name="WebRole1">
<Sites>
<Site name="Web">
<Bindings>
<Binding name="Endpoint1" endpointName="Endpoint1" />
</Bindings>
</Site>
</Sites>
<Endpoints>
<InputEndpoint name="Endpoint1" protocol="http" port="80" />
</Endpoints>
</WebRole>
</ServiceDefinition>
こんな感じで。
サービス設定ファイルも作成してもいいのですが、CSPackで生成することが出来るのでそうしたほうが間違いがないかもです。
（設定すべき値等を入力する必要がありますが）
これでデプロイパッケージの作成に必要なファイル群がそろいました。
デプロイパッケージの作成には
- サービス定義ファイル（.csdef）
- アプリケーションファイル
- ロールのエントリポイント（とロールに関する設定をまとめたプロパティファイル）
が必要です。※ロールのエントリポイントなくても一応パッケージングできますがちゃんと動かない気が。
アプリケーションファイルとロールのエントリポイントなんかはWorkerロールの場合、同一になるケースもありますね。
またVM Roleはそもそもロールのエントリポイントが無いので不要です。
※あらかじめVHDファイルをUploadしてるので、 .csdefを作ってパッケージングだけすればいい
ロールのプロパティファイルには以下の内容を含めます。
TargetFrameWorkVersion=v4.0 EntryPoint=AzureEntryPoint.dll
ターゲットフレームワーク（v3.5かv4.0）と、エントリポイントがあるアセンブリのファイル名を記述するだけです。
上記をまとめたフォルダ構成はこんな感じです。
ではWindows Azure SDK Command Promptを起動して上記ファイルがあるフォルダに移動し、以下のコマンドを実行します。
cspack ServiceDefinition.csdef /sites:WebRole1;Web;.\PublishedWebSite /out:cspack.cspkg /role:WebRole1;.\;AzureEntryPoint.dll /rolePropertiesFile:WebRole1;roleproperty.txt /generateConfigurationFile:ServiceConfiguration.cscfg
CSPackの他の引数や詳細はこちらをご覧ください。 → （ CSPack Command-Line Tool ）
エラーなく完了すれば .cspkg ファイルと .cscfg ファイルが生成されていると思います。
必要に応じて .cscfg ファイルの中の設定を編集しましょう。（今回は対して弄るところないのでそのまま）
一度 .cscfg を作成すれば、大幅な変更が無い限り通常再作成することはないと思います。そういう場合はCSPackの /generateConfigurationFile オプションを外せば生成されないので安心です。
Windows Azureにデプロイする際は作成された .cspkg ファイルと .cscfg ファイルがあればOKですので、Windows Azure管理ポータルからデプロイすることができるようになりました。
ぱちぱち。実際にデプロイしてみましょう。動きましたよね？
まとめ
CSPackの説明だけなら1行で済んでしまうのですがダラダラ書きました。如何でしょうか（
今回みたいにCSPackを利用することで、上手く開発者やITProの方と分業もしやすいんじゃないかなと思います。
もちろんアプリケーションをどう組み合わせるか、Windows Azure固有の部分をどうすればよいか等は別問題ですが。
それでも一定規模までの開発や、組織にとって運用しやすい手法になるんじゃないかなと思います。それぞれの担当者も最低限自分がしないといけない専門分野に注力できると思われます。
またASP.NET等に限らず、Eclipseを使ったPHPアプリケーションの場合等もこの手の手法を使うことでWindows Azure SDKの準備など不要になりますし、とっつきやすいと思います。
条件さえ整えば今流行のWebMatrixで開発とかもいけますね。
またコマンドでできるということは、Team Foundation Server と組み合わせてアプリケーションのチェックイン時にテスト→発行→Azureパッケージング→デプロイ 等やろうと思えばできますね～。（本運用にデプロイするのはもちろんNGでしょうけど）
というわけで、↓こんなことができるかもですよ、というお話でした。
ブチザッキ 