Azure Functions Core Tools の操作

Azure Functions Core Tools を使用すると、ローカル コンピューター上のコマンド プロンプトまたはターミナルから関数を開発およびテストできます。 ローカル関数はライブ Azure サービスに接続できるため、完全な Functions ランタイムを使用してローカル コンピューター上で関数をデバッグすることができます。 Azure サブスクリプションに関数アプリをデプロイすることもできます。

重要

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

Core Tools を使用して、ローカル コンピューターで関数を開発し、Azure に発行する基本的な手順は次の通りです。

前提条件

現在、Azure Functions Core Tools では、Azure CLI または Azure PowerShell に依存して Azure アカウントでの認証を行っています。 つまり、Azure Functions Core Tools から Azure に発行できるようにするには、このいずれかのツールをインストールする必要があります。

Core Tools のバージョン

Azure Functions Core Tools には、4 つのバージョンがあります。 使用するバージョンは、ローカル開発環境、選択した言語、必要なサポートのレベルによって異なります。

各特定のバージョンと詳細なインストール手順の詳細については、以下のバージョン タブを選択します。

Functions ランタイムのバージョン 4.x をサポートします。 このバージョンでは Windows、macOS、Linux がサポートされ、インストールにはプラットフォーム固有のパッケージ マネージャーまたは npm が使用されます。 これは、Functions ランタイムと Core Tools で推奨されるバージョンです。

特定のコンピューターには、1 つのバージョンの Core Tools のみをインストールできます。 特に記載がない限り、この記事の例ではバージョン 3.x を対象にしています。

Azure Functions Core Tools のインストール

Azure Functions Core Tools には、Azure Functions ランタイムを実行するのと同じランタイムのバージョンが含まれており、ローカルの開発コンピューターで実行できます。 また、関数の作成、Azure への接続、関数プロジェクトのデプロイを行うコマンドも用意されています。

Core Tools はバージョン 2.x より、WindowsmacOSLinux 上で実行されます。

次の手順では、Windows インストーラー (MSI) を使用して Core Tools v4.x をインストールします。 その他のパッケージベースのインストーラーの詳細については、Core Tools の Readme をご覧ください。

Windows のバージョンに応じて、 以下の Core Tools インストーラーをダウンロードして実行します。

Core Tools のバージョンの変更

別のバージョンの Core Tools に変更する場合は、元のインストールと同じパッケージ マネージャーを使用して、別のパッケージ バージョンに移行する必要があります。 たとえば、npm を使用して Core Tools バージョン 2.x をインストールした場合は、次のコマンドを使用してバージョン 3.x にアップグレードする必要があります。

npm install -g azure-functions-core-tools@3 --unsafe-perm true

Windows で Windows インストーラー (MSI) を使用して Core Tools をインストールした場合は、別のバージョンをインストールする前に、[プログラムの追加と削除] から古いバージョンをアンインストールする必要があります。

ローカル関数プロジェクトを作成する

Functions プロジェクト ディレクトリには、言語に関係なく、次のファイルとフォルダーが含まれます。

ファイル名 説明
host.json 詳細については、「host.json のリファレンス」を参照してください。
local.settings.json アプリ設定など、ローカルで実行する場合に Core Tools によって使用される設定。 詳細については、ローカル設定に関するページを参照してください。
.gitignore local.settings.json ファイルが誤って Git リポジトリに発行されないようにします。 詳細については、ローカル設定に関するページを参照してください。
.vscode\extensions.json Visual Studio Code でプロジェクト フォルダーを開く際に使用される設定ファイル。

Functions プロジェクト フォルダーの詳細については、「Azure Functions の開発者向けガイド」を参照してください。

ターミナル ウィンドウまたはコマンド プロンプトで、次のコマンドを実行してプロジェクトおよびローカルの Git リポジトリを作成します。

func init MyFunctionProj

この例では、新しい MyFunctionProj フォルダーに Functions プロジェクトが作成されます。 プロジェクトの既定の言語を選択するように求めるダイアログが表示されます。

プロジェクトの初期化には、次の考慮事項が適用されます。

  • コマンドで --worker-runtime オプションを指定しない場合は、言語を選択するように求めるダイアログが表示されます。 詳しくは、「func init リファレンス」を参照してください。

  • プロジェクト名を指定しないと、現在のフォルダーが初期化されます。

  • プロジェクトをカスタム Linux コンテナーに発行する予定の場合は、--dockerfile オプションを使用して、プロジェクトに対して Dockerfile が生成されるようにします。 詳細については、「カスタム イメージを使用して Linux で関数を作成する」をご覧ください。

特定の言語には、追加の考慮事項がある場合があります。

  • 既定では、Core Tools のバージョン 2.x 以降のバージョンでは、.NET ランタイムの関数アプリ プロジェクトは C# クラス プロジェクト (.csproj) として作成されます。 バージョン 3.x では、分離プロセスで .NET 5.0 で実行される関数の作成もサポートされています。 Visual Studio または Visual Studio Code で使用できるこれらの C# プロジェクトは、デバッグ中および Azure への発行時にコンパイルされます。

  • C# スクリプト (csx) ファイルを使用してローカルで作業する場合は、--csx パラメーターを使用します。 これらのファイルは、Azure portal で関数を作成するとき、およびバージョン 1.x の Core Tools を使用するときに取得するものと同じです。 詳細については、「func init リファレンス」を参照してください。

拡張機能を登録する

ランタイム バージョン 2.x 以降では、Functions のトリガーとバインディングは .NET 拡張機能 (NuGet) パッケージとして実装されます。 コンパイル済みの C# プロジェクトの場合は、使用している特定のトリガーとバインディングの NuGet 拡張機能パッケージを参照するだけです。 HTTP バインドとタイマー トリガーには、拡張機能は必要ありません。

C# 以外のプロジェクトの開発エクスペリエンスを向上させるために、Functions では、host.json プロジェクト ファイルでバージョン付きの拡張バンドルを参照できます。 拡張機能バンドルを使用すると、すべての拡張機能をアプリで使用できるようになり、拡張機能間でパッケージの互換性の問題が発生する可能性を排除できます。 拡張機能バンドルでは、.NET Core 3.1 SDK をインストールする必要も、extensions.csproj ファイルを処理する必要もなくなります。

拡張機能バンドルは、C# でコンパイルされたプロジェクト以外の関数プロジェクトで推奨される方法です。 これらのプロジェクトでは、拡張機能バンドル設定が、初期化中に host.json ファイルで生成されます。 これで問題がない場合は、このセクション全体をスキップできます。

拡張機能バンドルを使用する

バインド拡張機能をインストールする最も簡単な方法は、拡張機能のバンドルを有効にすることです。 バンドルを有効にすると、事前定義された一連の拡張機能パッケージが自動的にインストールされます。

拡張機能のバンドルを有効にするには、host.json ファイルを開き、その内容を次のコードに合わせて更新します。

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[1.*, 2.0.0)"
    }
}

お使いの言語でサポートされている場合は、func init を呼び出した後、拡張機能バンドルは既に有効になっています。 function.json ファイルへのバインドを追加する前に、host.json に拡張機能のバンドルを追加する必要があります。 詳細については、「Azure Functions バインド拡張機能を登録する」を参照してください。

拡張機能を明示的にインストールする

.NET 以外のプロジェクトでは、バンドルに含まれていない拡張機能の特定のバージョンをターゲットにする必要がある場合など、拡張機能バンドルを使用できない場合があります。 このようなまれなケースでは、Core Tools を使用して、プロジェクトに必要な特定の拡張機能パッケージをローカルにインストールすることができます。 詳細については、「拡張機能を明示的にインストールする」を参照してください。

ローカル設定

Azure の関数アプリで実行する場合、関数に必要な設定はアプリ設定に安全に保存されます。 ローカル開発中は、これらの設定はその代わりに local.settings.json ファイルの Values オブジェクトに追加されます。 local.settings.json ファイルには、ローカルの開発ツールによって使用される設定も格納されます。

local.settings.json には接続文字列などのシークレットが含まれている場合があるため、リモート リポジトリには絶対に格納しないようにしてください。 ローカル設定の詳細については、「ローカル設定ファイル」を参照してください。

既定では、プロジェクトが Azure に発行されても、これらの設定は自動的に移行されません。 発行する際に --publish-local-settings オプション を使用し、これらの設定が Azure 内の関数アプリに追加されるようにしてください。 ConnectionStrings セクション内の値は発行されません。

関数アプリの設定値は、コードの中で環境変数として読み込むこともできます。 詳細については、以下の言語固有のリファレンス トピックの「環境変数」のセクションを参照してください。

有効なストレージ接続文字列が AzureWebJobsStorage に設定されていなく、エミュレーターが使用されていない場合は、次のエラー メッセージが表示されます。

local.settings.json に AzureWebJobsStorage の値がありません。 これは HTTP 以外のすべてのトリガーに必要です。 "func azure functionapp fetch-app-settings <functionAppName>" を実行するか、local.settings.json で接続文字列を指定することができます。

ストレージ接続文字列の取得

開発のために Microsoft Azure ストレージ エミュレーターを使用している場合であっても、実際のストレージに接続してローカルで実行したい場合があります。 ストレージ アカウントを作成済みである場合は、次のいずれかの方法で、有効なストレージ接続文字列を取得できます。

  1. Azure portal から、 [ストレージ アカウント] を検索して選択します。

    Azure portal で [ストレージ アカウント] を選択する

  2. 使用するストレージ アカウントを選択し、 [設定][アクセス キー] を選択してから、 [接続文字列] の値のいずれかをコピーします。

    Azure Portal から接続文字列をコピーする

関数を作成する

既存のプロジェクトで関数を作成するには、次のコマンドを実行します。

func new

バージョン 3.x または 2.x では、func new を実行すると、関数アプリの既定の言語でテンプレートを選択するように求められます。 次に、関数の名前を選択するように求められます。 バージョン 1.x では、さらに言語を選択するように求められます。

func new コマンドで関数名とテンプレートを指定することもできます。 次の例では、--template オプションを使用して、MyHttpTrigger という名前の HTTP トリガーを作成します。

func new --template "Http Trigger" --name MyHttpTrigger

この例では、MyQueueTrigger という名前の Queue Storage トリガーを作成します。

func new --template "Queue Trigger" --name MyQueueTrigger

詳細については、func new コマンドに関するセクションを参照してください。

関数をローカルで実行する

Functions プロジェクトを実行するには、プロジェクトのルート ディレクトリから Functions ホストを実行します。 ホストによって、プロジェクトのすべての関数に対するトリガーが有効になります。 start コマンドは、使用するプロジェクトの言語によって異なります。

func start

注意

Functions ランタイムのバージョン 1.x では、代わりに func host start を使用する必要があります。 詳細については、「Azure Functions Core Tools リファレンス」を参照してください。

Functions ホストの起動時に、次の例のような、HTTP によってトリガーされる関数の URL が出力されます。

Found the following functions:
Host.Functions.MyHttpTrigger

Job host started
Http Function MyHttpTrigger: http://localhost:7071/api/MyHttpTrigger

重要

ローカルで実行される場合、HTTP エンドポイントに対して承認は適用されません。 つまり、ローカルの HTTP 要求はすべて、authLevel = "anonymous" として処理されます。 詳細については、HTTP バインディングに関する記事を参照してください。

関数へのテスト データの受け渡し

関数をローカルでテストするには、Functions ホストを起動し、HTTP 要求を使用してローカル サーバーでエンドポイントを呼び出します。 呼び出すエンドポイントは、関数の種類によって異なります。

注意

このトピックの例では、cURL ツールを使用してターミナルまたはコマンド プロンプトから HTTP 要求を送信します。 お好みのツールを使用して HTTP 要求をローカル サーバーに送信できます。 Linux ベースのシステムと Windows 10 ビルド 17063 以降では既定で cURL ツールを使用できます。 以前の Windows では、最初に cURL ツールをダウンロードし、インストールする必要があります。

関数のテストの全般的な情報については、「Azure Functions のコードをテストするための戦略」を参照してください。

HTTP と webhook でトリガーされる関数

次のエンドポイントを呼び出して、HTTP と webhook でトリガーされる関数をローカルで実行できます。

http://localhost:{port}/api/{function_name}

Functions ホストがリッスンしているのと同じサーバー名とポートを使用していることを確認してください。 これは、Functions ホストの起動時に生成される出力で確認できます。 トリガーでサポートされている任意の HTTP メソッドを使用して、この URL を呼び出すことができます。

次の cURL コマンドは、MyHttpTrigger クイックスタート関数を、クエリ文字列で渡された name パラメーターを使用して、GET 要求からトリガーします。

curl --get http://localhost:7071/api/MyHttpTrigger?name=Azure%20Rocks

次の例は、要求本文で name を渡す POST 要求から呼び出される同じ関数です。

curl --request POST http://localhost:7071/api/MyHttpTrigger --data '{"name":"Azure Rocks"}'

ブラウザーから GET 要求を行ってクエリ文字列でデータを渡すことが可能です。 その他すべての HTTP メソッドについては、cURL、Fiddler、Postman、または POST 要求をサポートする類似の HTTP テスト ツールを使用する必要があります。

HTTP でトリガーされない関数

HTTP トリガーと Event Grid トリガーを除く、あらゆる関数で、"管理エンドポイント" と呼ばれる特別なエンドポイントを呼び出すことによって、REST を使用して関数をローカルでテストできます。 HTTP POST 要求を使ってローカル サーバーでこのエンドポイントを呼び出すと、関数がトリガーされます。

Event Grid でトリガーされた関数をローカルでテストする方法については、「ビューアー Web アプリでのローカル テスト」を参照してください。

必要に応じて、POST 要求の本体でテスト データを実行に渡すことができます。 この機能は、Azure Portal の [テスト] タブに似ています。

次の管理者エンドポイントを呼び出して、非 HTTP 関数をトリガーします。

http://localhost:{port}/admin/functions/{function_name}

テスト データを関数の管理者エンドポイントに渡すには、そのデータを POST 要求メッセージの本文で提供する必要があります。 メッセージ本文は、次の JSON 形式にする必要があります。

{
    "input": "<trigger_input>"
}

<trigger_input> 値には、関数が必要とする形式でデータが含まれています。 次の cURL の例は、QueueTriggerJS 関数に対する POST です。 この場合、入力は、キューにあることが期待されるメッセージに相当する文字列です。

curl --request POST -H "Content-Type:application/json" --data '{"input":"sample queue data"}' http://localhost:7071/admin/functions/QueueTrigger

Azure の関数アプリで管理者エンドポイントを呼び出す場合は、アクセス キーを指定する必要があります。 詳細については、「関数のアクセス キー」を参照してください。

Azure に発行する

Azure Functions Core Tools は、次の 3 種類のデプロイをサポートしています。

展開の種類 command 説明
プロジェクト ファイル func azure functionapp publish zip デプロイを使用し、関数プロジェクト ファイルを関数アプリに直接デプロイします。
カスタム コンテナー func deploy プロジェクトをカスタム Docker コンテナーとして Linux 関数アプリにデプロイします。
Kubernetes クラスター func kubernetes deploy Linux 関数アプリを、カスタマー Docker コンテナーとして Kubernetes クラスターにデプロイします。

発行前

重要

Core Tools から Azure に発行できるようにするには、Azure CLI または Azure PowerShell がローカルにインストールされている必要があります。

プロジェクト フォルダーには、発行するべきではない言語固有のファイルやディレクトリが含まれている場合があります。 除外された項目は、ルート プロジェクト フォルダーの .funcignore ファイルにリストされます。

コードをデプロイする Azure サブスクリプションで関数アプリを作成しておく必要があります。 コンパイルを必要とするプロジェクトは、バイナリをデプロイできるように、ビルドする必要があります。

Azure CLI または Azure PowerShell を使用してコマンド プロンプトまたはターミナル ウィンドウから関数アプリを作成する方法については、「サーバーレス実行用の Function App を作成する」を参照してください。

重要

Azure portal で関数アプリを作成すると、既定でバージョン 3.x の Function ランタイムが使用されます。 関数アプリにバージョン 1.x のランタイムを使用させるには、バージョン 1.x での実行に関するページの説明に従ってください。 既存の関数がある関数アプリのランタイム バージョンを変更することはできません。

プロジェクト ファイルのデプロイ

Azure で ローカル コードを関数アプリに発行するには、publish コマンドを使用します。

func azure functionapp publish <FunctionAppName>

このデプロイには、次の考慮事項が適用されます。

  • 発行すると、関数アプリ内の既存のファイルが上書きされます。

  • --publish-local-settings オプションを使用して、local.settings.json ファイルの値に基づいて、関数アプリにアプリ設定を自動的に作成します。

  • コンパイルされたプロジェクトでリモート ビルドが実行されます。 これは、--no-build オプションを使用して制御できます。

  • プロジェクトがデプロイされ、デプロイ パッケージから実行されます。 この推奨されるデプロイ モードを無効にするには、--nozip オプションを使用します。

  • Java では、Maven を使用して、ローカル プロジェクトが Azure に発行されます。 代わりに、コマンド mvn azure-functions:deploy を実行して、Azure に発行します。 Azure リソースは、初期デプロイ中に作成されます。

  • サブスクリプションに存在しない <FunctionAppName> に発行しようとすると、エラーが表示されます。

Kubernetes クラスター

Functions では、Docker コンテナーで実行するように Functions プロジェクトを定義することもできます。 func init--docker オプションを使用して、特定の言語の Dockerfile を生成します。 このファイルはその後、デプロイするコンテナーを作成するときに使用されます。

Core Tools を使用すると、プロジェクトをカスタム コンテナー イメージとして Kubernetes クラスターにデプロイできます。 使用するコマンドは、クラスターで使用されるスケーラーの種類によって異なります。

次のコマンドは、Dockerfile を使用してコンテナーを生成し、それを Kubernetes クラスターにデプロイします。

func kubernetes deploy --name <DEPLOYMENT_NAME> --registry <REGISTRY_USERNAME> 

詳細については、「Kubernetes への関数アプリのデプロイ」を参照してください。

Kubernetes を使用せずにカスタム コンテナーを Azure に発行する方法については、「カスタム コンテナーを使用して Linux で関数を作成する」を参照してください。

関数の監視

関数の実行を監視するための推奨される方法は、Azure Application Insights との統合です。 また、ローカル コンピューターに実行ログをストリーミングすることもできます。 詳細については、「Azure Functions を監視する」を参照してください。

Application Insights の統合

Azure で関数アプリを作成するときに Application Insights の統合を有効にする必要があります。 何らかの理由で関数アプリが Application Insights インスタンスに接続されていない場合は、Azure portal でこの統合を簡単に行うことができます。 詳細については、「Application Insights との統合を有効にする」を参照してください。

ストリーミング ログを有効にする

関数によって生成されているログ ファイルのストリームは、ローカル コンピューター上のコマンド ライン セッションで表示できます。

組み込みのログ ストリーミング

次の例のように、func azure functionapp logstream コマンドを使用して、Azure 内で実行されている特定の関数アプリのストリーミング ログの受信を開始します。

func azure functionapp logstream <FunctionAppName>

注意

従量課金プランの場合、組み込みのログ ストリーミングは、Linux で実行されている関数アプリの Core Tools でまだ有効になっていません。 これらのホスティング プランでは、代わりに Live Metrics Stream を使用してログをほぼリアルタイムで表示する必要があります。

ライブ メトリック ストリーム

次の例に示すように、--browser オプションを含めることで、関数アプリの Live Metrics Stream を新しいブラウザー ウィンドウで表示できます。

func azure functionapp logstream <FunctionAppName> --browser

この種類のストリーミング ログを使用するには、関数アプリの Application Insights との統合を有効にする必要があります。

次のステップ

Azure Functions Core Tools Microsoft 学習モジュール を使用して Azure Functions を開発、テスト、および発行する方法について説明します。Azure Functions Core Tools はオープンソースであり、GitHub でホストされています。
バグまたは機能要求を提出するには、GitHub の問題をオープンしてください。