Core Tools を使用してローカルで Azure Functions を開発する

[アーティクル]
11/14/2023

Azure Functions Core Tools を使用すると、ローカルコンピューター上で関数を開発およびテストできます。準備ができたら、Core Tools を使用してコードプロジェクトを Azure にデプロイし、アプリケーション設定を操作することもできます。

この記事の C# バージョンが表示されています。記事の冒頭で、必ず好みの Functions のプログラミング言語を選択してください。

すぐに作業を開始したい場合は、「Core Tools のクイックスタートに関する記事」を完了してください。

この記事の Java バージョンが表示されています。記事の冒頭で、必ず好みの Functions のプログラミング言語を選択してください。

すぐに作業を開始したい場合は、「Core Tools のクイックスタートに関する記事」を完了してください。

この記事の JavaScript バージョンが表示されています。記事の冒頭で、必ず好みの Functions のプログラミング言語を選択してください。

すぐに作業を開始したい場合は、「Core Tools のクイックスタートに関する記事」を完了してください。

この記事の PowerShell バージョンが表示されています。記事の冒頭で、必ず好みの Functions のプログラミング言語を選択してください。

すぐに作業を開始したい場合は、「Core Tools のクイックスタートに関する記事」を完了してください。

この記事の Python バージョンが表示されています。記事の冒頭で、必ず好みの Functions のプログラミング言語を選択してください。

すぐに作業を開始したい場合は、「Core Tools のクイックスタートに関する記事」を完了してください。

この記事の TypeScript バージョンが表示されています。記事の冒頭で、必ず好みの Functions のプログラミング言語を選択してください。

すぐに作業を開始したい場合は、「Core Tools のクイックスタートに関する記事」を完了してください。

Azure Functions Core Tools のインストール

Core Tools をインストールするための推奨される方法は、ローカル開発用コンピューターのオペレーティングシステムによって異なります。

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

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

v4.x - Windows 64 ビット (推奨。Visual Studio Code デバッグには 64 ビットが必要です)。
v4.x - Windows 32 ビット

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

次の手順で、Homebrew を使用して macOS 上に Core Tools をインストールします。

まだインストールしていない場合は、Homebrew をインストールします。

次のコマンドを使って、Core Tools のパッケージをインストールします。

brew tap azure/functions
brew install azure-functions-core-tools@4
# if upgrading on a machine that has 2.x or 3.x installed:
brew link --overwrite azure-functions-core-tools@4

次の手順で APT 使用して、Ubuntu/Debian Linux ディストリビューションに Core Tools をインストールします。他の Linux ディストリビューションについては、Core Tools の readme に関するページを参照してください。

パッケージの整合性を検証するには、Microsoft パッケージリポジトリの GPG キーをインストールします。

curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg
sudo mv microsoft.gpg /etc/apt/trusted.gpg.d/microsoft.gpg

APT 更新を行う前に、APT ソースリストを設定します。

Ubuntu

sudo sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/repos/microsoft-ubuntu-$(lsb_release -cs 2>/dev/null)-prod $(lsb_release -cs 2>/dev/null) main" > /etc/apt/sources.list.d/dotnetdev.list'

Debian

sudo sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/debian/$(lsb_release -rs 2>/dev/null | cut -d'.' -f 1)/prod $(lsb_release -cs 2>/dev/null) main" > /etc/apt/sources.list.d/dotnetdev.list'

/etc/apt/sources.list.d/dotnetdev.list ファイルを調べて、次の表に示す適切な Linux バージョン文字列のいずれかがあることを確認します。

Linux ディストリビューション	バージョン
Debian 12	`bookworm`
Debian 11	`bullseye`
Debian 10	`buster`
Debian 9	`stretch`
Ubuntu 22.04	`jammy`
Ubuntu 20.04	`focal`
Ubuntu 19.04	`disco`
Ubuntu 18.10	`cosmic`
Ubuntu 18.04	`bionic`
Ubuntu 17.04	`zesty`
Ubuntu 16.04/Linux Mint 18	`xenial`

APT ソースの更新を開始します。
```
sudo apt-get update
```
次のコマンドを使って、Core Tools のパッケージをインストールします。
```
sudo apt-get install azure-functions-core-tools-4
```

バージョン関連の問題のヘルプについては、「Core Tools のバージョン」を参照してください。

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

重要

Python の場合は、仮想環境で Core Tools コマンドを実行する必要があります。詳細については、「クイックスタート: Azure でコマンドラインから Python 関数を作成する」を参照してください。

ターミナルウィンドウまたはコマンドプロンプトで次のコマンドを実行して、MyProjFolder フォルダーにプロジェクトを作成します。

分離ワーカーモデル
インプロセスモデル

func init MyProjFolder --worker-runtime dotnet-isolated

既定では、このコマンドは、現在の長期サポート (LTS) バージョンの .NET Core で Functions ホストを使用してインプロセスで実行されるプロジェクトを作成します。 --target-framework オプションを使用して、.NET Framework を含む、サポートされている特定のバージョンの .NET をターゲットにすることができます。詳しくは、func init のリファレンスを参照してください。

func init MyProjFolder --worker-runtime dotnet

このコマンドは、現在の長期サポート (LTS) バージョンの .NET Core で実行されるプロジェクトを作成します。他の .NET バージョンについては、Functions ホストから分離されたワーカープロセスで実行されるアプリを作成します。

2 つの .NET プロセスモデル間の比較については、プロセスモードの比較に関する記事を参照してください。

Java では、Maven アーキタイプを使用して、最初の HTTP によってトリガーされる関数と共にローカルプロジェクトを作成します。 func init と func new を使用する代わりに、コマンドラインクイックスタートの手順に従ってください。

func init MyProjFolder --worker-runtime javascript --model V4

func init MyProjFolder --worker-runtime javascript --model V3

このコマンドは、必要なプログラミングモデルのバージョンを使用する JavaScript プロジェクトを作成します。

func init MyProjFolder --worker-runtime typescript --model V4

func init MyProjFolder --worker-runtime typescript --model V3

このコマンは、必要なプログラミングモデルのバージョンを使用する TypeScript プロジェクトを作成します。

func init MyProjFolder --worker-runtime powershell

func init MyProjFolder --worker-runtime python --model V2

func init MyProjFolder --worker-runtime python

このコマンドは、必要なプログラミングモデルのバージョンを使用する Python プロジェクトを作成します。

--worker-runtime オプションを指定せずに func init を実行すると、プロジェクトの言語を選択するよう求められます。 func init コマンドで使用できるオプションの詳細については、func init リファレンスを参照してください。

関数を作成する

プロジェクトに関数を追加するには、--template オプションを使用して func new コマンドを実行し、トリガーテンプレートを選択します。次の例では、MyHttpTrigger という名前の HTTP トリガーを作成します。

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

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

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

関数を追加する場合は、次の考慮事項が適用されます。

--template オプションを指定せずに func new を実行すると、テンプレートを選択するよう求められます。
各言語で使用可能なテンプレートの完全な一覧を表示するには、func templates list コマンドを使用します。
サービスに接続するトリガーを追加する場合は、接続文字列またはマネージド ID を参照するアプリケーション設定を local.settings.json ファイルに追加する必要もあります。この方法でアプリケーション設定を使用すると、コードに資格情報を埋め込む必要がなくなります。詳細については、「アプリケーション設定の操作」を参照してください。

Core Tools では、特定のバインド拡張機能への参照も C# プロジェクトに追加されます。

func new コマンドで使用できるオプションの詳細については、func new リファレンスを参照してください。

関数にバインドを追加する

Functions には一連のサービス固有の入出力バインディングが用意されているため、サービス固有のクライアント SDK を使用しなくても、関数で他の Azure サービスに簡単に接続できます。詳細については、「Azure Functions でのトリガーとバインドの概念」を参照してください。

既存の関数に入力または出力のバインドを追加するには、関数の定義を手動で更新する必要があります。

次の例は、キューストレージの出力バインドを HTTP によってトリガーされる関数に追加した後の関数の定義を示しています。

分離プロセス
インプロセス

HTTP によってトリガーされる関数は HTTP 応答も返すため、この関数は、HTTP とキューの両方の出力を表す MultiResponse オブジェクトを返します。

[Function("HttpExample")]
public static MultiResponse Run([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req,
    FunctionContext executionContext)
{

この出力バインディングを含む MultiResponse オブジェクトの定義の例をこちらに示します。

public class MultiResponse
{
    [QueueOutput("outqueue",Connection = "AzureWebJobsStorage")]
    public string[] Messages { get; set; }
    public IActionResult HttpResponse { get; set; }
}

この例を独自のプロジェクトに適用する際には、ASP.NET Core 統合を使用しているかどうかによって、HttpRequest を HttpRequestData に、IActionResult を HttpResponseData に変更する必要がある場合があります。

[FunctionName("HttpExample")]
public static async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequest req, 
    [Queue("outqueue"),StorageAccount("AzureWebJobsStorage")] ICollector<string> msg, 
    ILogger log)

メッセージは、関数が完了したときにキューに送信されます。出力バインドを定義する方法は、プロセスモデルによって異なります。参照できるバインドコードの例へのリンクなど、詳細については、「関数へのバインドの追加」を参照してください。

@FunctionName("HttpExample")
public HttpResponseMessage run(
        @HttpTrigger(name = "req", methods = {HttpMethod.GET, HttpMethod.POST}, authLevel = AuthorizationLevel.ANONYMOUS) 
        HttpRequestMessage<Optional<String>> request, 
        @QueueOutput(name = "msg", queueName = "outqueue", 
        connection = "AzureWebJobsStorage") OutputBinding<String> msg, 
        final ExecutionContext context) {

参照できるバインドコードの例へのリンクなど、詳細については、「関数へのバインドの追加」を参照してください。

Node.js モデル v4 のバインド例は、まだ提供されていません。

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": ["get", "post"]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    },
    {
      "type": "queue",
      "direction": "out",
      "name": "msg",
      "queueName": "outqueue",
      "connection": "AzureWebJobsStorage"
    }
  ]
}

出力バインドを定義する方法は、Node.js モデルのバージョンによって異なります。参照できるバインドコードの例へのリンクなど、詳細については、「関数へのバインドの追加」を参照してください。

$outputMsg = $name
Push-OutputBinding -name msg -Value $outputMsg

参照できるバインドコードの例へのリンクなど、詳細については、「関数へのバインドの追加」を参照してください。

@app.route(route="HttpExample")
@app.queue_output(arg_name="msg", queue_name="outqueue", connection="AzureWebJobsStorage")
def HttpExample(req: func.HttpRequest, msg: func.Out [func.QueueMessage]) -> func.HttpResponse:
    logging.info('Python HTTP trigger function processed a request.')

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": ["get", "post"]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    },
    {
      "type": "queue",
      "direction": "out",
      "name": "msg",
      "queueName": "outqueue",
      "connection": "AzureWebJobsStorage"
    }
  ]
}

出力バインドを定義する方法は、Python モデルのバージョンによって異なります。参照できるバインドコードの例へのリンクなど、詳細については、「関数へのバインドの追加」を参照してください。

Node.js モデル v4 のバインド例は、まだ提供されていません。

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": ["get", "post"]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    },
    {
      "type": "queue",
      "direction": "out",
      "name": "msg",
      "queueName": "outqueue",
      "connection": "AzureWebJobsStorage"
    }
  ]
}

バインドを関数に追加する場合は、次の考慮事項が適用されます。

function.json 構成ファイルを使用して関数を定義する言語の場合、Visual Studio Code では、既存の関数の定義にバインドを追加するプロセスが簡略化されます。詳細については、「バインドを使用して関数を Azure サービスに接続する」を参照してください。

サービスに接続するトリガーを追加する場合は、接続文字列またはマネージド ID を参照するアプリケーション設定を local.settings.json ファイルに追加する必要もあります。詳細については、「アプリケーション設定の操作」を参照してください。

サポートされているバインドを追加する場合、アプリで拡張機能バンドルを使用している場合は、拡張機能が既にインストールされている必要があります。詳細については、「拡張機能のバンドル」参照してください。

新しいバインド拡張機能を必要とするバインドを追加する場合は、その特定のバインド拡張機能への参照も C# プロジェクトに追加する必要があります。

参照できるバインドコードの例へのリンクなど、詳細については、「関数へのバインドの追加」を参照してください。

Functions ランタイムを開始する

プロジェクトで関数を実行またはデバッグする前に、プロジェクトのルートディレクトリから Functions ホストを起動する必要があります。ホストによって、プロジェクトのすべての関数に対するトリガーが有効になります。ローカルランタイムを起動するには、次のコマンドを使用します。

mvn clean package 
mvn azure-functions:run

分離ワーカーモデル
インプロセスモデル

func start

func start

重要

Core Tools のバージョン 4.0.6517 以降、インプロセスモデルプロジェクトではMicrosoft.NET.Sdk.Functions のバージョン 4.5.0 以降を参照する必要があります。以前のバージョンが使用されている場合、func start コマンドはエラーになります。

func start

npm install
npm start

このコマンドは仮想環境で実行する必要があります。

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" として処理されます。詳細については、「認可レベル」を参照してください。 --enableAuth オプションを使用して、ローカルで実行するときに認可を要求できます。詳細については、func start を参照してください
Azure Storage サービス (Queue Storage、Blob Storage、および Table Storage) へのアクセスを必要とする関数を Azure 内のこれらのサービスに接続することなくローカルで実行するには、ローカル Azurite エミュレーターを使用することができます。ローカルエミュレーションを使用する際には、ローカルホスト (func.exe) を開始する前に Azurite を起動するようにしてください。詳細については、「ローカルストレージエミュレーション」を参照してください。

ローカル Azurite エミュレーションを使用して、Python v2 worker のストレージ要件を満たすことができます。

ライブサービスに接続しなくても、HTTP 以外の関数をローカルでトリガーできます。詳細については、「ローカル関数を実行する」を参照してください。
local.settings.json ファイルに Application Insights 接続情報を含めると、ローカルログデータが特定の Application Insights インスタンスに書き込まれます。ローカルテレメトリデータを運用データから分離するには、開発とテストに個別の Application Insights インスタンスを使用することを検討してください。

Core Tools のバージョン 1.x を使用する場合は、代わりに func host start コマンドを使用してローカルランタイムを開始します。

ローカル関数を実行する

実行中のローカルの Functions ホスト (func.exe) を使用して、個々の関数をトリガーして関数コードを実行およびデバッグできるようになりました。個々の関数を実行する方法は、トリガーの種類によって異なります。

Note

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

HTTP トリガーは、func.exe 出力に表示されるように、次の一般的な形式のローカルエンドポイントとポートに HTTP 要求を送信することによって開始されます。

http://localhost:<PORT>/api/<FUNCTION_NAME>

この URL テンプレートで、<FUNCTION_NAME> は関数またはルートの名前であり、<PORT> は func.exe がリッスンしているローカルポートです。

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

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

この例は、要求本文で name を渡す POST 要求から呼び出される同じ関数であり、Bash シェルと Windows コマンドラインの両方で示されています。

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

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

HTTP エンドポイントをローカルで呼び出す場合は、次の考慮事項が適用されます。

ブラウザーから GET 要求を行ってクエリ文字列でデータを渡すことが可能です。その他すべての HTTP メソッドでは、データの安全性も保つ HTTP テストツールを使用する必要があります。詳細については、「HTTP テストツール」を参照してください。
Functions ホストがリッスンしているのと同じサーバー名とポートを使用していることを確認してください。このようなエンドポイントは、関数ホストの起動時に生成される出力で確認できます。トリガーでサポートされている任意の HTTP メソッドを使用して、この URL を呼び出すことができます。

HTTP 以外のトリガーをローカルで実行するには、2 つの方法があります。まず、Azure Storage や Azure Service Bus などのライブ Azure サービスに接続できます。この場合、Azure で実行するときの関数の動作が直接反映されます。ライブサービスを使用する場合は、必要な名前付き接続文字列をローカル設定ファイルに含めるようにしてください。開発中は、Azure の関数アプリ設定で使用する接続文字列とは異なる接続文字列を local.settings.json ファイルで使用して、運用環境とは異なるサービス接続を使用することを検討できます。

Event Grid トリガーをローカルで実行するには、追加の構成が必要です。

"管理者エンドポイント" と呼ばれる特別なエンドポイントを呼び出すことで、REST を使用して HTTP 以外の関数をローカルで実行することもできます。 admin エンドポイントを呼び出して、特定の非 HTTP 関数をトリガーするには、次の形式を使用します。

http://localhost:<PORT>/admin/functions/<FUNCTION_NAME>

この URL テンプレートで、<FUNCTION_NAME> は関数またはルートの名前であり、<PORT> は func.exe がリッスンしているローカルポートです。

必要に応じて、POST 要求の本体でテストデータを実行に渡すことができます。テストデータを渡すには、POST 要求メッセージの本文でデータを提供する必要があります。メッセージ本文は次の JSON 形式です。

{
    "input": "<TRIGGER_INPUT>"
}

<TRIGGER_INPUT> 値には、関数が必要とする形式でデータが含まれています。次の cURL の例は、Bash シェルと Windows コマンドラインの両方で示されています。

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

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

前の例では、文字列 sample queue data を QueueTrigger 関数という名前の関数に渡す POST 要求を生成しています。これは、キューに到達し、関数をトリガーするデータをシミュレートしています。

ローカルテストに管理者エンドポイントを使用する場合は、次の考慮事項が適用されます。

functions 管理者エンドポイント (http://localhost:{port}/admin/functions/) を呼び出して、HTTP トリガーと非 HTTP トリガーの両方の使用可能なすべての関数の URL を取得できます。
ローカルで実行する場合、認証と認可はバイパスされます。 Azure にも同じ API がありますが、Azure の同じ管理者エンドポイントを呼び出す場合は、アクセスキーを指定する必要があります。詳細については、「アクセスキーの使用」を参照してください。
アクセスキーは重要な共有シークレットです。ローカルで使用する場合は、ソース管理の外部に安全に保存する必要があります。ローカルで実行する場合、Functions では認証と認可は必要ないため、シナリオで必要な場合を除きアクセスキーの使用と保存を避ける必要があります。
管理者エンドポイントを呼び出してテストデータを渡す方法は、Azure portal の [テスト] タブを使用する方法に似ています。

Azure に発行する

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

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

Core Tools から Azure に発行できるようにするには、Azure CLI または Azure PowerShell のいずれかがローカルにインストールされている必要があります。既定では、Core Tools はこれらのツールを使用して Azure アカウントで認証します。

これらのツールがインストールされていない場合は、代わりに、展開中に使用する有効なアクセストークンを取得する必要があります。デプロイコマンドの --access-token オプションを使用して、アクセストークンを提示できます。

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

Azure でローカルコードを関数アプリに発行するには、次の例のように func azure functionapp publish コマンドを使用します:

func azure functionapp publish <FunctionAppName>

このコマンドは、プロジェクトファイルを現在のディレクトリから .zip 展開パッケージとして <FunctionAppName> に発行します。プロジェクトにコンパイルが必要な場合は、展開中にリモートで実行されます。

Java では、Maven を使用して、Core Tools ではなくローカルプロジェクトを Azure に発行します。次の Maven コマンドを使用して、プロジェクトを Azure に発行します:

mvn azure-functions:deploy

このコマンドを実行すると、pom.xml ファイルの設定に基づいて、初期デプロイ中に Azure リソースが作成されます。詳細については、「関数プロジェクトを Azure にデプロイする」を参照してください。

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

発行すると、リモート関数アプリのデプロイ内の既存のファイルが上書きされます。
既に Azure サブスクリプションで関数アプリを作成してある必要があります。 Core Tools は、プロジェクトコードをこの関数アプリリソースにデプロイします。 Azure CLI または Azure PowerShell を使用してコマンドプロンプトまたはターミナルウィンドウから関数アプリを作成する方法については、「サーバーレス実行用の Function App を作成する」を参照してください。これらのリソースを Azure portal で作成することもできます。サブスクリプションに存在しない <FunctionAppName> を公開しようとすると、エラーが表示されます。
プロジェクトフォルダーには、発行するべきではない言語固有のファイルやディレクトリが含まれている場合があります。除外された項目は、ルートプロジェクトフォルダーの .funcignore ファイルにリストされます。
既定では、プロジェクトがデプロイパッケージから実行されるようにデプロイされます。この推奨されるデプロイモードを無効にするには、--nozip オプションを使用します。
コンパイルされたプロジェクトでリモートビルドが実行されます。これは、--no-build オプションを使用して制御できます。
--publish-local-settings オプションを使用して、local.settings.json ファイルの値に基づいて、関数アプリにアプリ設定を自動的に作成します。
関数アプリの特定の名前付きスロットに公開するには、--slot オプションを使用します。

コンテナーをデプロイする

Core Tools を使用すると、マネージド Azure Container Apps 環境と、管理する Kubernetes クラスターの両方にコンテナー化された関数アプリをデプロイできます。

コンテナーアプリ
Kubernetes クラスター

次の func azurecontainerapps deploy コマンドを使用して、既存のコンテナーイメージを Container Apps 環境にデプロイします:

func azurecontainerapps deploy --name <APP_NAME> --environment <ENVIRONMENT_NAME> --storage-account <STORAGE_CONNECTION> --resource-group <RESOURCE_GROUP> --image-name <IMAGE_NAME> [--registry-password] [--registry-server] [--registry-username]

Azure Container Apps 環境にデプロイする場合は、次の考慮事項が適用されます。

環境とストレージアカウントが既に存在している必要があります。指定したストレージアカウント接続文字列は、デプロイされた関数アプリによって使用されます。
Container Apps にデプロイするときは、別の関数アプリリソースを作成する必要はありません。
ストレージ接続文字列とその他のサービス資格情報は重要なシークレットです。 func azurecontainerapps deploy を使用してスクリプトファイルを安全に格納し、パブリックにアクセス可能なソース管理システムには保存しないようにしてください。 local.settings.json ファイルを暗号化して、セキュリティを強化することができます。

詳細については、「Azure Functions の Azure Container Apps ホスティング」を参照してください。

次の func kubernetes deploy コマンドを使うと、Dockerfile を使用して特定のレジストリにコンテナーが生成され、それが Kubernetes クラスターにデプロイされます。

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

KEDA を使用する Kubernetes の Azure Functions は、無料で使用できるオープンソースの取り組みです。ベストエフォートサポートは、共同作成者とコミュニティから提供されます。詳細については、「Kubernetes への関数アプリのデプロイ」を参照してください。

ローカルでアプリの設定を操作する

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

プロジェクトの local.settings.json ファイルの Values コレクションにある項目は、Azure の関数アプリのアプリケーション設定にある項目をミラー化するためのものです。

ローカル設定ファイルを使用する場合は、次の考慮事項が適用されます。

local.settings.json には接続文字列などのシークレットが含まれている場合があるため、リモートリポジトリには絶対に格納しないようにしてください。 Core Tools は、このローカル設定ファイルを暗号化してセキュリティを強化するのに役立ちます。詳細については、「ローカル設定ファイル」を参照してください。 local.settings.json ファイルを暗号化して、セキュリティを強化することもできます。
既定では、プロジェクトが Azure に発行されても、これらの設定は自動的に移行されません。プロジェクトファイルを発行する際に --publish-local-settings オプションを使用し、これらの設定が Azure 内の関数アプリに追加されるようにしてください。 ConnectionStrings セクション内の値は発行されません。また、いつでも local.settings.json ファイルから設定をアップロードすることができます。
local.settings.json ファイルの設定をダウンロードして、Azure の関数アプリの設定で上書きすることができます。詳細については、「アプリケーション設定のダウンロード」を参照してください。

関数アプリの設定値は、コードの中で環境変数として読み込むこともできます。詳細については、「環境変数」を参照してください。

関数アプリの設定値は、コードの中で環境変数として読み込むこともできます。詳細については、「環境変数」を参照してください。

関数アプリの設定値は、コードの中で環境変数として読み込むこともできます。詳細については、「環境変数」を参照してください。

関数アプリの設定値は、コードの中で環境変数として読み込むこともできます。詳細については、「環境変数」を参照してください。

関数アプリの設定値は、コードの中で環境変数として読み込むこともできます。詳細については、「環境変数」を参照してください。

AzureWebJobsStorage に有効なストレージ接続文字列が設定されておらず、ローカルストレージエミュレーターが使用されていない場合は、エラーメッセージが表示されます。 Core Tools を使用して、任意の Azure Storage アカウントから特定の接続文字列をダウンロードできます。

アプリケーション設定をダウンロードする

プロジェクトのルートから、次のコマンドを使用して、Azure の myfunctionapp12345 アプリからすべてのアプリケーション設定をダウンロードします。

func azure functionapp fetch-app-settings myfunctionapp12345

このコマンドは、local.settings.json ファイル内のすべての既存の設定を Azure の値で上書きします。既に存在していない場合は、新しい項目がコレクションに追加されます。詳細については、func azure functionapp fetch-app-settings コマンドを参照してください。

ストレージ接続文字列のダウンロード

また、Core Tools を使用すると、アクセスできる任意のストレージアカウントの接続文字列を簡単に取得できます。プロジェクトのルートから、次のコマンドを使用して、mystorage12345 という名前のストレージアカウントから接続文字列をダウンロードします。

func azure storage fetch-connection-string mystorage12345

このコマンドは、mystorage12345_STORAGE という名前の設定を local.settings.json ファイルに追加します。この設定には、mystorage12345 アカウントの接続文字列が含まれています。詳細については、func azure storage fetch-connection-string コマンドを参照してください。

開発中のセキュリティを強化するために、local.settings.json ファイルの暗号化を検討してください。

Azure にローカル設定をアップロードする

--publish-local-settings オプションを使用せずにプロジェクトファイルを Azure に発行する場合、local.settings.json ファイルの設定は関数アプリでは設定されません。プロジェクトファイルを再発行せずに設定のみをアップロードする --publish-settings-only オプションを使用して、いつでも func azure functionapp publish を再実行できます。

次の例では、local.settings.json ファイルの Values コレクションから設定のみを myfunctionapp12345 という名前の Azure の関数アプリにアップロードします。

func azure functionapp publish myfunctionapp12345 --publish-settings-only

ローカル設定ファイルを暗号化する

ローカル設定の接続文字列やその他の重要なデータのセキュリティを強化するために、Core Tools では local.settings.json ファイルを暗号化できます。このファイルが暗号化されると、Azure のアプリケーション設定と同じように、必要に応じてランタイムが設定の暗号化を自動的に解除します。ローカルで暗号化されたファイルの暗号化を解除して、設定を操作することもできます。

次のコマンドを使用して、プロジェクトのローカル設定ファイルを暗号化します。

func settings encrypt

ローカル設定を操作できるように、次のコマンドを使用して、暗号化されたローカル設定の暗号化を解除します。

func settings decrypt

設定ファイルが暗号化され、暗号化解除されると、ファイルの IsEncrypted の設定も更新されます。

バインド拡張機能を構成する

Functions のトリガーとバインドは .NET 拡張機能 (NuGet) パッケージとして実装されています。特定のバインド拡張機能を使用できるようにするには、その拡張機能をプロジェクトにインストールする必要があります。

このセクションは、Functions ランタイムのバージョン 1.x にはあてはまりません。バージョン 1.x では、サポートされているバインドはコア製品拡張機能に含まれていました。

C# クラスライブラリプロジェクトに対しては、関数に必要なバインド拡張機能のための特定の NuGet パッケージへの参照を追加します。 C# スクリプト (.csx) プロジェクトでは、拡張機能バンドルを使用する必要があります。

Functions には、プロジェクト内のバインド拡張機能を操作しやすくするための拡張機能バンドルが用意されています。 host.json ファイルでバージョン管理され、定義される拡張機能バンドルは、アプリのための互換性のあるバインド拡張機能パッケージの完全なセットをインストールします。 host.json で拡張機能バンドルが既に有効になっている必要があります。何らかの理由で host.json ファイルの拡張機能バンドルを追加または更新する必要がある場合は、「拡張機能バンドル」を参照してください。

サポートされているバンドルにないバインド拡張機能または拡張機能のバージョンを使用する必要がある場合は、拡張機能を手動でインストールする必要があります。このようなまれなシナリオについては、func extensions install コマンドを参照してください。

Core Tools のバージョン

Azure Functions Core Tools のメジャーバージョンは、Azure Functions ランタイムの特定のメジャーバージョンとリンクしています。たとえば、Core Tools のバージョン 4.x では、Functions ランタイムのバージョン 4.x がサポートされています。これは、Functions ランタイムと Core Tools の両方で推奨されるメジャーバージョンです。最新の Core Tools リリースバージョンは、Azure Functions Core Tools リポジトリで確認できます。

Core Tools のバージョン 4.0.6517 以降、インプロセスモデルプロジェクトでは、バージョン 4.5.0 以降の Microsoft.NET.Sdk.Functions を参照する必要があります。以前のバージョンが使用されている場合、func start コマンドはエラーになります。

次のコマンドを実行して、現在の Core Tools インストールのバージョンを確認します。

func --version

特に記載がない限り、この記事の例ではバージョン 4.x を対象にしています。

Core Tools のインストールには、次の考慮事項が適用されます。

特定のコンピューターには、1 つのバージョンの Core Tools のみをインストールできます。
最新バージョンの Core Tools にアップグレードする場合は、元のインストールの使用したのと同じ方法を使用してアップグレードを実行する必要があります。たとえば、Windows で MSI を使用した場合は、現在の MSI をアンインストールし、最新のものをインストールします。または、npm を使用した場合は、npm install command を再実行します。
Core Tools のバージョン 2.x と 3.x は、サポート終了になった Functions ランタイムのバージョン 2.x と 3.x で使われていました。詳細については、「Azure Functions ランタイムバージョンをターゲットにする方法」をご覧ください。

Core Tools のバージョン 1.x は、まだサポートされているバージョン 1.x の Functions ランタイムを使用する場合に必要です。 Core Tools のこのバージョンは、Windows コンピューターでのローカル実行のみが行えます。現在バージョン 1.x で実行している場合は、今すぐにでもアプリをバージョン 4.x に移行することを検討する必要があります。

次のステップ

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

次の方法で共有

Core Tools を使用してローカルで Azure Functions を開発する

Azure Functions Core Tools のインストール

Ubuntu

Debian

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

関数を作成する

関数にバインドを追加する

Functions ランタイムを開始する

ローカル関数を実行する

Azure に発行する

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

コンテナーをデプロイする

ローカルでアプリの設定を操作する

アプリケーション設定をダウンロードする

ストレージ接続文字列のダウンロード

Azure にローカル設定をアップロードする

ローカル設定ファイルを暗号化する

バインド拡張機能を構成する

Core Tools のバージョン

次のステップ

フィードバック

その他のリソース

次の方法で共有

Core Tools を使用してローカルで Azure Functions を開発する

Azure Functions Core Tools のインストール

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

関数を作成する

関数にバインドを追加する

Functions ランタイムを開始する

ローカル関数を実行する

Azure に発行する

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

コンテナーをデプロイする

ローカルでアプリの設定を操作する

アプリケーション設定をダウンロードする

ストレージ接続文字列のダウンロード

Azure にローカル設定をアップロードする

ローカル設定ファイルを暗号化する

バインド拡張機能を構成する

Core Tools のバージョン

次のステップ

フィードバック

その他のリソース

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

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