次の方法で共有

Azure Functions のデプロイ テクノロジ

  • [アーティクル]

各種のテクノロジを使用して、Azure Functions プロジェクト コードを Azure にデプロイすることができます。 この記事では、使用可能なデプロイ方法の概要と、さまざまなシナリオで推奨される最適な方法について説明します。 また、基になるデプロイ テクノロジについての完全な一覧とその主要な詳細情報も提供します。

デプロイ方法

Azure の関数アプリにコードを発行するために使うデプロイ テクノロジは、特定のニーズと開発サイクルの時点によって異なります。 たとえば、開発およびテスト中であれば、Visual Studio Code などの開発ツールから直接配置します。 アプリが運用環境にある場合は、ソース管理から、または検証やテストを含む自動化された発行パイプラインを使って継続的に発行する可能性が高くなります。

次の表では、コード プロジェクトで使用できるデプロイ方法について説明します。

デプロイの種類 メソッド 最適なシナリオ
ツールベース • Visual Studio Code による発行
• Visual Studio による発行
• Core Tools による発行		 開発中のデプロイ、およびその他の即席のデプロイ。 ローカル開発ツールを使ったコードのオンデマンドのデプロイ。
App Service マネージド • デプロイ センター (CI/CD)
• コンテナーのデプロイ		 ソース管理またはコンテナー レジストリからの継続的配置 (CI/CD)。 デプロイは、App Service プラットフォーム (Kudu) によって管理されます。
外部パイプライン • Azure Pipelines
• GitHub Actions		 自動化されたデプロイの一部として実行する必要がある検証、テスト、その他のアクションを含む運用環境パイプライン。 デプロイはパイプラインによって管理されます。

特定のデプロイでは、特定のシナリオに基づいて最適なテクノロジを使う必要があります。 デプロイ方法の多くは、デプロイに推奨される zip デプロイに基づいています。

デプロイ テクノロジの利用可否

デプロイ方法は、関数アプリを実行するホスティング プランとオペレーティング システムによっても異なります。

現在、Functions には、関数アプリをホストするための 5 つのオプションが用意されています。

各プランの動作は異なります。 すべてのデプロイ テクノロジが各ホスティング プランやオペレーティング システムで使用できるわけではありません。 このグラフでは、サポートされているデプロイ テクノロジに関する情報を提供します。

デプロイ テクノロジ Flex 従量課金 従量課金プラン エラスティック Premium 専用 コンテナー アプリ
OneDeploy ✔
Zip デプロイ ✔ ✔ ✔
外部パッケージ URL1 ✔ ✔ ✔
Docker コンテナー Linux のみ Linux のみ Linux のみ ✔
ソース管理 Windows のみ ✔ ✔
ローカル Git1 Windows のみ ✔ ✔
FTPS1 Windows のみ ✔ ✔
ポータル内編集2 ✔ ✔ ✔

1トリガーを手動で同期する必要があるデプロイ テクノロジは推奨されません。
2 コードがポータルの外部から関数アプリにデプロイされる場合、ポータル内編集は無効になります。 ポータル内編集の言語サポートの詳細など、詳細については、「言語サポートの詳細」を参照してください。

主要な概念

Azure Functions でのデプロイの動作を理解するために重要な概念がいくつかあります。

トリガーの同期

トリガーのいずれかを変更する場合、Functions インフラストラクチャにその変更を認識させる必要があります。 同期は、多くのデプロイ テクノロジでは自動的に実行されます。 ただし、場合によっては、トリガーを手動で同期する必要があります。

以下のデプロイ オプションを使用する場合は、トリガーを手動で同期する必要があります。

次の方法のいずれかでトリガーを同期できます。

  • Azure portal で関数アプリを再起動する。

  • 次の例のように、az rest コマンドを使用して、syncfunctiontriggers API を呼び出す HTTP POST 要求を送信します。

    az rest --method post --url https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Web/sites/<APP_NAME>/syncfunctiontriggers?api-version=2016-08-01

展開パッケージの更新済みバージョンをデプロイし、同じ外部パッケージ URL を維持する場合は、関数アプリを手動で再起動する必要があります。 これで、ホストに対し、同じパッケージ URL から更新プログラムを同期して再デプロイする必要があることを示します。 Functions ホストでは、アプリケーションの起動後にバックグラウンドでの同期のトリガーも実行されます。 ただし、従量課金および Elastic Premium ホスティング プランの場合、次のシナリオではトリガーを手動で同期することも必要です。

  • ARM テンプレートまたは Terraform による外部パッケージ URL を使用したデプロイ。
  • 同じ外部パッケージ URL で展開パッケージを更新する場合。

リモート ビルド

デプロイ中にコード プロジェクトのリモート ビルドを実行するように Azure Functions に要求できます。 次のシナリオでは、ローカルでビルドするのではなく、リモート ビルドを要求する必要があります。

  • Windows コンピューター上で開発された Linux ベースの関数アプリにアプリをデプロイしている。 これは一般的に Python アプリ開発の場合です。 Windows 上でローカルに展開パッケージをビルドすると、不適切なライブラリが使用されてしまう可能性があります。
  • プロジェクトに、カスタム パッケージ インデックスへの依存関係がある。
  • 展開パッケージのサイズを小さくする必要がある。

リモート ビルドを要求する方法は、アプリが Windows 上または Linux 上のどちらの Azure 内で実行されているかによって異なります。

Windows 上で実行されるすべての関数アプリには、小規模な管理アプリがあり、これは Kudu によって提供される scm サイトです。 このサイトで、Azure Functions のデプロイとビルドのロジックの多くが処理されます。

アプリが Windows にデプロイされると、dotnet restore (C#) や npm install (JavaScript) などの言語固有のコマンドが実行されます。

次の考慮事項は、デプロイ時にリモート ビルドを使用する場合に適用されます。

  • 従量課金プランの Linux 上で実行されている関数アプリでは、リモート ビルドがサポートされます。 ただし、これらのアプリには scm (Kudu) サイトがないため、デプロイ オプションは制限されます。
  • Premium プランまたは Dedicated (App Service) プランにおいて Linux 上で実行されている関数アプリには scm (Kudu) サイトがありますが、Windows と比較すると制限があります。
  • アプリが run-from-package を使用している場合は、リモート ビルドは実行されません。 このような場合にリモート ビルドを使用する方法については、「Zip デプロイ」を参照してください。
  • アプリがこの機能が利用可能になった日 (2019 年 8 月 1 日) より前に作成されている場合、リモート ビルドで問題が発生する可能性があります。 古いアプリの場合は、新しい関数アプリを作成するか、az functionapp update --resource-group <RESOURCE_GROUP_NAME> --name <APP_NAME> を実行して関数アプリを更新します。 このコマンドを正常に実行するには、2 回試行することが必要な場合があります。

アプリ コンテンツ ストレージ

パッケージ ベースのデプロイ方法では、AzureWebJobsStorage 設定内に定義されている関数アプリに関連付けられたストレージ アカウント内にパッケージが格納されます。 使用可能な場合、従量課金および Elastic Premium プランのアプリでは、このアカウントから Azure Files コンテンツ共有を使用しようとしますが、別の場所にパッケージを保持することもできます。 Flex 従量課金プラン アプリでは、デプロイに使用する別のストレージ アカウントを構成する場合を除き、代わりに既定のストレージ アカウント内のストレージ コンテナーを使用します。 詳細については、次のセクションの中で説明する各デプロイ テクノロジの「アプリ コンテンツが格納される場所」の詳細を確認してください。

重要

ストレージ アカウントは、アプリケーション コード自体を含む重要なアプリ データを格納するために使用されます。 他のアプリやユーザーからのアクセスをストレージ アカウントに制限する必要があります。

デプロイ テクノロジの詳細

Azure Functions では、次のデプロイ方法が使用できます。

OneDeploy

Flex 従量課金プラン上のアプリでサポートされているデプロイ テクノロジは OneDeploy のみです。 最終的な結果は、関数アプリがその上で実行される、すぐに実行できる .zip パッケージです。

使用方法: Visual Studio Code の発行機能を使用するか、Azure Functions Core Tools または Azure CLI を使用してコマンド ラインからデプロイします。 Azure Dev Ops タスクおよび GitHub Action も同様に、Flex 従量課金アプリがデプロイされていることを検出すると OneDeploy を活用します。

Flex 従量課金アプリを作成する際は、デプロイ ストレージ (BLOB) コンテナーと、それに対する認証方法を指定する必要があります。 既定では、AzureWebJobsStorage 接続と同じストレージ アカウントが使用され、認証方法として接続文字列が使用されます。 したがって、デプロイ設定は、アプリケーション設定を必要とせず、アプリの作成時に構成されます。

使用するタイミング: Flex 従量課金プラン上で実行されている関数アプリで使用可能なデプロイ テクノロジは、OneDeploy のみです。

アプリ コンテンツが格納される場所: Flex 従量課金関数アプリを作成する際に、デプロイ ストレージ コンテナーを指定します。 これは、デプロイしたアプリ コンテンツをプラットフォームがアップロードする BLOB コンテナーです。 この場所を変更するには、Azure portal 内の [デプロイ設定] ブレードにアクセスするか、Azure CLI を使用します。

Zip デプロイ

Zip デプロイは、従量課金、Elastic Premium、App Service (Dedicated) プラン上の関数アプリで、既定かつおすすめのデプロイ テクノロジです。 最終的に、関数アプリがその上で実行される、すぐに実行できる .zip パッケージが作成されます。 これは、プラットフォームがアプリ コンテンツのリモートビルドと格納を担う外部パッケージ URL とは異なります。

使用方法: 任意のクライアント ツールを使用してデプロイします。Visual Studio Code、Visual Studio、Azure Functions Core Tools または Azure CLI を使用したコマンド ラインなど。 Azure Dev Ops タスクおよび GitHub Action も同様に zip デプロイを活用します。

zip デプロイを使用してデプロイする場合は、パッケージから実行 するようにアプリを設定できます。 パッケージから実行するには、WEBSITE_RUN_FROM_PACKAGE アプリケーション設定の値を 1 に設定します。 ZIP デプロイをお勧めします。 これによりアプリケーションの読み込み時間が短縮されます。これは VS Code、Visual Studio、および Azure CLI の既定値になります。

使用するタイミング: Zip デプロイは、Windows 従量課金、Windows と Linux の Elastic Premium、Windows と Linux の App Service (Dedicated) プラン上の関数アプリで、既定かつおすすめのデプロイ テクノロジです。

アプリ コンテンツが格納される場所: 既定では、zip デプロイからのアプリ コンテンツはファイル システムに格納されます。このファイル システムは、関数アプリの作成時に指定されたストレージ アカウントから Azure Files によってバックアップされる場合があります。 Linux 従量課金プランにおいて、アプリ コンテンツは代わりに AzureWebJobsStorage アプリ設定で指定されたストレージ アカウント内の BLOB 上に保持され、WEBSITE_RUN_FROM_PACKAGE アプリ設定は BLOB URL の値を受け取ります。

外部パッケージ URL

外部パッケージ URL は、デプロイの実行方法を手動で制御する場合のオプションです。 ビルドされたアプリ コンテンツを含む、すぐに実行できる .zip パッケージを Blob Storage にアップロードし、この外部 URL を関数アプリ上のアプリケーション設定として参照するのは、ユーザーの責任になります。 アプリは、再起動するたびにそのパッケージをフェッチしてマウントし、パッケージから実行モードで実行します。

使用方法: アプリケーション設定に WEBSITE_RUN_FROM_PACKAGE を追加します。 この設定の値は、アプリが実行する特定のパッケージの場所を指す、BLOB URL である必要があります。 ポータルで、または Azure CLI を使用して設定を追加できます。

Azure Blob Storage を使用する場合、関数アプリはマネージド ID ベースの接続を使用するか、Shared Access Signature (SAS) を使用してコンテナーにアクセスできます。 選択するオプションによって、WEBSITE_RUN_FROM_PACKAGE の値として使用する URL の種類は影響されます。 全体的なセキュリティのためには、マネージド ID がおすすめです。SAS トークンでは有効期限が切れて、手動で管理する必要があるためです。

関数アプリが参照するパッケージ ファイルをデプロイするときは常に、初期デプロイを含め、トリガーを手動で同期する必要があります。 パッケージ ファイルの内容を変更して URL 自体は変更しない場合も、関数アプリを再起動してトリガーを同期する必要があります。 このデプロイ テクノロジに関する構成については、使用法ガイドを参照してください。

使用するタイミング: リモート ビルドを実行したくない場合、Linux 従量課金プラン上で実行されているアプリでサポートされているデプロイ方法は外部パッケージ URL のみです。 この方法は、Azure Files を使用せずにアプリを作成する場合にもおすすめのデプロイ テクノロジです。 Linux 上で実行されているスケーラブルなアプリの場合は、代わりに Flex 従量課金プラン ホスティングを検討する必要があります。

アプリ コンテンツが格納される場所: アプリコンテンツを BLOB ストレージにアップロードするのはユーザーの責任になります。 任意の BLOB ストレージ アカウントを使用できますが、Azure Blob Storage をおすすめします。

Docker コンテナー

Linux コンテナーで実行されている関数アプリをデプロイできます。

使用方法: Linux コンテナーに関数を作成し、そのコンテナーを Azure Functions または別のコンテナー ホストの Premium プランまたは Dedicated プランにデプロイします。 Azure Functions Core Tools を使用して、コンテナー化された関数アプリのビルドに使用するプロジェクトの カスタム Dockerfile を作成します。 コンテナーは、次のデプロイで使用できます。

使用するタイミング: Docker コンテナー オプションは、関数アプリが実行され、コンテナーがホストされる Linux 環境をより詳細に制御する必要がある場合に使用します。 このデプロイ メカニズムは、Linux 上で実行されている関数に対してのみ使用できます。

アプリ コンテンツが格納される場所: アプリのコンテンツは、イメージの一部として、指定されたコンテナー レジストリに格納されます。

ソース管理

関数アプリとソース コード リポジトリの間で継続的インテグレーションを実現することができます。 ソース管理が有効であると、接続されたソース リポジトリ内のコードに対する更新によって、リポジトリの最新コードのデプロイがトリガーされます。 詳細については、「Azure Functions の継続的デプロイ」を参照してください。

使用方法: ソース管理からの発行を設定する最も簡単な方法は、ポータルの Functions 領域のデプロイ センターを利用することです。 詳細については、「Azure Functions の継続的なデプロイ」を参照してください。

いつ使用するか: 関数アプリで共同作業を行うチームにとっては、ソース管理を使用することがベスト プラクティスです。 ソース管理は、より高度なデプロイ パイプラインを可能にする優れたデプロイ オプションです。 ソース管理は通常、ステージング スロットで有効にされますが、これは、リポジトリの更新の検証後に運用環境へとスワップできます。 詳細については、「Azure Functions のデプロイ スロット」を参照してください。

アプリ コンテンツが格納される場所: アプリ コンテンツはソース管理システムにありますが、ローカルに複製およびビルドされたアプリ コンテンツはアプリ ファイル システムに格納されます。これは、関数アプリの作成時に指定されたストレージ アカウントの Azure Files によってサポートされる場合があります。

ローカル Git

ローカル Git は、Git を使用して、ローカル コンピューターから Azure Functions にコードをプッシュするのに使用できます。

使用方法: 「Azure App Service へのローカル Git デプロイ」の指示に従ってください。

いつ使用するか: エラーの可能性を減らすために、トリガーを手動で同期するという追加の手順を必要とするデプロイ方法の使用は避けてください。 可能な場合は、zip デプロイを使います。

アプリ コンテンツが格納される場所: アプリのコンテンツはファイル システムに格納され、関数アプリの作成時に指定されたストレージ アカウントから Azure Files によってサポートされる場合があります。

FTP/S

FTP/S を使って Azure Functions にファイルを直接転送できますが、このデプロイ方法は推奨されません。 FTP を使う予定がない場合は、無効にしてください。 FTP を使用する場合は、FTPS を強制してください。 Azure portal での方法については、「FTPS を適用する」を参照してください。

使用方法:FTPS デプロイ設定の手順に従って、FTPS を使って関数アプリにデプロイするために使用できる URL と資格情報を取得します。

いつ使用するか: エラーの可能性を減らすために、トリガーを手動で同期するという追加の手順を必要とするデプロイ方法の使用は避けてください。 可能な場合は、zip デプロイを使います。

アプリ コンテンツが格納される場所: アプリのコンテンツはファイル システムに格納され、関数アプリの作成時に指定されたストレージ アカウントから Azure Files によってサポートされる場合があります。

ポータルでの編集

ポータルベースのエディターでは、関数アプリ内のファイルを直接編集できます (基本的には、変更内容を保存するたびにデプロイされます)。

使用方法:Azure portal で関数を編集できるようにするために、ポータルで関数を作成しておく必要があります。 単一の信頼できるソースを保持するため、他のデプロイ方法を使用して、関数を読み取り専用にし、ポータルで編集できないようにします。 Azure portal でファイルを編集できる状態に戻すには、編集モードを Read/Write に手動で戻し、デプロイ関連のアプリケーション設定 (WEBSITE_RUN_FROM_PACKAGE など) をすべて削除します。

いつ使用するか: Azure Functions の使用を開始するには、ポータルが適しています。 より高度な開発作業を行うには、次のクライアント ツールのいずれかを使用することをお勧めします。

アプリ コンテンツが格納される場所: アプリのコンテンツはファイル システムに格納され、関数アプリの作成時に指定されたストレージ アカウントから Azure Files によってサポートされる場合があります。

次の表に、ポータル内編集をサポートしているオペレーティング システムと言語を示します。

Language Windows Consumption Windows Premium Windows Dedicated Linux Consumption Linux Premium Linux Dedicated
C#1
Java
JavaScript (Node.js)JavaScript (Node.js) ✔ ✔ ✔ ✔ ✔
Python2 ✔ ✔ ✔
PowerShell ✔ ✔ ✔
TypeScript (Node.js)

1 ポータル内編集がサポートされているのは C# スクリプト ファイルだけであり、これらはホストでのインプロセスで実行されます。 詳細については、Azure Functions C# スクリプト (.csx) 開発者向けリファレンスを参照してください。
2 ポータル内編集は、v1 Python プログラミング モデルでのみサポートされます。

デプロイ動作

関数アプリ コードに更新プログラムをデプロイすると、現在実行中の関数は終了します。 デプロイが完了すると、新しいコードが読み込まれ、要求の処理が開始されます。 ステートレスな関数と防御的な関数を記述する方法については、「Azure Functions のパフォーマンスと信頼性の向上」を参照してください。

この移行をさらに制御する必要がある場合、デプロイ スロットを使用してください。

デプロイ スロット

関数アプリを Azure にデプロイする場合、運用環境に直接デプロイする代わりに、個別のデプロイ スロットにデプロイできます。 デプロイ スロットにデプロイしてから、検証後に運用環境にスワップすることが、継続的デプロイを構成するための推奨方法です。

スロットにデプロイする方法は、使用する具体的なデプロイ ツールによって異なります。 たとえば、Azure Functions Core Tools を使用する場合は、func azure functionapp publish コマンドに対して特定のスロットの名前を指定するために --slot オプションを含めます。

デプロイ スロットの詳細については、Azure Functions のデプロイ スロットのドキュメントをご覧ください。

次のステップ

関数アプリのデプロイの詳細については、次の記事を参照してください。