3.3. アプリケーションを実装する

Windows Azureオフィシャルサイトの解説記事でも前ページまでの内容については解説されていますが、以下では、実際のアプリケーションを実装してデプロイする場合に考慮するべき点について説明します。

3.3.1. SQL データベースの使用

データ保管先としてWindows Azure SQL データベースを使用する場合は、必要な各種のソフトウェアやライブラリをローカルコンピュータ上にインストールする必要があります。インストール手順に関する詳細はクラウドサービスの場合と同様ですので、Windows Azure SQL データベースを使用するを参照ください。モデルとデータベースの同期はWebサイトへのデプロイの前にローカルコンピュータから実行しておきます。以下での説明の内容を実際に試す場合はadminアプリケーションを有効化のうえでデータベースの同期を実行してください。

またpyodbcやdjango-pyodbc-azureなど、アプリケーションから使用するライブラリを新たにローカルコンピュータ上のPythonランタイムにインストールした場合はその都度、Pythonラインタイム内のsite-packagesフォルダをプロジェクトの中にも上書きコピーのうえ、デプロイの対象としてローカルのGitリポジトリにコミットしてください。

なおWebサイトのサーバ上にはSQL Server 2012のドライバが予めインストールされていますので、SQL Serverドライバについてはデプロイの対象に含める必要はありません。

3.3.2. 静的ファイルの供給

Windows Azure WebサイトでもHTTPリクエストはIISが処理するため、Djangoアプリケーションを実行するに当たっては静的ファイルの収集を予め行っておく必要がある点はクラウドサービスの場合と同様です。

Webサイトを作成するで説明した内容でWebサイトのハンドラーマッピング設定を行った場合、静的ファイルに対するリクエストを含め全てのHTTPリクエストがアプリケーションに転送されてしまうため、この点についてもクラウドサービスの場合と同様に、正しく供給されるため構成をとる必要があります。

アプリケーションとは別に、Windows Azure BLOBストレージや、別のWindows Azure Webサイトに静的ファイルを配置することでも供給は可能となりますが、この場合、アプリケーションとは別に静的ファイルのデプロイも別途必要になってしまうなどの欠点もあります。

クラウドサービスのケースで紹介した静的ファイルを供給するの場合と同様に、アプリケーションと静的ファイルを同一のWebサイトにデプロイできればそれが最もシンプルです。ただしこの点に関するクラウドサービスとの違いは、Webサイトではリクエストハンドラの名前が動的に決定されるため、特定コンテンツの処理に関して定義済みリクエストハンドラの名前を指定して除去するための設定ファイルを事前に記述しておくことが難しいということです。

以下はWebサイト上のアプリケーションでエラーが発生した場合の詳細エラーページの内容ですが、「Handler」として表示されているリクエストハンドラの名前の末尾に付加されているUUIDを確認できます。

ここでは、上記の制限を回避し、アプリケーションと同じWebサイト上に静的ファイルを配置して供給するための方法について説明します。

警告

以下に説明する内容は公式にサポートされているものではありませんので、実際に運用するアプリケーションでの利用は自己責任で行ってください。

3.3.2.1. 静的ファイルの収集

静的ファイルの収集に関する手順は一般のDjangoアプリケーション開発の場合と同様です。詳細は静的ファイルを供給するを参照ください。

3.3.2.2. 管理ポータルからのハンドラーマッピング設定

上述の通り、Webサイトを作成するにある内容でハンドラーマッピングを登録してしまうと、静的ファイルの供給ができません。ただし管理ポータル上でハンドラーマッピングを何も登録しておかないと、そのWebサイト上でFastCGIモジュールが有効とならず、アプリケーションが全く動作しなくなってしまうため、ダミーのハンドラーマッピングを登録しておきます。

このハンドラーマッピングはWebサイト上でFastCGIモジュールを有効にすることだけを目的としたものであり、実際にこのハンドラにリクエストが転送されないよう、通常のアプリケーションでは使用されないような拡張子のみ受け付けるよう設定しておきましょう。

3.3.2.3. Webサイト設定ファイルの追加

管理ポータルで登録したハンドラーマッピングとは別に、Webサイト設定ファイルをプロジェクトの直下に追加し、そこでもハンドラーマッピングを記述します。こちらで指定するハンドラーマッピングが、アプリケーションのリクエストを処理するための実体となります。Webサイトの名前はサイト作成の段階で一意性が保証されていますので、ハンドラー名（add要素のname属性値）にサイト名を含めておくとよいでしょう。

<?xml version="1.0"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="FastCGI_python-website"
           path="*"
           verb="*"
           modules="FastCgiModule"
           scriptProcessor="D:\Python27\python.exe|D:\home\site\wwwroot\wfastcgi.py"
           resourceType="Unspecified"
           requireAccess="Script" />
    </handlers>
  </system.webServer>
</configuration>

そして、静的ファイル収集先のディレクトリにも、以下の内容でweb.configファイルを作成します。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <remove name="FastCGI_python-website" />
    </handlers>
  </system.webServer>
</configuration>

ここまでの変更で、プロジェクトの内容は以下のようになっていると思います。

変更内容をローカルのGitリポジトリにコミットし、さらにその内容をWebサイトのリモートリポジトリにプッシュします。リモートリポジトリへのプッシュが完了後、Webサイト上のDjango管理サイトのURLにアクセスし、静的ファイルの適用を含む適切な画面表示が行われることを確認してください。

3.3.3. 他のWebアプリケーションフレームワークの使用

クラウドサービスにおいてDjango以外のWebアプリケーションフレームワークを使用する方法は他のWebアプリケーションフレームワークを使用するにて説明しましたが、Webサイトでもまた同様に、Django以外のWebアプリケーションフレームワークを使用することができます。

この場合は、使用するWebアプリケーションフレームワークとアプリケーションをデプロイのうえ、管理ポータルのアプリ設定「WSGI_HANDLER」にて、使用するWebアプリケーションフレームワークで利用可能なWSGI準拠のPythonオブジェクトを指定してください。