✍️

Python Programming Model V2 を使用した関数が Azure Portal 上に反映されない問題の解決メモ

に公開

はじめに

Azure FunctionsでPython Programming Model V2を使用した関数をデプロイしたところ、
Azure Portal 上に正常に反映されない問題に遭遇しました。
最終的にAzureWebJobsFeatureFlagsの設定により解決したので、メモとして記録しておきます。

発生した問題

Functions Appのデプロイ自体は成功していたものの、作成した関数が実際には反映されていない状況でした。
デプロイ完了の通知はされるが、実際の関数が動作しないという現象です。

この状況は、以下の記事で紹介されているような問題と似ていました。

【Azure Functions】No HTTP triggers found発生時の調査方法

・Azure Portalから見た時に関数が表示されない
・ソースコードのファイル自体はアップロードされているように見える

(※記事では HTTP Trigger ですが、私の場合は Timer Trigger で発生しました。)

解決に向けた調査

診断ツールでエラーを確認

エラーの原因を探るため、「問題の診断と解決」のいくらかの項目を確認してみました。
確認したところ、2件のエラーが発生していることが判明しました。

エラー1: ログレベルの設定問題

1件目は、ログレベルに関するエラーでした。設定でINFOと大文字で指定していましたが、
Azure Functionsでは小文字のinfoのみが受け付けられるとのことでした。

エラー2: 不明なエラー

2件目のエラーについては内容が不明だったため、AIに相談しました。
AIからの提案で「AzureWebJobsFeatureFlagsの設定が必要では?」という回答を得たため、
この設定を調べて試してみることにしました。

AzureWebJobsFeatureFlagsの設定

AzureWebJobsFeatureFlags: EnableWorkerIndexingを環境変数に設定したところ、
関数が正常に反映されるようになりました。

AzureWebJobsFeatureFlags: EnableWorkerIndexingとは

Language Worker が関数のメタデータを Host に送信できるかどうかを制御するフラグ
という認識です。

順を追って説明します。

Host と Language Worker の関係

まず、Azure Functionsの構造として、 HostLanguage Worker があります。
参考にした記事内で紹介されていますが、それぞれの役割は下記です。

メタデータとは

関数を他のサービスと接続する、トリガーやバインドの情報です。

関数がどのトリガーやバインドを使っているかという情報を Host に伝える必要があります。

メタデータ取得方法の変化

Python Programming Model v1では、 関数のトリガーやバインドの情報を function.json に記載し、Hostfunction.json を読み取ることでメタデータを取得していました。

Python Programming Model v2では、トリガーやバインドの情報をデコレータでコードに付与する方法に変化したことから、 Language Worker が デコレータの情報をメタデータとして整理し、 Host に通知するというアプローチになったようです。

↓デコレータでのトリガー設定の例(公式の開発者ガイドに記載)

@app.function_name(name="HttpTrigger1")
@app.route(route="req")
def main(req):
    user = req.params.get("user")
    return f"Hello, {user}!"

Azure Functions の Python 開発者向けガイド

Worker Indexing Changes ワーカーインデックス作成の変更

まとめ

  • Azure Functionのデプロイエラー解決のヒントとして、「問題の診断と解決」を確認すると良さそう
  • Python Programming Model V2で作成した関数をデプロイする際にはAzureWebJobsFeatureFlags: EnableWorkerIndexingの設定が必要
NCDCエンジニアブログ

Discussion