Azure Functions Core Tools の操作

  • [アーティクル]

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

Note

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

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

前提条件

Core Tools の具体的な前提条件は、使用する予定の機能によって異なります。

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

拡張機能のインストール: Core Tools を使用して拡張機能を手動でインストールするには、.NET 6.0 SDK がインストールされている必要があります。 .NET SDK は NuGet から拡張機能をインストールする目的で Core Tools によって使用されます。 Azure Functions 拡張機能を使用するために .NET の知識は必要ありません。

Core Tools のバージョン

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

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

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

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

Azure Functions Core Tools のインストール

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

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

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

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

Core Tools のバージョンの変更

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

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

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

Functions プロジェクトをローカルで作成する

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

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

  • Core Tools を使用すると、.NET ランタイム用の関数アプリ プロジェクトを、インプロセスおよび分離ワーカー プロセス C# クラス ライブラリ プロジェクト (.csproj) の両方として作成できます。 Visual Studio または Visual Studio Code で使用できるこれらのプロジェクトは、デバッグ中および 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 SDK をインストールする必要も、extensions.csproj ファイルを処理する必要もなくなります。

拡張バンドルは、C# 準拠プロジェクト以外の関数プロジェクトや C# スクリプトに推奨されるアプローチです。 これらのプロジェクトでは、拡張機能バンドル設定が、初期化中に host.json ファイルで生成されます。 バンドルが有効になっていない場合は、プロジェクトの host.json ファイルを更新する必要があります。

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

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

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

詳細については、「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 で接続文字列を指定することができます。

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

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

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

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

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

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

関数を作成する

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

func new

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

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

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

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

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

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

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

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

func start

Note

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 要求を使用してローカル サーバーでエンドポイントを呼び出します。 呼び出すエンドポイントは、関数の種類によって異なります。

Note

このトピックの例では、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 要求を使ってローカル サーバーでこのエンドポイントを呼び出すと、関数がトリガーされます。 functions 管理者エンドポイント (http://localhost:{port}/admin/functions/) を呼び出して、HTTP トリガーと非 HTTP トリガーの両方の使用可能なすべての関数の URL を取得できます。

ローカルで実行している場合、認証と認可はバイパスされます。 ただし、Azure の関数アプリで同じ管理者エンドポイントを呼び出す場合は、アクセス キーを指定する必要があります。 詳細については、「関数のアクセス キー」を参照してください。

重要

アクセス キーは重要な共有シークレットです。 ローカルで使用する場合は、ソース管理の外部に安全に保存する必要があります。 ローカルで実行する場合、Functions では認証と認可は必要ないため、シナリオで必要な場合を除きアクセス キーの使用と保存を避ける必要があります。

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 Functions Core Tools では、次の 2 種類のデプロイがサポートされています。

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

発行前

重要

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

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

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

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

重要

Azure portal で関数アプリを作成すると、既定でバージョン 4.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 を生成します。 このファイルはその後、デプロイするコンテナーを作成するときに使用されます。 Kubernetes を使用せずにカスタム コンテナーを Azure に発行する方法については、「カスタム コンテナーを使用して Linux で関数を作成する」を参照してください。

Core Tools を使用すると、プロジェクトをカスタム コンテナー イメージとして Kubernetes クラスターにデプロイできます。

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

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

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

拡張機能のインストール

拡張機能バンドルを使用できない場合、Azure Functions Core Tools をローカルで使用し、プロジェクトで必要とされる特定の拡張機能パッケージをインストールできます。

重要

拡張機能バンドルが有効になっている関数アプリに拡張機能を明示的にインストールすることはできません。 まず、拡張機能を明示的にインストールする前に、extensionBundlehost.json の セクションを削除します。

次の項目では、拡張機能の手動インストールが必要になる可能性のあるケースを説明します。

  • バンドルで利用できない特定のバージョンの拡張機能にアクセスする必要がある。
  • バンドルで利用できないカスタム拡張機能にアクセスする必要がある。
  • 1 つのバンドルで利用できない特定の組み合わせの拡張機能にアクセスする必要がある。

拡張機能を明示的にインストールすると、extensions.csproj という名前の .NET プロジェクト ファイルがプロジェクトのルートに追加されます。 このファイルによって、関数に必要とされる NuGet パッケージのセットが定義されます。 このファイルで NuGet パッケージ参照を使用することができますが、Core Tools では、C# プロジェクト ファイルを手動編集しなくても拡張機能をインストールできます。

Core Tools を使用し、ローカル プロジェクトで必要な拡張機能をインストールする方法がいくつかあります。

すべての拡張機能をインストールする

次のコマンドを使用し、ローカル プロジェクトのバインドで使用されるすべての拡張機能パッケージを自動追加します。

func extensions install

このコマンドでは、function.json ファイルを読み取って必要なパッケージを確認し、パッケージをインストールして、拡張プロジェクト (extensions.csproj) を再構築します。 現在のバージョンで新しいバインドが追加されますが、既存のバインドは更新されません。 新しいバージョンをインストールするときに、--force オプションを使用して既存のバインドを最新バージョンに更新します。 詳細については、func extensions install コマンドを参照してください。

Core Tools で認識されないバインドが関数または NuGet パッケージがアプリで使用されている場合、特定の拡張機能を手動インストールする必要があります。

特定の拡張機能をインストールする

次のコマンドを使用し、特定のバージョンの特定の拡張機能パッケージをインストールします。 これは、Storage 拡張機能の場合です。

func extensions install --package Microsoft.Azure.WebJobs.Extensions.Storage --version 5.0.0

このコマンドを使用して、互換性のある NuGet パッケージをインストールできます。 詳細については、func extensions install コマンドに関するセクションを参照してください。

関数の監視

関数の実行を監視するための推奨される方法は、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>

Note

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

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

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

func azure functionapp logstream <FunctionAppName> --browser

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

ARM64 での x86 エミュレーション

現在、Functions は ARM64 デバイスでのローカル Python 関数開発をサポートしていません。 次の手順を使用し、エミュレートされた x86 環境を実行することで、M1 チップを搭載した Mac で Python 関数を開発します。

ターミナルで Rosetta を有効にする

  1. Mac で Finder を開き、[Applications] (アプリケーション) を選び、[Terminal] (ターミナル) を見つけます。

  2. Control キーを押しながら [Terminal] (ターミナル) をクリックし、[Get Info] (情報の取得) を選びます。 ターミナルを複製して名前を変更することで、個別の並列環境を作成することもできます。

    Control キーを押しながら [Terminal] (ターミナル) をクリックして [Get Info] (情報の取得) を選んでいるスクリーンショット

  3. [Open using Rosetta] (Rosetta を使用して開く) を選びます。

    Rosetta を使用して開くように構成されたターミナルのスクリーンショット

  4. Rosetta が有効になったターミナルを開き、シェルが zsh であることを確認します。

  5. 次のコマンドを実行して、x86 エミュレーションを検証します。

    $ arch

    i386 という応答によって、ターミナルが x86 エミュレート環境で実行されていることが示されます。

必要なパッケージをインストールする

Functions で必要となるすべての依存関係をこの環境に再インストールします。これには、次のパッケージが含まれます。

また、Python プロジェクトで必要となるその他のパッケージも再インストールします。

エイリアスを設定する (省略可能)

必要に応じてエイリアスを設定して、Rosetta で適切なバージョンを簡単に参照できるようにすることができます。

zsh ターミナルを構成する .zshrc ファイルを作成する方法の例を次に示します。

# file: .zshrc
# rosetta terminal setup
if [ $(arch) = "i386" ]; then
    alias python="/usr/local/bin/python3"
    alias brew86='/usr/local/bin/brew'
    alias pyenv86="arch -x86_64 pyenv"
    alias func="/usr/local/Cellar/azure-functions-core-tools@4/4.0.4785/func"
fi

次のコマンドを実行して、エイリアスを適用します。

$ source .zshrc

次の例に示すように、which コマンドを使用して正しいバージョンを参照していることを確認します。

コマンド 応答の例
$ which python python: aliased to /usr/local/bin/python3
$ which func func: aliased to /usr/local/Cellar/azure-functions-core-tools@4/4.0.4785/func

これらの応答例は、前の例の .zshrc ファイルに基づいています。

これで、ターミナルから x86 環境で Azure Functions を使用するように設定しました。

Visual Studio Code を使用している場合は、Rosetta を組み込みのターミナルと統合できます。 詳細については、「Visual Studio Code でエミュレーションを有効にする」を参照してください。

次のステップ

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