Azure Functions での Python エラーのトラブルシューティング
この記事では、Azure Functions での Python 関数のエラーのトラブルシューティングに役立つ情報を提供します。 この記事は、v1 と v2 の両方のプログラミング モデルをサポートしています。 記事の上部にあるセレクターから使用するモデルを選択します。
Note
Python v2 プログラミング モデルは、4.x Functions ランタイムでのみサポートされます。 詳細については、「Azure Functions ランタイム バージョンをターゲットにする方法」をご覧ください。
Python 関数の一般的な問題に関するトラブルシューティング セクションを次に示します。
特に v2 モデルについて、既知の問題とその回避策を次に示します。
Python 関数の一般的なトラブルシューティング ガイドは次のとおりです。
トラブルシューティング: ModuleNotFoundError
このセクションは、Python Function App でのモジュール関連のエラーのトラブルシューティングに役立ちます。 これらのエラーでは、通常、次のような Azure Functions エラー メッセージが示されます。
例外: ModuleNotFoundError: No module named 'module_name'. ('module_name' という名前のモジュールはありません。)
このエラーは、Python 関数アプリで Python モジュールの読み込みに失敗した場合に発生します。 このエラーの根本原因は、次の問題のいずれかです。
- パッケージが見つからない
- パッケージが適切な Linux ホイールで解決されない
- パッケージが Python インタープリター バージョンと互換性がない
- パッケージが他のパッケージと競合している
- パッケージで、Windows および macOS プラットフォームのみがサポートされている
プロジェクト ファイルを表示する
問題の実際の原因を特定するには、Function App で実行される Python プロジェクト ファイルを取得する必要があります。 ローカル コンピューターにプロジェクト ファイルがない場合は、次のいずれかの方法で取得できます。
- 関数アプリのアプリ設定が
WEBSITE_RUN_FROM_PACKAGEで、その値が URL の場合は、URL をコピーしてブラウザーに貼り付け、ファイルをダウンロードします。 - 関数アプリで
WEBSITE_RUN_FROM_PACKAGEが1に設定されている場合は、https://<app-name>.scm.azurewebsites.net/api/vfs/data/SitePackagesに移動し、最新のhrefURL からファイルをダウンロードします。 - 関数アプリに前述のアプリ設定がない場合は、
https://<app-name>.scm.azurewebsites.net/api/settingsに移動し、SCM_RUN_FROM_PACKAGEの下の URL を見つけます。 URL をコピーし、ブラウザーに貼り付けて、ファイルをダウンロードします。 - 提案で問題が解決する場合は、
https://<app-name>.scm.azurewebsites.net/DebugConsoleに移動し、/home/site/wwwrootの下にあるコンテンツを確認してください。
この記事の残りの部分は、Function App のコンテンツを検査し、根本原因を特定し、特定の問題を解決することによって、このエラーの考えられる原因をトラブルシューティングするのに役立ちます。
ModuleNotFoundError を診断する
このセクションでは、モジュール関連のエラーの潜在的な根本原因について詳しく説明します。 考えられる根本原因を解明した後、関連する軽減策に進むことができます。
パッケージが見つからない
.python_packages/lib/python3.6/site-packages/<package-name> または .python_packages/lib/site-packages/<package-name> に移動します。 ファイル パスが存在しない場合は、この欠落したパスが根本原因である可能性があります。
デプロイ中にサードパーティまたは古いツールを使用すると、この問題が発生する可能性があります。
この問題を軽減するには、「 リモート ビルドを有効にする 」または「 ネイティブ依存関係のビルド」をご覧ください。
パッケージが適切な Linux ホイールで解決されない
.python_packages/lib/python3.6/site-packages/<package-name>-<version>-dist-info または .python_packages/lib/site-packages/<package-name>-<version>-dist-info に移動します。 任意のテキスト エディターを使用して、wheel ファイルを開き、Tag: セクションを確認します。 タグ値に linuxが含まれていないことが問題である可能性があります。
Python 関数は、Azure の Linux でのみ実行されます。 関数ランタイム v2.x は Debian Stretch で、v3.x ランタイムは Debian Buster で実行されます。 成果物には、正しい Linux バイナリを含める必要があります。 Core Tools、サードパーティ、または古いツールで --build local フラグを使用すると、古いバイナリが使用される可能性があります。
この問題を軽減するには、「 リモート ビルドを有効にする 」または「 ネイティブ依存関係のビルド」をご覧ください。
パッケージが Python インタープリター バージョンと互換性がない
.python_packages/lib/python3.6/site-packages/<package-name>-<version>-dist-info または .python_packages/lib/site-packages/<package-name>-<version>-dist-info に移動します。 テキスト エディターで METADATA ファイルを開き、 Classifiers: セクションを確認します。 セクションに Python :: 3、Python :: 3.6、Python :: 3.7、Python :: 3.8、または Python :: 3.9が含まれていない場合は、パッケージのバージョンが古すぎるか、既にメンテナンスの対象外となっている可能性が高いです。
ご利用の Function App の Python バージョンは、Azure portal から確認できます。 関数アプリの [概要] リソース ページに移動して、ランタイム バージョンを見つけます。 ランタイム バージョンでは、 Azure Functions ランタイム バージョンの概要に関するページで説明されているように、Python バージョンがサポートされています。
この問題を軽減するには、「 パッケージを最新バージョンに更新する 」または「 パッケージを同等のものに置き換える」をご覧ください。
パッケージが他のパッケージと競合している
パッケージが適切な Linux ホイールで正しく解決されていることを確認した場合は、他のパッケージと競合している可能性があります。 特定のパッケージでは、PyPi ドキュメントで互換性のないモジュールが明確になる場合があります。 たとえば、azure 4.0.0 では、次のようなステートメントが見つかります。
このパッケージは、azure storage との互換性がありません。 azure-storage をインストールした場合、または azure 1.x/2.x をインストールしたものの azure-storage をインストールしなかった場合、最初に azure-storage をインストールする必要があります。
ご利用のパッケージ バージョンのドキュメントは、https://pypi.org/project/<package-name>/<package-version> で確認できます。
この問題を軽減するには、「 パッケージを最新バージョンに更新する 」または「 パッケージを同等のものに置き換える」をご覧ください。
パッケージで、Windows および macOS プラットフォームのみがサポートされている
テキスト エディターを使用して requirements.txt を開き、https://pypi.org/project/<package-name> でパッケージを確認します。 一部のパッケージは、Windows および macOS プラットフォームでのみ実行されます。 たとえば、pywin32 は Windows でのみ実行されます。
ローカル開発に Windows または macOS を使用している場合は、 Module Not Found エラーが発生しない可能性があります。 しかし、実行時に Linux を使用する、Azure Functions にパッケージをインポートすることはできません。 この問題は、プロジェクトの初期化中に Windows または macOS マシンから requirements.txt に仮想環境をエクスポートするために、 pip freeze を使用することで発生する可能性があります。
この問題を軽減するには、「 パッケージを同等のものに置き換える 」または「 Handcraft requirements.txt」をご覧ください。
ModuleNotFoundError を軽減する
モジュール関連の問題の軽減策として考えられるものを以下に示します。 前述の診断方法 を使用して、これらの軽減策のうち、どれを試すかを決めます。
リモート ビルドを有効にする
リモート ビルドが有効になっていることを確認します。 確認する方法は、デプロイ方法によって異なります。
最新バージョンの Visual Studio Code 用の Azure Functions 拡張機能がインストールされていることを確認してください。 .vscode/settings.json ファイルが存在し、設定 "azureFunctions.scmDoBuildDuringDeployment": trueが含まれていることを確認します。 そうでない場合は、 azureFunctions.scmDoBuildDuringDeployment 設定を有効にした状態でファイルを作成し、プロジェクトを再デプロイします。
ネイティブの依存関係を構築する
Docker と Azure Functions Core Tools の両方の最新バージョンがインストールされていることを確認します。 ローカル関数プロジェクト フォルダーに移動し、デプロイに func azure functionapp publish <app-name> --build-native-deps を使用します。
パッケージを最新バージョンに更新する
https://pypi.org/project/<package-name>の最新のパッケージ バージョンで、 Classifiers: セクションを確認します。 パッケージは OS Independent であるか、Operating System の POSIX または POSIX :: Linux と互換性がある必要があります。 また、プログラミング言語には、Python :: 3、Python :: 3.6、Python :: 3.7、Python :: 3.8、または Python :: 3.9が含まれている必要があります。
これらのパッケージ項目が正しい場合は、 requirements.txtの <package-name>~=<latest-version> 行を変更することで、パッケージを最新バージョンに更新できます。
requirements.txt を手動で作成する
一部の開発者は pip freeze > requirements.txt を使用して、開発環境用の Python パッケージの一覧を生成します。 ほとんどの場合、この利便性が機能するはずですが、関数は Windows または macOS でローカルに開発しても、Linux で実行される Function App に発行する場合など、クロスプラットフォームのデプロイ シナリオで問題が発生する可能性があります。 このシナリオでは、pip freeze によって、ローカル開発環境に対して予期しないオペレーティング システム固有の依存関係が生じる場合があります。 これらの依存関係により、Python 関数アプリが Linux で実行されている場合に中断される可能性があります。
プロジェクト ソース コード内の各 .py ファイルの import ステートメントを確認し、 requirements.txt ファイルでモジュールのみをチェックインすることをお勧めします。 この方法により、さまざまなオペレーティング システムでパッケージの解決を適切に処理できることが保証されます。
パッケージを同等のものに置き換える
まず、 https://pypi.org/project/<package-name>でパッケージの最新バージョンを確認します。 このパッケージには通常、独自の GitHub ページがあります。 GitHub の [問題] セクションに移動し、問題が修正されているかどうかを確認します。 修正されている場合は、パッケージを最新バージョンに更新します。
場合によっては、パッケージが Python Standard Library ( pathlibなど) に統合されていることがあります。 そのような場合は、Azure Functions で特定の Python ディストリビューション (Python 3.6、Python 3.7、Python 3.8、および Python 3.9) が提供されるため、 requirements.txt ファイル内のパッケージを削除する必要があります。
ただし、問題が修正されておらず、期限が切れている場合は、プロジェクト用の同様のパッケージを見つけるためにいくつかの調査を行うことをお勧めします。 通常は、Python コミュニティから提供されているさまざまな類似ライブラリを使用できます。
依存関係の分離フラグを無効にする
アプリケーション設定 PYTHON_ISOLATE_WORKER_DEPENDENCIES の値を 0 に設定します。
トラブルシューティング: "cygrpc" をインポートできない
このセクションは、Python 関数アプリでの 'cygrpc' 関連のエラーのトラブルシューティングに役立ちます。 これらのエラーでは、通常、次のような Azure Functions エラー メッセージが示されます。
Cannot import name 'cygrpc' from 'grpc._cython' ('grpc._cython' から 'cygrpc' という名前をインポートできません)
このエラーは、Python 関数アプリで適切な Python インタープリターの使用を開始できない場合に発生します。 このエラーの根本原因は、次の問題のいずれかです。
'cygrpc' リファレンス エラーの診断
cygrpc を参照するエラーには、いくつかの原因が考えられます。このセクションではそれを詳しく説明します。
Python インタープリターが OS アーキテクチャに一致しない
この不一致は、32 ビットの Python インタープリターが 64 ビットのオペレーティング システムにインストールされていることが最も可能性の高い原因だと考えられます。
x64 オペレーティング システムで実行している場合は、Python バージョン 3.6、3.7、3.8、または 3.9 インタープリターが 64 ビット バージョンであることを確認します。
次のコマンドを実行して、ご利用の Python インタープリターのビットを確認できます。
PowerShell のWindows で、 py -c 'import platform; print(platform.architecture()[0])'を実行します。
Unix に似たシェルで、 python3 -c 'import platform; print(platform.architecture()[0])'を実行します。
Python インタープリターのビットとオペレーティング システムのアーキテクチャが一致しない場合は、 Python Software Foundationから適切な Python インタープリターをダウンロードします。
Python インタープリターが Azure Functions の Python Worker でサポートされない
Azure Functions の Python Worker では、特定の Python バージョンのみがサポートされます。
Windows の場合は py --version、または Unix 系システムの場合は python3 --version で、Python インタープリターが想定されているバージョンと一致しているかどうかを確認します。 返される結果が、サポートされている Python のバージョンの 1 つであることを確認します。
Python インタープリターのバージョンが Azure Functions の要件を満たしていない場合は、代わりに Python Software Foundation から Functions でサポートされている Python インタープリターのバージョンをダウンロードします。
トラブルシューティング: Python がコード 137 で終了した
コード 137 エラーは、通常、Python 関数アプリのメモリ不足の問題が原因で発生します。 その結果、次の Azure Functions エラー メッセージが表示されます。
Microsoft.Azure.WebJobs.Script.Workers.WorkerProcessExitException : python exited with code 137 (Python がコード 137 で終了しました)
このエラーは、Python 関数アプリが、SIGKILL シグナルでオペレーティング システムによって強制的に終了された場合に発生します。 このシグナルは、通常、Python プロセスでのメモリ不足エラーを示します。 Azure Functions プラットフォームには サービス制限 があり、この制限を超える関数アプリは終了されます。
関数アプリのメモリ ボトルネックを分析するには、「ローカル開発環境で Python 関数アプリをプロファイルする」をご覧ください。
トラブルシューティング: Python がコード 139 で終了した
このセクションは、Python 関数アプリでのセグメント化の失敗に関するエラーのトラブルシューティングに役立ちます。 これらのエラーでは、通常、次のような Azure Functions エラー メッセージが示されます。
Microsoft.Azure.WebJobs.Script.Workers.WorkerProcessExitException : python exited with code 139 (Python がコード 139 で終了しました)
このエラーは、Python 関数アプリが、SIGSEGV シグナルでオペレーティング システムによって強制的に終了された場合に発生します。 このシグナルは、メモリ セグメント化の違反を示します。これは、制限されたメモリ領域からの予期しない読み取りまたはメモリ領域への書き込みの結果として発生する可能性があります。 以下のセクションでは、一般的な根本原因の一覧を示します。
サードパーティのパッケージからの回帰
関数アプリの requirements.txt ファイルで固定されていないパッケージは、Azure への各デプロイの間に、最新バージョンにアップグレードされます。 パッケージの更新では、アプリに影響を与える回帰が発生する可能性があります。 そのような問題から復旧するには、import ステートメントをコメントアウトするか、パッケージ参照を無効にするか、requirements.txt でパッケージを以前のバージョンに固定します。
形式に誤りがある .pkl ファイルからの Unpickle
お使いの関数アプリで Python pickle ライブラリを使用して .pkl ファイルから Python オブジェクトを読み込んでいる場合、そのファイルに形式に誤りがあるバイト文字列、または無効なアドレス参照が含まれている可能性があります。 この問題から復旧するには、 pickle.load() 関数をコメント アウトしてみてください。
pyodbc 接続の競合
お使いの関数アプリで一般的な ODBC データベース ドライバー pyodbcを使用している場合、1 つの関数アプリ内で複数の接続が開かれている可能性があります。 この問題を回避するには、シングルトン パターンを使用し、関数アプリ全体で使用されている pyodbc 接続が 1 つだけであることを確認します。
同期トリガーが失敗した
エラー Sync triggers failed は、いくつかの問題が原因で発生する可能性があります。 考えられる原因の 1 つは、関数が App Service プランで実行されるときの、顧客定義の依存関係と Python 組み込みモジュールの間の競合です。 詳しくは、「パッケージの管理」をご覧ください。
トラブルシューティング: ファイルまたはアセンブリを読み込めなかった
このエラーは、v2 プログラミング モデルを使ってローカル環境で実行しているときに発生することがあります。 このエラーは、今後のリリースで解決される既知の問題が原因で発生します。
このエラーのメッセージ例を次に示します。
DurableTask.Netherite.AzureFunctions: ファイルまたはアセンブリ 'Microsoft.Azure.WebJobs.Extensions.DurableTask, Version=2.0.0.0, Culture=neutral, PublicKeyToken=014045d636e89289' を読み込むことができませんでした。
指定されたファイルが見つかりません。
このエラーは、拡張機能バンドルがキャッシュされる方法に問題があるために発生します。 この問題をトラブルシューティングするには、--verbose を指定して次のコマンドを実行し、詳細を表示します。
func host start --verbose
Loading startup extension <> のような拡張機能読み込みログの後に Loaded extension <> がない場合、このキャッシュの問題が発生している可能性があります。
この問題を解決するには、次の手順を実行します。
次を実行して、
.azure-functions-core-toolsのパスを見つけます。func GetExtensionBundlePath.azure-functions-core-toolsディレクトリを削除します。rm -r <insert path>/.azure-functions-core-tools
Core Tools をもう一度実行すると、キャッシュ ディレクトリが再作成されます。
トラブルシューティング: Azure Storage の接続を解決できない
このエラーは、ローカル出力に次のメッセージとして表示されることがあります。
Microsoft.Azure.WebJobs.Extensions.DurableTask: Unable to resolve the Azure Storage connection named 'Storage'. ('Storage' という名前の Azure Storage 接続を解決できません。)
値を null にすることはできません。 (Parameter 'provider') ((パラメーター 'provider'))
このエラーは、拡張機能がローカルでバンドルから読み込まれる方法の結果です。 このエラーを解決するには、以下のいずれかのアクションを実行します。
Azurite のようなストレージ エミュレーターを使ってください。 このオプションは、関数アプリケーションでストレージ アカウントを使用する予定がない場合に適しています。
ストレージ アカウントを作成し、接続文字列を localsettings.json ファイルの
AzureWebJobsStorage環境変数に追加します。 アプリケーションでストレージ アカウントのトリガーやバインドを使用している場合、または既存のストレージ アカウントを持っている場合は、このオプションを使用します。 作業を開始するには、「ストレージ アカウントの作成」を参照してください。
デプロイ後に関数が見つからない
デプロイが成功したように見えるのに、ホストが Python 関数を認識できない原因となりうる一般的なビルドの問題がいくつか検出されました。
ビルド ステップからパッケージが正しく復元されることを保証するには、エージェント プールが Ubuntu で実行されている必要があります。 デプロイ テンプレートで、ビルドとデプロイに Ubuntu 環境を要求していることを確認します。
関数アプリがソース リポジトリのルートにない場合は、
pip installの手順で.python_packagesフォルダーを作成する正しい場所が参照されていることを確認します。 この場所では、次のコマンド例のように大文字と小文字が区別されます。pip install --target="./FunctionApp1/.python_packages/lib/site-packages" -r ./FunctionApp1/requirements.txtテンプレートは
/home/site/wwwrootに読み込むことができるデプロイ パッケージを生成する必要があります。 Azure Pipelines では、これはArchiveFilesタスクによって行われます。
Azure portal での開発に関する問題
Azure portal を使うときは、次の既知の問題とその回避策を考慮してください。
- ポータルでの関数コードの記述には、一般的な制限があります。 詳細については、「Azure portal での開発の制限事項」をご覧ください。
- ポータルで関数アプリから関数を削除するには、ファイル自体から関数コードを削除します。 Python v2 のプログラミング モデルを使っている場合、[削除] ボタンでは関数を削除できません。
- ポータルで関数を作成しているとき、別のツールを使って開発するよう警告されることがあります。 構文エラーが検出された場合など、ポータルでコードを編集できないシナリオがいくつかあります。 このようなシナリオでは、Visual Studio Code または Azure Functions Core Tools を使って、関数コードの開発と発行を行ってください。
次のステップ
問題を解決できない場合は、Azure Functions チームにお問い合わせください。