Python Web アプリを Azure App Service on Linux に発行する
Visual Studio には、Azure App Service on Linux に Python Web アプリを発行する機能が用意されています。 Azure App Service on Linux への発行には、必要なファイルのサーバーへのコピーや、アプリの起動方法を Web サーバーに指示する適切な web.config
ファイルの設定が含まれます。
Note
App Service で Python アプリを実行できるオペレーティング システムは Linux だけです。 「App Service Linux ドキュメント - Python のサポート」で説明されているように、Python on Windows はサポートされなくなりました。 Windows の場合は、独自のカスタム Windows コンテナー イメージをビルドし、App Service でイメージを実行することができます。 詳細については、「カスタム Docker イメージを使用する」を参照してください。
前提条件
見ることができます。 製品をインストールするには、「Visual Studio のインストール」の手順に従います。
Bottle、Flask、または Django フレームワークに基づく Python Web アプリ プロジェクト。 テスト プロジェクトを作成して、発行プロセスを試すことができます。
Azure に発行するには、Azure サブスクリプションのターゲット Azure App Service が必要です。
Azure サブスクリプションがまだない場合は、無料の完全な Azure アカウントから始めます。 また、Visual Studio Dev Essentials へのサインアップも検討してください
Visual Studio のバージョン
発行プロセスは、Visual Studio 2017 以降と Visual Studio 2015 では異なります。 どちらの方法も、この記事内で説明します。
Visual Studio 2015 は
web.config
ファイルの作成など、インストール手順の一部を自動化しますが、それによって長期的な柔軟性と制御が制限されます。Visual Studio 2017 以降では、より多くの手動のインストール手順が必要ですが、Python 環境をより正確に制御することができます。
Visual Studio 2015 と Visual Studio 2017 以降の間の変更の詳細については、ブログ記事「Publish to Azure in Visual Studio 2017」 (Visual Studio 2017 での Azure への発行) を参照してください。
テスト プロジェクトを作成する
発行する既存のプロジェクトがない場合は、テスト プロジェクトを作成してプロセスを試すことができます。
Visual Studio で、ツールバー メニューから [ファイル] > [新規] > [プロジェクト] を選択して、[新しいプロジェクトの作成] ダイアログを開きます。
ダイアログで、[検索] ボックスに「bottle」と入力し、[Bottle Web プロジェクト] テンプレートを選択して、[次へ] を選択します。
[Bottle Web プロジェクト] テンプレートは、Python 開発ワークロードに含まれています。 詳細については、「Python Webアプリケーション プロジェクト テンプレート」を参照してください。
プロジェクトの名前とパスの場所を入力し、[作成] を選択します。
指示に従って外部パッケージをインストールし、[仮想環境にインストールする] を選択し、仮想環境の優先ベース インタープリターを選択します。
仮想環境は通常、App Service にインストールされている Python のバージョンと一致します。
準備ができたら、[デバッグ] > [デバッグの開始] を選択するか、キーボード ショートカット F5 を使用して、プロジェクトをローカルでテストできます。
ターゲット Azure App Service を作成する
Azure に発行するには、Azure サブスクリプションのターゲット Azure App Service が必要です。
以下のように、空の Web アプリを使用して App Service を作成します。
Azure Portal にサインインします。
[App Services] ページに移動します。
[作成] を選択し、ドロップダウン メニューから [Web アプリ] を選択します。 [Web アプリの作成] ページが開きます。
[基本] タブで次の設定を構成します。
設定 説明 リソース グループ このフィールドは無視します。 ランタイム設定を選択した後、システムがこの値を更新します。 名前 Web アプリの名前を入力します。 発行 [コード] を選択します。 ランタイム スタック ドロップダウン メニューから適切な Python ランタイムを選択します。 項目を選択すると、[リソース グループ] フィールドが更新されます。 リージョン 最寄りの Azure リージョンを選択します。 料金プラン Free F1 プランを選択します。 この記事の例では、他のタブの設定を無視できます。
[確認および作成] を選択します。 選択内容を確認し、[作成] を選択します。
(省略可能) App Service の準備ができたら、リソースに移動し、[発行プロファイルのダウンロード] を選択してファイルをローカルに保存できます。
Azure App Service での Python の構成
サブスクリプションで実行されている空の Web アプリを含む App Service を作成したら、目的のバージョンの Python をインストールします。 Visual Studio 2017 以降から発行する場合は、サイトの拡張機能と共にインストールされた Python インタープリターへの正確なパスを記録します。 詳細については、「Python インタープリターのインストール」を参照してください。
必要に応じて、bottle
パッケージをインストールすることもできます。 ただし、このパッケージは、このチュートリアルの後の手順でインストールされます。
App Service への発行 - Visual Studio 2017 以降
Visual Studio 2017 以降から Azure App Service に発行すると、プロジェクト内のファイルのみがサーバーにコピーされます。 サーバー環境の構成に必要なファイルを作成する必要があります。
Visual Studio のソリューション エクスプローラーで、プロジェクトを右クリックし、[追加] > [新しい項目] を選択します。 ダイアログで、[Azure web.config (Fast CGI)] テンプレートを選択し、[追加] を選択します。 これによりプロジェクト ルートに
web.config
ファイルが作成されます。「IIS 構成リファレンス (iis.net)」で説明されているように、
PythonHandler
ファイルのweb.config
エントリを変更して、パスがサーバー上の Python インストールと一致するようにします。 たとえば、Python 3.6.1 x64 の場合、エントリは次のように表示されます。<system.webServer> <handlers> <add name="PythonHandler" path="*" verb="*" modules="FastCgiModule" scriptProcessor="D:\home\Python361x64\python.exe|D:\home\Python361x64\wfastcgi.py" resourceType="Unspecified" requireAccess="Script"/> </handlers> </system.webServer>
WSGI_HANDLER
ファイルのweb.config
エントリを、使用しているフレームワークに合わせて適切に設定します。Bottle: この例に示すように、
app.wsgi_app
値の後にかっこを追加します。 オブジェクトが変数ではなく関数であるため、かっこが必要です。 構文は、app.py
ファイルで確認できます。<!-- Bottle apps only --> <add key="WSGI_HANDLER" value="app.wsgi_app()"/>
Flask:
WSGI_HANDLER
値を<project_name>.app
に変更します。<project_name>
はプロジェクトの名前に一致します。from <project_name> import app
ファイルのrunserver.py
ステートメントを見ると、正確な識別子が見つかります。 たとえば、プロジェクトの名前が "FlaskAzurePublishExample" の場合、エントリは次のように表示されます。<!-- Flask apps only: Change the project name to match your app --> <add key="WSGI_HANDLER" value="FlaskAzurePublishExample.app"/>
Django: Django プロジェクトの
web.config
ファイルには 2 つの変更が必要です。WSGI_HANDLER
の値をdjango.core.wsgi.get_wsgi_application()
に変更します。 オブジェクトは、wsgi.py
ファイルにあります。<!-- Django apps only --> <add key="WSGI_HANDLER" value="django.core.wsgi.get_wsgi_application()"/>
WSGI_HANDLER
キーのエントリの直後に、次のエントリを追加します。DjangoAzurePublishExample
の値を、プロジェクトの名前に置き換えます。<add key="DJANGO_SETTINGS_MODULE" value="django_iis_example.settings" />
Django アプリのみ: Django プロジェクトの
settings.py
ファイルで、サイトの URL ドメインまたは IP アドレスをALLOWED_HOSTS
エントリに追加します。 "vspython-test-02.azurewebsites.net" を URL に置き換えます。# Change the URL to your specific site ALLOWED_HOSTS = ['vspython-test-02.azurewebsites.net']
配列の結果に URL を追加しない場合、次のエラーが表示されます。
DisallowedHost at / Invalid HTTP_HOST header: '\<site URL\>'. You might need to add '\<site URL\>' to ALLOWED_HOSTS.
配列が空のとき、Django は自動的に
'localhost'
をホストとして許可します。 実稼働 URL を追加した場合、'localhost'
はホストとして自動的に許可されません。 そのため、settings.py
ファイルの開発用のコピーと実稼働用のコピーを別々に管理するか、環境変数を使用してランタイム値を制御することをお勧めします。テンプレートを選択します。
- ソリューション エクスプローラーで、プロジェクト フォルダーを展開します。
- static フォルダーを右クリックし、[追加] > [新しい項目] を選択します。
- [Azure 静的ファイルの web.config] テンプレートを選択し、[追加] を選択します。
この操作により、[static] (静的) フォルダー内に別の
web.config
ファイルが作成され、そのフォルダーの Python 処理が無効になります。 この構成は、Python アプリケーションを使用せずに、静的ファイルの要求を既定の Web サーバーに送信します。ソリューション エクスプローラーでプロジェクトを保存し、プロジェクトを右クリックし、[発行] を選択します。
[発行] ウィンドウで、発行先を指定します。
[ターゲット] に [Azure] を選択し、[次へ] を選択します。
[特定のターゲット] に [Azure App Service (Windows)] を選択し、[次へ] を選択します。
- インストールを完了するために他の [Required components] (必須コンポーネント] が必要であると表示された場合は、[完了] を選択します。 Visual Studio インストーラーが開きます。 オプションを確認し、[インストール] を選択します。
[App Service] にサブスクリプションに適した App Service を選択し、[完了] を選択します。
発行の作成プロセスが完了したら、[閉じる] を選択します。
[Web 発行アクティビティ] ウィンドウと [発行プロファイルの作成の進行状況] ウィンドウに状態が表示されます。 Web アプリの "発行準備が完了しました" というメッセージが表示されたら、[発行] を選択します。
発行が成功すると、サイトの URL で既定のブラウザーが開きます。 サイトの URL は、[発行] ウィンドウにも表示されます。
サイトの URL が自動的に開かない場合は、[Open site] (サイトを開く) を選択してブラウザーで Web アプリを表示します。
ブラウザーが開いたときに、"内部サーバー エラーが発生したため、ページを表示できません。" というメッセージが表示される場合があります。このメッセージは、サーバー上の Python 環境が完全に構成されていないことを示しています。その場合、次の手順に従います。
適切な Python サイト拡張機能がインストールされていることを確認します。 詳細については、「クイックスタート: Python (Django または Flask) Web アプリを Azure App Service にデプロイする」を参照してください。
web.config
ファイル内の Python インタープリターへのパスを再確認します。 パスは、選択したサイト拡張機能のインストール場所と完全に一致している必要があります。Kudu コンソールを使用して、アプリの
requirements.txt
ファイルに記載されているすべてのパッケージをアップグレードします。web.config
など、/home/python361x64
ファイルで使用しているのと同じ Python フォルダーを参照します。 [Kudu コンソール] セクションで説明されているように、以下のコマンドを実行します。python -m pip install --upgrade -r /home/site/wwwroot/requirements.txt
このコマンドの実行時にアクセス許可エラーが表示される場合は、サイト拡張機能フォルダーでコマンドを実行していることを確認します。 App Service の既定の Python インストールのいずれかがあるフォルダーでは、コマンドを実行しないでください。 これらの既定の環境を変更することはできないため、パッケージをインストールしようとすると確実に失敗します。
エラーをより詳細に出力するには、次の行を
web.config
ノード内の<system.webServer>
ファイルに追加します。<httpErrors errorMode="Detailed"></httpErrors>
新しいパッケージをインストールした後、App Service の再起動を試します。
web.config
ファイルの変更に再起動は不要です。App Service はweb.config
ファイルを変更するたびに自動的に再起動されます。ヒント
アプリの
requirements.txt
ファイルに変更を加えた場合、必ずもう一度 Kudu コンソールを使用して、そのファイルに一覧表示されている任意のパッケージをインストールしてください。
サーバー環境を完全に構成した後、ブラウザーでページを更新して Web アプリを表示します。
App Service への発行 - Visual Studio 2015
以下の手順に従って、Visual Studio 2015 で Python Web アプリを Azure App Service に発行します。
ソリューション エクスプローラーで、プロジェクトを右クリックし、 [発行] を選択します。
[発行] ダイアログで、 [Microsoft Azure App Service] を選びます。
発行先として [Microsoft Azure App Service] を選択します。 次のダイアログで、既存の App Service を選択するか、[新規] を選択して新しい App Service を作成します。
App Service の詳細が、[発行] ダイアログの [接続] タブに表示されます。
必要に応じて、[次へ] を選択して他の設定を確認します。
公開を選択します。 アプリケーションが Azure にデプロイされると、サイトの URL で既定のブラウザーが開きます。
このプロセスの一環として、Visual Studio は以下の手順も完了します。
web.config
ファイルをサーバー上に作成し、その中にwsgi_app
アプリの関数と App Service のデフォルト Python 3.4 インタープリターをそれぞれ指す適切なポインターを記述します。- プロジェクトの static フォルダー内のファイルの処理をオフにします。 (このアクションの規則は
web.config
ファイルにあります。) - 仮想環境をサーバーに発行します。
web.debug.config
ファイルとデバッグ ツールを追加して、リモート デバッグを有効にします。 Visual Studio 2019 バージョン 16.4 以前の場合、デバッグ ツールは ptvsd です。 Visual Studio 2019 バージョン 16.5 以降の場合、デバッグ ツールは debugpy です。
前述したとおり、これらの自動ステップは発行プロセスを簡素化しますが、Python 環境の制御をより難しくすることがあります。 たとえば、web.config
ファイルはサーバーにのみ作成され、プロジェクトには追加されません。 発行プロセスは、サーバーの構成に依存するのではなく、開発用コンピューターから仮想環境全体をコピーするため、時間がかかります。
最終的には、独自の web.config
ファイルを管理し、requirements.txt
ファイルでサーバー上のパッケージを直接管理すると良いでしょう。 特に、requirements.txt
ファイルを使用すると、開発環境とサーバー環境が常に一致していることを示しやすくなります。