Code 2015 in 定山渓温泉で学んだ Flask による Web アプリを Azure Web Apps に配置してみる

今年も、定山渓温泉の温泉ホテルに一泊二日で泊まり込みのプログラマ向けイベント「Code 2015 in 定山渓温泉」を主催してきた。

そのなかの勉強枠で、Python によるシンプルな Web アプリフレームワークである Flask を使った Web アプリ作成の入門を果たした。

ただし70分枠のあくまで入門編だったので、手持ちの PC 上での実践までとなり、インターネット上に公開するところまでは触れなかった。

Code 2015 in 定山渓温泉から帰ってきて、折角なので Flask Web アプリをインターネット上に公開することに挑戦してみた。

公開先は、自分が慣れている PaaS である Microsoft Azure Web Apps (旧称 Azure Websites) にしてみた。
今回は学習の意図なので、ありがたくAzure Web Apps の無料プランで使わせてもらう。

Azure Web Apps に Web アプリコンテンツを送り込む手段としては Git を使うことにした。
すなわち、Web ブラウザで Microsoft Azure の管理ポータルサイトにサインインし、そこで Web Apps サイトをひとつ追加し、Git を使用してコンテンツを送り込む旨設定を済ませると、その Web Apps サイトに付属の Git リポジトリが作成され、同時に発行される HTTPS な URL に宛てて、手元のローカルリポジトリからプッシュできるようになる。

なお、Azure Web Apps サイトを追加するにあたっては、素の空のサイトとして新規追加するだけでなく、あらかじめ各種設定がプリセットされた "テンプレート" を選んで新規追加することもできる。

その "テンプレート" の中には、そのものズバリの「Flask」というテンプレートもある。
この「Flask」テンプレートを選んで新規 Azure Web Apps を追加し、それを開始地点として、手元のローカル開発に git clone して作りこみを進めることも可能だ。

ただし今回は、Code 2015 in 定山渓温泉当日に作成した Flask Web アプリをそのまま Azure Web Apps に搭載することを目指したため、素の空の Azure Web Apps を新規追加してそこに git push して稼働させる手順について、自分なりにまとめてみた。

なお、前提として、今回使用した Pythonのバージョンは v.3.4 で、また、virtualenv による仮想環境フォルダを作成して Flask はじめ必要なパッケージはこの仮想環境フォルダに収録する形態で実装してある。

追加で必要となるファイルや、従うべき規約

ローカル開発環境で作成した Flask Web アプリのコンテンツを、そのまま Azure Web Apps に git push しても、さすがに動いてはくれない。
Azure Web Apps にしてみたら、Python 処理系のバージョンは 2.7系か3.4系かいずれを使えばよいかわからないし、HTTP要求を受け取るオブジェクトもどれを使えばよいのかわからないからである。

そこで以下で示す規約に従うようにしたり、追加のファイルが必要となる。

1. requirements.txt を作成、git リポジトリにコミットしておく

Azure Web Apps に配置するかどうかに関係なく、「pip freeze」の標準出力の内容、すなわち必要とするパッケージを記載した「requirements.txt」をバージョン管理リポジトリに登録しておくのが普通だろう。

「requirements.txt」があれば「pip install -r requirements.txt」を実行することで、必要パッケージを再配置することができるわけだ。

手動で「pip install -r ～」を実行するのでれば、「requirements.txt」はこれとはことなるファイル名でも構わないことだろう。

しかし PaaS である Azure Web Apps は、送り込まれたコンテンツに「requirements.txt」というファイルがあることで「pip install -r ～」を実行するようなので、ファイル名は確実に「requirements.txt」にしてコミットしておく。

2. runtime.txt を作成、git リポジトリにコミットしておく

先に書いたように Azure Web Apps にしてみたら、送り込まれたコンテンツはどんな処理系で書かれた Web アプリなのか、ただそれだけでは判断がつかない。

そこで Azure Web Apps では、送り込まれたコンテンツの中に「runtime.txt」というファイルが含まれていたらこのファイルの内容を確認し、「python-3.4
」とテキストで書かれていたら、「ああ、これは Pyhthon v.3.4 上で動作する Web アプリなんだな」と判定するらしい。

ということで、「python-3.4」と書かれたテキストファイル「runtime.txt」を作成し、リポジトリにコミットしておく。

3. virtualenv の仮想環境フォルダ名は env にする

Azure Web Apps は、送り込まれたコンテンツから「ああ、これは Pyhthon v.3.4 上で動作する Web アプリなんだな」と判定したら、virtualenv による仮想環境フォルダを作成するようだ。

このときの仮想環境フォルダ名は、Azure Web Apps は「env」という名前で作成するらしい。

ローカル開発環境とは直接関係しない場合もあるが、Windows OS でのローカル開発環境で IIS Express 上で稼働させながら開発する場合などは、ローカル開発環境でも仮想環境フォルダ名は「env」に揃えておいた方が無難だ。

4. env/Scripts フォルダに activate_this.py を追加、コミットしておく

仮想環境フォルダ「env」およびその中身は、バージョン管理にコミットしておく必要はない (pip install などで復元されるので)。
.gitignore ファイルにも「env フォルダはバージョン管理に追加しない」と記載しておくことだろう。

しかしながら、Azure Web Apps 上に配置した Web アプリが仮想環境フォルダを活性化しようとするにあたり、「env/Scripts/activate.bat」は使えないようだ。

これは想像に過ぎないが、Python によるプロセスがバッチファイルなどを実行すると cmd.exe による外部プロセス実行となり、環境変数の設定は呼び出し元の親プロセスには反映されないからかもしれない。

ということで代替手段が必要なのだが、それが「activate_this.py」になる。

このファイルはもとは誰が作成したものなのか知らないのだが、冒頭で触れた、Azure Web Apps の Flask テンプレートから作成したサイトだと、env/Scripts フォルダに配置されていた。

これを入手し「env/Scripts/activate_this.py」としてリポジトリにコミットしておく。

5. ptvs_virtualenv_proxy.py を入手、コミットしておく

ptvs_virtualenv_proxy.py は、HTTP 要求を受け取る入り口だ。
もちろん通常であれば、こんな別の Python スクリプトを持ち出さなくても、自作した Flask Web アプリとしてのコードのどれかが HTTP 要求の入り口、エントリポイントになるところだ。

しかし先の説明のとおり、virtualenv による仮想環境フォルダの活性化を実施しておく必要があるのだが、そのタイミングとしてふさわしい場面が Azure Web Apps には用意がないようだ。
そこで ptvs_virtualenv_proxy.py を HTTP 要求の入り口第一弾として設置し、この ptvs_virtualenv_proxy.py の中で仮想環境フォルダ「env」の活性化を行ってから、それから開発者が作成した "真の" エントリポイントへ処理を譲る、という仕組みにするらしい。

ptvs_virtualenv_proxy.py も、冒頭で触れた、Flask テンプレートを選んで新規追加した Azure Web Apps サイトのコンテンツに収録されていた。
「ptvs_virtualenv_proxy.py」というファイル名の先頭が「ptvs」すなわち「Python Tools for Visual Studio」であることから、もともとは Python Tools for Visual Studio の構成要素のひとつらしい。
Coyright は Microsoft で、Apache 2.0 License となっている。

ptvs_virtualenv_proxy.py を入手、リポジトリにコミットしておく。

6. web.config を作成、コミットしておく

さて、Azure Web Apps の Web サーバーは IIS だ。
そして IIS に対する構成は「web.config」という XML 形式のファイルで記述することになる。

この「web.config」で、これまで説明してきたファイルや規約を紐づけていく、集大成となるのだ。

必要最小限の「web.config」の記述例は以下のとおり。

<?xml version="1.0"?>

<configuration>

  <appSettings>

    <add key="PYTHONPATH" value="%ROOTDIR%" />

    <add key="WSGI_HANDLER" value="ptvs_virtualenv_proxy.get_virtualenv_handler()" />

    <add key="WSGI_ALT_VIRTUALENV_ACTIVATE_THIS" value=".\env\Scripts\activate_this.py" />

    <add key="WSGI_ALT_VIRTUALENV_HANDLER" value="app.app" />

  </appSettings>

  <system.webServer>

    <modules runAllManagedModulesForAllRequests="true" />

    <handlers>

      <add name="Python FastCGI" path="handler.fcgi" verb="*" modules="FastCgiModule" scriptProcessor="D:\Python34\python.exe|D:\Python34\Scripts\wfastcgi.py" resourceType="Unspecified" requireAccess="Script" />

    </handlers>

    <rewrite>

      <rules>

        <rule name="Configure Python" stopProcessing="true">

          <match url="(.*)" ignoreCase="false" />

          <action type="Rewrite" url="handler.fcgi/{R:1}" appendQueryString="true" />

        </rule>

      </rules>

    </rewrite>

  </system.webServer>

</configuration>

先に説明したとおり、HTTP 要求の入り口第一弾には ptvs_virtualenv_proxy.py 内で実装されたハンドラを指定する必要がある。
HTTP 要求を渡す先を指定するのが WSGI_HANDLER アプリケーション構成項目であるが、まさしくここに "ptvs_virtualenv_proxy.get_virtualenv_handler()" を指定してある。

そして、ptvs_virtualenv_proxy.py が、内部で仮想環境フォルダ「env」を活性化したあと、HTTP 要求処理を譲る "真の" HTTP要求ハンドラを指定するのが「WSGI_ALT_VIRTUALENV_HANDLER」アプリケーション構成項目だ。

この「WSGI_ALT_VIRTUALENV_HANDLER」アプリケーション構成項目は、作成した Flask Web アプリのコードに応じて個々に指定する必要がある。

上記「web.config」の例では「app.app」と書いてるが、これは Code 2015 in 定山渓温泉で習った際に作成した Flask Web アプリが、「app.py というスクリプトファイルにて、"app = Flask(__name__)" とコーディング」したからである。

これがもし「foo.py というスクリプトファイルにて、"bar = Flask(__name__)" とコーディング」したのならば、同構成項目には「foo.bar」と記述することになるはずである。

以降、Python の Fast CGI 機構を登録したり、すべての HTTP 要求を Python Fast CGI に渡すよう URL リライトを構成したりする構成が続く。

以上の処置を済ませたリポジトリを Azure Web Apps に git push することで、Flask による自作 Web アプリを Azure Web Apps に配置、インターネットに公開することができた。

成果と補足

以上の成果を反映したサンプルは、GitHub における Code in 定山渓温泉のグループアカウント以下のリポジトリとして公開してある。

https://github.com/codejp/code2015-my-1st-flask

また、本ブログ記事で説明した内容は OS プラットフォームに依らず実践可能だが (git コマンドとテキストエディタがあればできるだろう)、Code 2015 in 定山渓温泉の当日、受講するにあたり、自分は、利用条件さえ合えば無償で使えるエディションの Visual Studio でも利用可能な「Python Tools for Visual Studio」をインストール済みの Visual Studio 2015 を使って、作業を行った (下図のとおり、Visual Studio 2015 のインストール時の機能選択ダイアログに、選択肢として表示されている)。インテリセンスのお蔭で、打鍵数も少なく、かつタイポもあり得ないので、躓くこともなくサクサクと受講することができた。
こんな環境を無償で利用させてもらえるとは (フリーミアム戦略とはいえ) ありがたい限りである。

まとめ

ローカル開発環境で作成した Flask Web アプリは、以下の処置を済ませてコミットした git リポジトリをプッシュすることで、Azure Web Apps に配置して稼働させることができる。

1. requirements.txt を作成、git リポジトリにコミットしておく
2. runtime.txt を作成、git リポジトリにコミットしておく
3. virtualenv の仮想環境フォルダ名は env にする
4. env/Scripts フォルダに activate_this.py を追加、コミットしておく
5. ptvs_virtualenv_proxy.py を入手、コミットしておく
6. web.config を作成、コミットしておく

いかがだろう。

個人的な感想としては、意外とやるべき手順が多いなという印象。
これが他の PaaS、例えば Heroku などであれば配置手順はどうなるのか、気になるところだ。