Azure Functions の開発を調べる

完了

関数には 2 つの重要な要素が含まれています。さまざまな言語で記述できるコードと、いくつかの構成、つまり function.json ファイルです。 コンパイル式の言語の場合、この構成ファイルはコード内の注釈から自動的に生成されます。 スクリプト言語の場合は、構成ファイルを自分で用意する必要があります。

function.json ファイルには、関数のトリガー、バインド、その他の構成設定を定義します。 すべての関数には、1 つだけトリガーがあります。 ランタイムはこの構成ファイルを使用して、監視対象のイベントを特定し、関数の実行との間でデータを渡したりデータを受け取ったりする方法を判断します。 以下に function.json ファイルの例を示します。

{
    "disabled":false,
    "bindings":[
        // ... bindings here
        {
            "type": "bindingType",
            "direction": "in",
            "name": "myParamName",
            // ... more depending on binding
        }
    ]
}

bindings プロパティで、トリガーとバインドの両方を構成します。 各バインドは、いくつかの一般的な設定と、バインドの特定の種類に固有の設定を共有します。 すべてのバインドには次の設定が必要です。

プロパティ 種類 説明
type string バインドの名前。 たとえば、「queueTrigger」のように入力します。
direction string バインドが関数への受信データか、関数からの送信データかを示します。 たとえば、in または out です。
name string 関数のバインドされたデータに使用される名前。 たとえば、「 myQueue 」のように入力します。

関数アプリ

関数アプリからは、関数が実行される、Azure における実行コンテキストが提供されます。 そのため、これが関数のデプロイと管理の単位となります。 関数アプリは、まとめて管理、デプロイ、およびスケールされる 1 つまたは複数の個々の関数で構成されます。 関数アプリ内のすべての関数は、同じ料金プラン、デプロイ方法、およびランタイム バージョンを共有します。 関数を整理し、まとめて管理する方法として関数アプリを考えてください。

注意

Functions 2.x では、関数アプリ内のすべての関数を同じ言語で作成する必要があります。 Azure Functions ランタイムの以前のバージョンでは、これは必須ではありませんでした。

フォルダー構造

特定の関数アプリ内のすべての関数のコードは、ホスト構成ファイルを含むルート プロジェクト フォルダーにあります。 host.json ファイルにはランタイム固有の構成が含まれています。このファイルは関数アプリのルート フォルダーにあります。 bin フォルダーには、関数アプリに必要なパッケージやその他のライブラリ ファイルが含まれています。 関数アプリが必要とする特定のフォルダー構造は、言語によって異なります。

ローカル開発環境

Functions では、ローカル コンピューター上でお気に入りのコード エディターや開発ツールを使用して、関数を作成し、テストすることができます。 ローカル関数はライブ Azure サービスに接続できるため、完全な Functions ランタイムを使用してローカル コンピューター上で関数をデバッグすることができます。

ローカル コンピューター上で関数を開発する方法は、言語とツールの設定によって異なります。 詳細については、「Azure Functions をローカルでコーディングしてテストする」を参照してください。

警告

同じ関数アプリにローカル開発とポータル開発を混在させないでください。 ローカル プロジェクトから関数を発行するときは、ポータルではプロジェクト コードを管理または変更しないようにしてください。