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

この記事では、Python を使用した Azure Functions の開発について紹介します。This article is an introduction to developing Azure Functions using Python. 以下の内容は、「Azure Functions の開発者向けガイド」を既に読んでいることを前提としています。The content below assumes that you've already read the Azure Functions developers guide.

Python でのスタンドアロンの関数のサンプル プロジェクトについては、Python 関数のサンプルを参照してください。For standalone Function sample projects in Python, see the Python Functions samples.

プログラミング モデルProgramming model

Azure Functions では、関数は入力を処理して出力を生成する Python スクリプト内のステートレスなメソッドであることが求められます。Azure Functions expects a function to be a stateless method in your Python script that processes input and produces output. 既定で、ランタイムでは、このメソッドは main() と呼ばれるグローバル メソッドとして __init__.py ファイル内に実装されると想定されます。By default, the runtime expects the method to be implemented as a global method called main() in the __init__.py file. また、代替エントリ ポイントを指定することもできます。You can also specify an alternate entry point.

トリガーとバインディングからのデータをメソッド属性を介して関数にバインドするには、function.json ファイル内で定義されている name プロパティを使用します。Data from triggers and bindings is bound to the function via method attributes using the name property defined in the function.json file. たとえば、次の function.json には、req という名前の HTTP 要求によってトリガーされるシンプルな関数が記述されています。For example, the function.json below describes a simple function triggered by an HTTP request named req:

{
  "bindings": [
    {
      "name": "req",
      "direction": "in",
      "type": "httpTrigger",
      "authLevel": "anonymous"
    },
    {
      "name": "$return",
      "direction": "out",
      "type": "http"
    }
  ]
}

__init__.py ファイルには、次の関数コードが含まれています。The __init__.py file contains the following function code:

def main(req):
    user = req.params.get('user')
    return f'Hello, {user}!'

Python の型の注釈を使用することで、関数内に属性の種類および戻り値の型を明示的に宣言することもできます。you can also explicitly declare the attribute types and return type in the function using Python type annotations. これは、多くの Python コード エディターによって提供される IntelliSense およびオートコンプリート機能を使用するのに役立ちます。This helps you use the intellisense and autocomplete features provided by many Python code editors.

import azure.functions


def main(req: azure.functions.HttpRequest) -> str:
    user = req.params.get('user')
    return f'Hello, {user}!'

azure.functions.* パッケージに含まれる Python の注釈を使用すると、入力と出力がご利用のメソッドにバインドされます。Use the Python annotations included in the azure.functions.* package to bind input and outputs to your methods.

代替エントリ ポイントAlternate entry point

function.json ファイル内で scriptFile プロパティと entryPoint プロパティをオプションで指定することによって、関数の既定の動作を変更できます。You can change the default behavior of a function by optionally specifying the scriptFile and entryPoint properties in the function.json file. たとえば、以下の function.json では、ご利用の Azure 関数のエントリ ポイントとして、main.py ファイル内の customentry() メソッドを使用するようにランタイムに指示が出されます。For example, the function.json below tells the runtime to use the customentry() method in the main.py file, as the entry point for your Azure Function.

{
  "scriptFile": "main.py",
  "entryPoint": "customentry",
  "bindings": [
      ...
  ]
}

フォルダー構造Folder structure

Python 関数プロジェクトの推奨フォルダー構造は、次の例のようになります。The recommended folder structure for a Python Functions project looks like the following example:

 __app__
 | - MyFirstFunction
 | | - __init__.py
 | | - function.json
 | | - example.py
 | - MySecondFunction
 | | - __init__.py
 | | - function.json
 | - SharedCode
 | | - myFirstHelperFunction.py
 | | - mySecondHelperFunction.py
 | - host.json
 | - requirements.txt
 tests

メイン プロジェクト フォルダー (__app__) には、次のファイルを含めることができます。The main project folder (__app__) can contain the following files:

  • local.settings.json:ローカルで実行するときに、アプリの設定と接続文字列を格納するために使用されます。local.settings.json: Used to store app settings and connection strings when running locally. このファイルは Azure に公開されません。This file doesn't get published to Azure. 詳細については、「local.settings.file」に関するページを参照してください。To learn more, see local.settings.file.
  • requirements.txt:Azure に公開するときにシステムによってインストールされるパッケージの一覧が含まれます。requirements.txt: Contains the list of packages the system installs when publishing to Azure.
  • host.json:関数アプリ内のすべての関数に影響するグローバル構成オプションが含まれます。host.json: Contains global configuration options that affect all functions in a function app. このファイルは Azure に公開されます。This file does get published to Azure. ローカルで実行する場合は、すべてのオプションがサポートされるわけではありません。Not all options are supported when running locally. 詳細については、「host.json」に関するページを参照してください。To learn more, see host.json.
  • .funcignore:(省略可能) Azure に発行しないファイルを宣言します。.funcignore: (Optional) declares files that shouldn't get published to Azure.
  • .gitignore:(省略可能) git リポジトリから除外されるファイル (local.settings.json など) を宣言します。.gitignore: (Optional) declares files that are excluded from a git repo, such as local.settings.json.

各関数には、独自のコード ファイルとバインディング構成ファイル (function.json) があります。Each function has its own code file and binding configuration file (function.json).

共有コードは、__app__ 内の別のフォルダーに保存する必要があります。Shared code should be kept in a separate folder in __app__. SharedCode フォルダー内のモジュールを参照するには、次の構文を使用します。To reference modules in the SharedCode folder, you can use the following syntax:

from __app__.SharedCode import myFirstHelperFunction

関数に対してローカルになるモジュールを参照するには、次のような相対インポート構文を使用できます。To reference modules local to a function, you can use the relative import syntax as follows:

from . import example

Azure の関数アプリにプロジェクトをデプロイする場合は、FunctionApp フォルダーの内容全体をパッケージに含める必要がありますが、フォルダー自体は含めないでください。When deploying your project to a function app in Azure, the entire content of the FunctionApp folder should be included in the package, but not the folder itself. テストは、プロジェクト フォルダーとは別のフォルダー (この例では tests) に保存することをお勧めします。We recommend that you maintain your tests in a folder separate from the project folder, in this example tests. これにより、アプリでテスト コードをデプロイすることを防ぐことができます。This keeps you from deploying test code with your app. 詳細については、「単体テスト」を参照してください。For more information, see Unit Testing.

トリガーと入力Triggers and Inputs

Azure Functions では、入力はトリガー入力と追加入力の 2 つのカテゴリに分けられます。Inputs are divided into two categories in Azure Functions: trigger input and additional input. function.json ファイルではこれらは同じではありませんが、Python コードでは同じように使用されます。Although they are different in the function.json file, usage is identical in Python code. トリガーの接続文字列またはシークレットと入力ソースは、ローカル実行時には local.settings.json ファイル内の値にマップし、Azure での実行時にはアプリケーションの設定にマップします。Connection strings or secrets for trigger and input sources map to values in the local.settings.json file when running locally, and the application settings when running in Azure.

たとえば、次のコードでは 2 つの違いが示されています。For example, the following code demonstrates the difference between the two:

// function.json
{
  "scriptFile": "__init__.py",
  "bindings": [
    {
      "name": "req",
      "direction": "in",
      "type": "httpTrigger",
      "authLevel": "anonymous",
      "route": "items/{id}"
    },
    {
      "name": "obj",
      "direction": "in",
      "type": "blob",
      "path": "samples/{id}",
      "connection": "AzureWebJobsStorage"
    }
  ]
}
// local.settings.json
{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "python",
    "AzureWebJobsStorage": "<azure-storage-connection-string>"
  }
}
# __init__.py
import azure.functions as func
import logging


def main(req: func.HttpRequest,
         obj: func.InputStream):

    logging.info(f'Python HTTP triggered function processed: {obj.read()}')

この関数が呼び出されると、HTTP 要求は req として関数に渡されます。When the function is invoked, the HTTP request is passed to the function as req. エントリは、ルート URL 内の ID に基づいて Azure Blob Storage から取得され、関数の本体で obj として使用できるようになります。An entry will be retrieved from the Azure Blob Storage based on the ID in the route URL and made available as obj in the function body. ここで、指定されるストレージ アカウントは、AzureWebJobsStorage アプリ設定で見つかる接続文字列であり、関数アプリケーションで使用されるストレージ アカウントと同じものです。Here, the storage account specified is the connection string found in the AzureWebJobsStorage app setting, which is the same storage account used by the function app.

出力Outputs

出力は、戻り値および出力パラメーターの両方で表現できます。Output can be expressed both in return value and output parameters. 出力が 1 つのみの場合は、戻り値の使用をお勧めします。If there's only one output, we recommend using the return value. 出力が複数の場合は、出力パラメーターを使用する必要があります。For multiple outputs, you'll have to use output parameters.

出力バインディングの値として関数の戻り値を使用するには、バインディングの name プロパティを function.json 内の $return に設定する必要があります。To use the return value of a function as the value of an output binding, the name property of the binding should be set to $return in function.json.

複数の出力を生成するには、azure.functions.Out インターフェイスによって提供される set() メソッドを使用して、バインディングに値を割り当てます。To produce multiple outputs, use the set() method provided by the azure.functions.Out interface to assign a value to the binding. たとえば、次の関数を使用すると、キューにメッセージをプッシュすることに加え、HTTP 応答を返すこともできます。For example, the following function can push a message to a queue and also return an HTTP response.

{
  "scriptFile": "__init__.py",
  "bindings": [
    {
      "name": "req",
      "direction": "in",
      "type": "httpTrigger",
      "authLevel": "anonymous"
    },
    {
      "name": "msg",
      "direction": "out",
      "type": "queue",
      "queueName": "outqueue",
      "connection": "AzureWebJobsStorage"
    },
    {
      "name": "$return",
      "direction": "out",
      "type": "http"
    }
  ]
}
import azure.functions as func


def main(req: func.HttpRequest,
         msg: func.Out[func.QueueMessage]) -> str:

    message = req.params.get('body')
    msg.set(message)
    return message

ログ記録Logging

Azure Functions ランタイム ロガーへのアクセスは、ご利用の関数アプリ内のルート logging ハンドラーを介して利用できます。Access to the Azure Functions runtime logger is available via a root logging handler in your function app. このロガーは Application Insights に関連付けられているため、関数の実行中に検出される警告とエラーにフラグを設定することができます。This logger is tied to Application Insights and allows you to flag warnings and errors encountered during the function execution.

次の例では、HTTP トリガーを介して関数が呼び出されるときに、情報メッセージが記録されます。The following example logs an info message when the function is invoked via an HTTP trigger.

import logging


def main(req):
    logging.info('Python HTTP trigger function processed a request.')

他にもログ記録メソッドが用意されています。これにより、さまざまなトレース レベルでコンソールへの書き込みが可能になります。Additional logging methods are available that let you write to the console at different trace levels:

方法Method [説明]Description
critical(_message_) ルート ロガー上に CRITICAL レベルのメッセージを書き込みます。Writes a message with level CRITICAL on the root logger.
error(_message_) ルート ロガー上に ERROR レベルのメッセージを書き込みます。Writes a message with level ERROR on the root logger.
warning(_message_) ルート ロガー上に WARNING レベルのメッセージを書き込みます。Writes a message with level WARNING on the root logger.
info(_message_) ルート ロガー上に INFO レベルのメッセージを書き込みます。Writes a message with level INFO on the root logger.
debug(_message_) ルート ロガー上に DEBUG レベルのメッセージを書き込みます。Writes a message with level DEBUG on the root logger.

ログ記録の詳細については、「Azure Functions を監視する」を参照してください。To learn more about logging, see Monitor Azure Functions.

HTTP トリガーとバインディングHTTP Trigger and bindings

HTTP トリガーは function.jon ファイルで定義されています。The HTTP trigger is defined in the function.jon file. バインディングの name は、関数の名前付きパラメーターと一致している必要があります。The name of the binding must match the named parameter in the function. 前の例では、バインド名 req が使用されています。In the previous examples, a binding name req is used. このパラメーターは HttpRequest オブジェクトであり、HttpResponse オブジェクトが返されます。This parameter is an HttpRequest object, and an HttpResponse object is returned.

HttpRequest オブジェクトからは、要求ヘッダー、クエリ パラメーター、ルート パラメーター、およびメッセージ本文を取得できます。From the HttpRequest object, you can get request headers, query parameters, route parameters, and the message body.

次の例は、Python 用の HTTP トリガー テンプレートからのものです。The following example is from the HTTP trigger template for Python.

def main(req: func.HttpRequest) -> func.HttpResponse:
    headers = {"my-http-header": "some-value"}

    name = req.params.get('name')
    if not name:
        try:
            req_body = req.get_json()
        except ValueError:
            pass
        else:
            name = req_body.get('name')
            
    if name:
        return func.HttpResponse(f"Hello {name}!", headers=headers)
    else:
        return func.HttpResponse(
             "Please pass a name on the query string or in the request body",
             headers=headers, status_code=400
        )

この関数では、name クエリ パラメーターの値は HttpRequest オブジェクトの params パラメーターから取得されます。In this function, the value of the name query parameter is obtained from the params parameter of the HttpRequest object. JSON でエンコードされたメッセージ本文は get_json メソッドを使用して読み取られます。The JSON-encoded message body is read using the get_json method.

同様に、返される HttpResponse オブジェクトに応答メッセージの status_code および headers を設定できます。Likewise, you can set the status_code and headers for the response message in the returned HttpResponse object.

スケーリングとコンカレンシーScaling and concurrency

既定では、Azure Functions は、アプリケーションの負荷を自動的に監視し、必要に応じて Python 用に追加のホスト インスタンスを作成します。By default, Azure Functions automatically monitors the load on your application and creates additional host instances for Python as needed. 関数は、さまざまなトリガー型の組み込み(ユーザー設定不可)しきい値を使用して、メッセージの経過時間や QueueTrigger のキューサイズなど、インスタンスを追加するタイミングを決定します。Functions uses built-in (not user configurable) thresholds for different trigger types to decide when to add instances, such as the age of messages and queue size for QueueTrigger. 詳細については、「従量課金プランと Premium プランのしくみ」をご覧ください。For more information, see How the Consumption and Premium plans work.

多くのアプリケーションでは、このスケーリング動作で十分です。This scaling behavior is sufficient for many applications. ただし、次のいずれかの特性を持つアプリケーションは、効果的にスケーリングできない場合があります。Applications with any of the following characteristics, however, may not scale as effectively:

  • アプリケーションで多くの同時呼び出しを処理する必要がある。The application needs to handle many concurrent invocations.
  • アプリケーションが大量の I/O イベントを処理する。The application processes a large number of I/O events.
  • アプリケーションが I/O バインドされている。The application is I/O bound.

そのような場合、非同期パターンを採用し、複数の言語ワーカー プロセスを使用することで、パフォーマンスをさらに向上させることができます。In such cases, you can improve performance further by employing async patterns and by using multiple language worker processes.

非同期Async

Python はシングルスレッド ランタイムであるため、Python のホスト インスタンスは一度に 1 つの関数呼び出ししか処理できません。Because Python is a single-threaded runtime, a host instance for Python can process only one function invocation at a time. 大量の I/O イベントを処理するアプリケーションや、I/O バインドされているアプリケーションでは、関数を非同期に実行することによってパフォーマンスを向上させることができます。For applications that process a large number of I/O events and/or is I/O bound, you can improve performance by running functions asynchronously.

関数を非同期に実行するには、async def ステートメントを使用します。これにより、asyncio を使用して関数が直接実行されます。To run a function asynchronously, use the async def statement, which runs the function with asyncio directly:

async def main():
    await some_nonblocking_socket_io_op()

async キーワードを持たない関数は、自動的に asyncio スレッド プールで実行されます。A function without the async keyword is run automatically in an asyncio thread-pool:

# Runs in an asyncio thread-pool

def main():
    some_blocking_socket_io()

複数の言語ワーカー プロセスを使用するUse multiple language worker processes

既定では、すべての Functions ホスト インスタンスに 1 つの言語ワーカー プロセスがあります。By default, every Functions host instance has a single language worker process. FUNCTIONS_WORKER_PROCESS_COUNT アプリケーション設定を使用して、ホストごとのワーカー プロセスの数を増やすことができます (最大 10)。You can increase the number of worker processes per host (up to 10) by using the FUNCTIONS_WORKER_PROCESS_COUNT application setting. 次に、Azure Functions は、これらのワーカー間で同時関数呼び出しを均等に分散しようとします。Azure Functions then tries to evenly distribute simultaneous function invocations across these workers.

FUNCTIONS_WORKER_PROCESS_COUNT は、需要に応じてアプリケーションをスケールアウトするときに Functions が作成する各ホストに適用されます。The FUNCTIONS_WORKER_PROCESS_COUNT applies to each host that Functions creates when scaling out your application to meet demand.

ContextContext

実行中に関数の呼び出しコンテキストを取得するには、そのシグニチャに context 引数を含めます。To get the invocation context of a function during execution, include the context argument in its signature.

次に例を示します。For example:

import azure.functions


def main(req: azure.functions.HttpRequest,
         context: azure.functions.Context) -> str:
    return f'{context.invocation_id}'

コンテキスト クラスには次の文字列属性が含まれています。The Context class has the following string attributes:

function_directory
関数が実行されるディレクトリです。The directory in which the function is running.

function_name
関数の名前です。Name of the function.

invocation_id
現在の関数呼び出しの ID です。ID of the current function invocation.

グローバル変数Global variables

将来の実行に対してアプリの状態が保持されることは保証されません。It is not guaranteed that the state of your app will be preserved for future executions. ただし、Azure Functions ランタイムでは、多くの場合、同じアプリの複数の実行に対して同じプロセスが再利用されます。However, the Azure Functions runtime often reuses the same process for multiple executions of the same app. 高コストの計算の結果をキャッシュするには、グローバル変数として宣言します。In order to cache the results of an expensive computation, declare it as a global variable.

CACHED_DATA = None


def main(req):
    global CACHED_DATA
    if CACHED_DATA is None:
        CACHED_DATA = load_json()

    # ... use CACHED_DATA in code

環境変数Environment variables

Functions では、サービス接続文字列などのアプリケーション設定は、実行中に環境変数として公開されます。In Functions, application settings, such as service connection strings, are exposed as environment variables during execution. これらの設定にアクセスするには、import os を宣言してから setting = os.environ["setting-name"] を使用します。You can access these settings by declaring import os and then using, setting = os.environ["setting-name"].

次の設定では、myAppSetting という名前のキーのアプリケーション設定が取得されます。The following example gets the application setting, with the key named myAppSetting:

import logging
import os
import azure.functions as func

def main(req: func.HttpRequest) -> func.HttpResponse:

    # Get the setting named 'myAppSetting'
    my_app_setting_value = os.environ["myAppSetting"]
    logging.info(f'My app setting value:{my_app_setting_value}')

ローカル開発の場合、アプリケーション設定は local.settings.json ファイルに保持されますFor local development, application settings are maintained in the local.settings.json file.

Python バージョンPython version

現時点では、Azure Functions は Python 3.6.x と 3.7.x (公式の CPython ディストリビューション) の両方をサポートしています。Currently, Azure Functions supports both Python 3.6.x and 3.7.x (official CPython distributions). ローカルで実行する場合、ランタイムは使用可能な Python バージョンを使用します。When running locally, the runtime uses the available Python version. Azure で関数アプリを作成するときに特定の Python バージョンを要求するには、az functionapp create コマンドの --runtime-version オプションを使用します。To request a specific Python version when you create your function app in Azure, use the --runtime-version option of the az functionapp create command. バージョンの変更は、関数アプリの作成時にのみ許可されます。Version change is allowed only on Function App creation.

パッケージの管理Package management

Azure Functions Core Tools または Visual Studio Code を使用してローカルで開発を行う場合は、必要なパッケージの名前とバージョンを requirements.txt ファイルに追加し、pip を使用してそれらをインストールしてください。When developing locally using the Azure Functions Core Tools or Visual Studio Code, add the names and versions of the required packages to the requirements.txt file and install them using pip.

たとえば、次の要件のファイルと pip コマンドを使用すれば、PyPI から requests パッケージをインストールすることができます。For example, the following requirements file and pip command can be used to install the requests package from PyPI.

requests==2.19.1
pip install -r requirements.txt

Azure への発行Publishing to Azure

発行する準備ができたら、一般公開されているすべての依存関係が、プロジェクト ディレクトリのルートにある requirements.txt ファイルに一覧表示されていることを確認します。When you're ready to publish, make sure that all your publicly available dependencies are listed in the requirements.txt file, which is located at the root of your project directory.

発行から除外されたプロジェクト ファイルとフォルダー (仮想環境フォルダーなど) は、.funcignore ファイルに一覧表示されます。Project files and folders that are excluded from publishing, including the virtual environment folder, are listed in the .funcignore file.

Python プロジェクトを Azure に発行するために、次の 3 つのビルド アクションがサポートされています。There are three build actions supported for publishing your Python project to Azure:

  • リモート ビルド:依存関係は、requirements.txt ファイルの内容に基づいてリモートで取得されます。Remote build: Dependencies are obtained remotely based on the contents of the requirements.txt file. リモート ビルド は推奨されるビルド方法です。Remote build is the recommended build method. リモートは、Azure ツールの既定のビルド オプションでもあります。Remote is also the default build option of Azure tooling.
  • ローカル ビルド:依存関係は、requirements.txt ファイルの内容に基づいてローカルで取得されます。Local build: Dependencies are obtained locally based on the contents of the requirements.txt file.
  • カスタムの依存関係:プロジェクトがツールで公開されていないパッケージを使用しています。Custom dependencies: Your project uses packages not publicly available to our tools. (Docker が必要です。)(Requires Docker.)

継続的デリバリー (CD) システムを使って依存関係のビルドと発行を行うには、Azure パイプラインを使用します。To build your dependencies and publish using a continuous delivery (CD) system, use Azure Pipelines.

リモート ビルドRemote build

次の func azure functionapp publish コマンドを使用して Python プロジェクトを Azure に発行すると、既定では Azure Functions Core Tools によってリモート ビルドが要求されます。By default, the Azure Functions Core Tools requests a remote build when you use the following func azure functionapp publish command to publish your Python project to Azure.

func azure functionapp publish <APP_NAME>

<APP_NAME> を、Azure 内のご自分の関数アプリの名前に置き換えることを忘れないでください。Remember to replace <APP_NAME> with the name of your function app in Azure.

Visual Studio Code の Azure Functions 拡張機能も、既定ではリモート ビルドを要求します。The Azure Functions Extension for Visual Studio Code also requests a remote build by default.

ローカル ビルドLocal build

次の func azure functionapp publish コマンドを使用してローカル ビルドとして発行することで、リモート ビルドを実行しないようにすることができます。You can prevent doing a remote build by using the following func azure functionapp publish command to publish with a local build.

func azure functionapp publish <APP_NAME> --build local

<APP_NAME> を、Azure 内のご自分の関数アプリの名前に置き換えることを忘れないでください。Remember to replace <APP_NAME> with the name of your function app in Azure.

--build local オプションを使用すると、プロジェクトの依存関係が requirements.txt ファイルから読み取られ、これらの依存パッケージがローカルにダウンロードされ、インストールされます。Using the --build local option, project dependencies are read from the requirements.txt file and those dependent packages are downloaded and installed locally. プロジェクト ファイルと依存関係は、ローカル コンピューターから Azure にデプロイされます。Project files and dependencies are deployed from your local computer to Azure. これにより、大きいサイズのデプロイ パッケージが Azure にアップロードされます。This results in a larger deployment package being uploaded to Azure. 何らかの理由で、コア ツールが requirements.txt ファイルの依存関係を取得できない場合は、発行に際して [custom dependencies](カスタムの依存関係) オプションを使用する必要があります。If for some reason, dependencies in your requirements.txt file can't be acquired by Core Tools, you must use the custom dependencies option for publishing.

カスタムの依存関係Custom dependencies

ツールで公開されていないパッケージをプロジェクトに使用している場合は、それを __app__/.python_packages ディレクトリに配置することで、アプリで使用可能にすることができます。If your project uses packages not publicly available to our tools, you can make them available to your app by putting them in the __app__/.python_packages directory. 発行する前に次のコマンドを実行して、依存関係をローカルでインストールします。Before publishing, run the following command to install the dependencies locally:

pip install  --target="<PROJECT_DIR>/.python_packages/lib/site-packages"  -r requirements.txt

カスタムの依存関係を使用する場合は、既に依存関係がインストールされているため、--no-build 公開オプションを使用する必要があります。When using custom dependencies, you should use the --no-build publishing option, since you have already installed the dependencies.

func azure functionapp publish <APP_NAME> --no-build

<APP_NAME> を、Azure 内のご自分の関数アプリの名前に置き換えることを忘れないでください。Remember to replace <APP_NAME> with the name of your function app in Azure.

単体テストUnit Testing

Python で記述された関数は、標準的なテスト フレームワークを使用して、他の Python コードのようにテストできます。Functions written in Python can be tested like other Python code using standard testing frameworks. ほとんどのバインドでは、azure.functions パッケージから適切なクラスのインスタンスを作成することにより、モック入力オブジェクトを作成できます。For most bindings, it's possible to create a mock input object by creating an instance of an appropriate class from the azure.functions package. azure.functions パッケージはすぐには利用できないため、上記の「パッケージ管理」セクションの説明に従って、requirements.txt ファイルを使用してインストールしてください。Since the azure.functions package is not immediately available, be sure to install it via your requirements.txt file as described in the package management section above.

たとえば、次に示すのは、HTTP によってトリガーされる関数のモック テストです。For example, following is a mock test of an HTTP triggered function:

{
  "scriptFile": "__init__.py",
  "entryPoint": "my_function",
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "$return"
    }
  ]
}
# __app__/HttpTrigger/__init__.py
import azure.functions as func
import logging

def my_function(req: func.HttpRequest) -> func.HttpResponse:
    logging.info('Python HTTP trigger function processed a request.')

    name = req.params.get('name')
    if not name:
        try:
            req_body = req.get_json()
        except ValueError:
            pass
        else:
            name = req_body.get('name')

    if name:
        return func.HttpResponse(f"Hello {name}")
    else:
        return func.HttpResponse(
             "Please pass a name on the query string or in the request body",
             status_code=400
        )
# tests/test_httptrigger.py
import unittest

import azure.functions as func
from __app__.HttpTrigger import my_function

class TestFunction(unittest.TestCase):
    def test_my_function(self):
        # Construct a mock HTTP request.
        req = func.HttpRequest(
            method='GET',
            body=None,
            url='/api/HttpTrigger',
            params={'name': 'Test'})

        # Call the function.
        resp = my_function(req)

        # Check the output.
        self.assertEqual(
            resp.get_body(),
            b'Hello Test',
        )

キューによってトリガーされる関数の別の例を次に示します。Here is another example, with a queue triggered function:

{
  "scriptFile": "__init__.py",
  "entryPoint": "my_function",
  "bindings": [
    {
      "name": "msg",
      "type": "queueTrigger",
      "direction": "in",
      "queueName": "python-queue-items",
      "connection": "AzureWebJobsStorage"
    }
  ]
}
# __app__/QueueTrigger/__init__.py
import azure.functions as func

def my_function(msg: func.QueueMessage) -> str:
    return f'msg body: {msg.get_body().decode()}'
# tests/test_queuetrigger.py
import unittest

import azure.functions as func
from __app__.QueueTrigger import my_function

class TestFunction(unittest.TestCase):
    def test_my_function(self):
        # Construct a mock Queue message.
        req = func.QueueMessage(
            body=b'test')

        # Call the function.
        resp = my_function(req)

        # Check the output.
        self.assertEqual(
            resp,
            'msg body: test',
        )

一時ファイルTemporary files

tempfile.gettempdir() メソッドは一時フォルダーを返します。Linux では /tmp です。The tempfile.gettempdir() method returns a temporary folder, which on Linux is /tmp. アプリケーションは、実行中に関数が生成および使用する一時ファイルを格納するためにこのディレクトリを使用できます。Your application can use this directory to store temporary files generated and used by your functions during execution.

重要

一時ディレクトリに書き込まれるファイルは、呼び出しをまたいで保持されることは保証されません。Files written to the temporary directory aren't guaranteed to persist across invocations. スケールアウトの間、一時ファイルはインスタンス間で共有されません。During scale out, temporary files aren't shared between instances.

次の例では、名前付きの一時ファイルを一時ディレクトリ (/tmp) に作成します。The following example creates a named temporary file in the temporary directory (/tmp):

import logging
import azure.functions as func
import tempfile
from os import listdir

#---
   tempFilePath = tempfile.gettempdir()   
   fp = tempfile.NamedTemporaryFile()     
   fp.write(b'Hello world!')              
   filesDirListInTemp = listdir(tempFilePath)     

テストは、プロジェクト フォルダーとは別のフォルダーに保存することをお勧めします。We recommend that you maintain your tests in a folder separate from the project folder. これにより、アプリでテスト コードをデプロイすることを防ぐことができます。This keeps you from deploying test code with your app.

既知の問題とよくあるご質問Known issues and FAQ

既知の問題と機能に関する要望はすべて、GitHub issues リストを使用して追跡されます。All known issues and feature requests are tracked using GitHub issues list. 問題が発生してその問題が GitHub で見つからない場合は、新しい Issue を開き、その問題の詳細な説明を記載してお知らせください。If you run into a problem and can't find the issue in GitHub, open a new issue and include a detailed description of the problem.

クロス オリジン リソース共有Cross-origin resource sharing

Azure Functions では、クロス オリジン リソース共有 (CORS) がサポートされています。Azure Functions supports cross-origin resource sharing (CORS). CORS はポータル内でAzure CLI によって構成されます。CORS is configured in the portal and through the Azure CLI. CORS の許可配信元一覧は、関数アプリ レベルで適用されます。The CORS allowed origins list applies at the function app level. CORS を有効にすると、応答に Access-Control-Allow-Origin ヘッダーが含まれます。With CORS enabled, responses include the Access-Control-Allow-Origin header. 詳細については、「 クロス オリジン リソース共有」を参照してください。For more information, see Cross-origin resource sharing.

許可配信元一覧は、Python 関数アプリでは現在サポートされていませんThe allowed origins list isn't currently supported for Python function apps. この制限のため、次の例に示すように、HTTP 関数で Access-Control-Allow-Origin ヘッダーを明示的に設定する必要があります。Because of this limitation, you must expressly set the Access-Control-Allow-Origin header in your HTTP functions, as shown in the following example:

def main(req: func.HttpRequest) -> func.HttpResponse:

    # Define the allow origin headers.
    headers = {"Access-Control-Allow-Origin": "https://contoso.com"}

    # Set the headers in the response.
    return func.HttpResponse(
            f"Allowed origin '{headers}'.",
            headers=headers, status_code=200
    )

OPTIONS HTTP メソッドをサポートするように、function.json も更新してください。Make sure that you also update your function.json to support the OPTIONS HTTP method:

    ...
      "methods": [
        "get",
        "post",
        "options"
      ]
    ...

この HTTP メソッドは、許可配信元一覧をネゴシエートするために Web ブラウザーによって使用されます。This HTTP method is used by web browsers to negotiate the allowed origins list.

次のステップNext steps

詳細については、次のリソースを参照してください。For more information, see the following resources: