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

複数の異なるテクノロジを使用して、Azure Functions プロジェクト コードをAzureにデプロイできます。 この記事では、使用可能なデプロイ方法の概要と、さまざまなシナリオで推奨される最適な方法について説明します。 また、基になるデプロイ テクノロジに関する包括的な一覧と重要な詳細も提供します。

デプロイ方法

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

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

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

特定のシナリオに最適なテクノロジを使用します。 サポートされるホスティングプランでは、多くの展開方式がzipデプロイメントを使用しています。

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

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

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

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

デプロイ テクノロジ Flex 従量課金 従量課金 エラスティック Premium Dedicated Container Apps
フレックス消費パッケージの展開 サポート対象 サポートしていません サポートしていません サポートしていません サポートしていません
ZIP デプロイ サポートしていません サポート対象 サポート対象 サポート対象 サポートしていません
外部パッケージURL1 サポートしていません サポート対象 サポート対象 サポート済み サポートしていません
コンテナイメージ(Docker) サポートしていません Linux のみ Linux のみ Linux のみ サポート対象
ソース管理 サポートしていません Windowsのみ サポート対象 サポート対象 サポートしていません
ローカルGit1 サポートしていません Windowsのみ サポート対象 サポート対象 サポートしていません
FTPS1 サポートしていません Windowsのみ サポート対象 サポート対象 サポートしていません
ポータル内編集2 サポートしていません サポート対象 サポート対象 サポート対象 サポートしていません
  1. 手動でトリガーを同期させる必要があるデプロイ技術は推奨されません。
  2. ポータル内編集は、ポータル外から関数アプリにコードをデプロイした場合に無効化されます。 ポータル内編集の言語サポートの詳細など、詳細については、「言語サポートの詳細」を参照してください。

この記事の冒頭でホスティングプランを選択すると、あなたの機能アプリに適用される展開技術や挙動を確認できます。

主要な概念

Azure Functionsでのデプロイのしくみを理解するには、いくつかの重要な概念が重要です。

ホスティングプランによるアプリコンテンツ保存

展開されたアプリのコンテンツの場所は、ホスティングプランや展開技術によって異なります。

ホスティング プラン アプリ コンテンツ ストレージ
Flex 従量課金 関数アプリ用に構成する BLOB デプロイ コンテナーです。
従量課金、Elastic Premium、専用 デプロイ技術に応じて、アプリファイルシステム、Azure Filesのコンテンツ共有、または外部パッケージURLのいずれかです。
Azure Container Apps コンテナレジストリに保存されたコンテナイメージ。

トリガーの同期

デプロイメントが関数やトリガー設定を追加、削除、変更する際、Functionsインフラストラクチャは関数アプリのトリガーメタデータを更新しなければなりません。 この同期は多くの展開技術で自動的に行われます。 ただし、場合によっては、トリガーを手動で同期する必要があります。

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

トリガーは、次のいずれかの方法で手動で同期できます。

  • Azure ポータルで関数アプリを再起動します。 Functions ホストは、アプリケーションの起動後にバックグラウンド トリガー同期を実行します。

  • 次の例のように、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 を使用して、更新されたバージョンのデプロイ パッケージをデプロイするたびに、関数アプリを手動で再起動する必要があります。
  • 従量課金プランまたは Elastic Premium プランで実行されているアプリの場合は、次のシナリオでも トリガーを手動で同期する 必要があります。
    • ARM テンプレート、Bicep、または Terraform ファイルを使用したリソースマネージャーに基づくデプロイメントで外部パッケージのURLを使用する場合。
    • 同じ外部パッケージ URL を使用して、インプレースで配置パッケージを更新する場合。
  • 既存の関数アプリにネットワーク制限を追加する場合は、 AzureWebJobsStorage アプリ設定で設定された既定のホスト ストレージ アカウントへの接続を保証する必要があります。 詳細については、「Azure Functionsを参照してください。

リモート ビルド

配置中にコード プロジェクトのリモート ビルドを実行するようにAzure Functionsを要求できます。 これらのシナリオでは、ローカルでビルドするのではなく、リモート ビルドを要求します。

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

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

Windows上で動作するすべての機能アプリには、コンパニオンのデプロイサイトがあります。 このサイトでは、Azure Functionsのデプロイとビルド ロジックの多くを処理します。

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

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

  • 従量課金プランの Linux 上で実行されている関数アプリでは、リモート ビルドがサポートされます。 しかし、これらのアプリには伴随する展開サイトがないため、展開オプションが限られています。
  • Elastic PremiumプランやDedicated (App Service)プランでLinux上で動作する機能アプリには、伴随するデプロイサイトがありますが、Windowsと比べると制限があります。
  • リモートビルドをリクエストするときに WEBSITE_RUN_FROM_PACKAGE 設定しないでください。 Linuxの消費、Elastic Premium、専用プランアプリでは、 Linux タブに記載されているデプロイメント設定を使ってリモートビルドを有効にしてください。デプロイプロセスではビルド出力をパッケージ化し、そのパッケージからアプリを実行するように設定できます。
  • 機能が利用可能になる前にアプリが作成されたときに、リモート ビルドに問題が発生する可能性があります (2019 年 8 月 1 日)。 古いアプリの場合は、新しい関数アプリを作成するか、az functionapp update --resource-group <RESOURCE_GROUP_NAME> --name <APP_NAME> を実行して関数アプリを更新します。 このコマンドを正常に実行するには、2 回試行することが必要な場合があります。

リモート ビルド

Flex Consumptionでは、デプロイ開始時にリモートビルドパラメータを渡してリモートビルドを要求します。 リモートビルドはアプリケーション設定で設定するものではありません。 Core ToolsやVisual Studio Codeでは、Pythonアプリをデプロイする際に必ずリモートビルドが求められます。 詳細については、「 デプロイ」を参照してください。

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

Flex Consumptionは、現在のパッケージを設定済みのデプロイメントストレージコンテナに保存します。 デフォルトではこのコンテナは AzureWebJobsStorageが使っている同じアカウントに入っていますが、 別のデプロイメントストレージアカウントを設定することもできます。

重要

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

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

展開技術によっては、アプリコンテンツはアプリファイルシステム、Azure Filesのコンテンツ共有、または外部パッケージURLに保存されます。 次のセクションでは、各展開技術ごとに アプリコンテンツがどこに保存されているか を確認してください。

重要

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

セキュリティで保護された仮想ネットワーク

関数アプリが プライベートエンドポイント を有効にしていて、パブリックネットワークアクセスが無効になっている場合、デプロイメントエンドポイントはパブリックにアクセスできません。 Core Tools、Visual Studio Code、Azure CLI、GitHub Actions、Azure Pipelinesなどのプッシュ展開ツールは、このエンドポイントにパッケージを送信します。 展開を実行するマシン、ランナー、またはエージェントは、プライベートデプロイメントエンドポイントに対してネットワーク接続とDNS解決の両方を持っている必要があります。

この接続性は以下の方法で提供できます:

展開リソースは同じ仮想ネットワーク内にある場合もあれば、プライベートエンドポイントとルーティングやDNS接続があるネットワーク(ピアード仮想ネットワークなど)に存在する場合があります。

Resource Managerベースのパッケージ展開は、開始クライアントからデプロイメントエンドポイントへパッケージをプッシュしません。 代わりに、デプロイサービスはデプロイメントリソースに提供されたURLからパッケージを取得します。 パッケージのURLとデプロイメントストレージはデプロイサービスにアクセス可能でなければなりません。 Flex Consumptionについては、「Bicep または Azure Resource Manager テンプレートを使ってデプロイする」をご覧ください。

仮想ネットワークで関数アプリを構成する方法の詳細については、「仮想ネットワークを使用してAzure Functionsを構成する方法を参照してください。

アプリのコンテンツ保存とネットワーキング

Azure Functions on Azure Container Apps は、あなたのアプリをコンテナイメージとしてデプロイします。 イメージはコンテナレジストリに保存され、ネットワークはコンテナアプリ環境によって管理されます。 詳細については、Azure Functions on Azure Container Apps の概要および Networking in Azure Container Apps をご覧ください。

ホスティング計画による展開動作

以下の展開方法は、選択したホスティングプランに適用されます。 すべてのプランにおける技術を比較するには、 導入技術の可用性 表をご覧ください。

フレックス消費パッケージの展開

パッケージ展開は 、Flex Consumptionプランのアプリで唯一サポートされているコード展開技術です。 デプロイメントプロセスは、アプリのデプロイコンテナ内に実行可能な .zip パッケージを格納し、関数アプリはそのパッケージから直接実行されます。

Visual Studio Code 発行機能を使用してデプロイするか、Azure Functions Core Tools または Azure CLI を使用してコマンド ラインからデプロイします。 Azure DevOpsタスクとGitHub Actionも同様に、Flex Consumptionアプリを検出した際に正しいパッケージ展開動作を選択します。

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

使うべきタイミング: すべてのFlex Consumptionコード展開にはパッケージデプロイメントを使いましょう。 他のコード展開技術はサポートされていません。

アプリ コンテンツが格納される場所: Flex 従量課金関数アプリを作成する際に、デプロイ ストレージ コンテナーを指定します。 展開サービスは処理された、実行準備済みのパッケージをこのコンテナに保存します。 プッシュデプロイメントツールはまずソースパッケージをアプリのデプロイメントエンドポイントに送信します。デプロイメントコンテナに直接アップロードするわけではありません。 ストレージの場所を変更するには、Azureポータルのデプロイメント設定ページを開くか、Azure CLIを使ってください。

基盤となるプラットフォームAPIは時に OneDeployとして識別されます。 インフラストラクチャ・アズ・コードの定義は、この実装を /onedeploy リソース名を通じて公開します。 サポートされた開発ツールやCI/CDプロバイダーを使って展開する際に、このAPIを選択したり設定したりする必要はありません。

ヒント

Flex Consumption Deployment 診断ツールは、Azure ポータルで使用できます。 Flex Consumption アプリを開き、[ 問題の診断と解決] を選択して、 Flex Consumption Deploymentを検索します。 このツールには、デプロイ履歴、パッケージの状態、トラブルシューティングの推奨事項など、デプロイに関する詳細情報が表示されます。

ZIP デプロイ

ZIP展開は、Consumption、Elastic Premium、Dedicated (App Service)プランの機能アプリのデフォルトかつ推奨される展開技術です。 最終的な結果は、関数アプリがその上で実行される、すぐに実行できる .zip パッケージです。 外部 パッケージの URL とは異なり、プラットフォームはアプリ コンテンツのリモートビルドと格納を担当します。

使い方:お好みのクライアントツール(Visual Studio Code、Visual Studio)、またはコマンドラインからAzure Functions Core ToolsやAzure CLIを使ってデプロイできます。 Azure DevOpsタスクとGitHub Actionも同様にZIPデプロイメントを使用しています。

ZIPデプロイメントを使うと、アプリを パッケージから実行するように設定できます。 パッケージから実行するには、WEBSITE_RUN_FROM_PACKAGE アプリケーション設定の値を 1 に設定します。 ZIPの導入を推奨します。 アプリケーションの読み込み時間が速くなり、Visual Studio Code、Visual Studio、Azure CLIのデフォルトにもなっています。

使用タイミング:ZIP展開は、Windows Consumption、Windows and Linux Elastic Premium、Windows and Linux App Service(専用)プランの機能アプリのデフォルトかつ推奨展開技術です。

アプリのコンテンツが保存される場所:ZIPデプロイメントのアプリコンテンツはデフォルトでファイルシステムに保存されており、Azureは関数アプリ作成時に指定したストレージアカウントからAzure Filesでバックアップすることがあります。 Linux Consumption では、アプリのコンテンツは代わりに、 AzureWebJobsStorage アプリ設定で指定されたストレージ アカウント内の BLOB に保持され、アプリ設定 WEBSITE_RUN_FROM_PACKAGE は BLOB URL の値を受け取ります。

外部パッケージ URL

デプロイの進行を手動でコントロールしたい場合は、外部パッケージURLを使いましょう。 あなたは、作成したアプリコンテンツを含むすぐに実行可能な .zip パッケージをブロブストレージにアップロードし、この外部URLを関数アプリのアプリケーション設定として参照する責任があります。 アプリが再起動するたびに、パッケージを取得してマウントし、その パッケージから実行します。

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

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

関数アプリが参照するパッケージ ファイルをデプロイするときは常に、初期デプロイを含め、トリガーを手動で同期する必要があります。 パッケージ ファイルの内容を変更して URL 自体は変更しない場合も、関数アプリを再起動してトリガーを同期する必要があります。 設定手順については、「 外部パッケージURLから実行」を参照してください。

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

アプリ コンテンツが格納される場所: アプリコンテンツを BLOB ストレージにアップロードするのはユーザーの責任になります。 どのBlob Storageアカウントでも使えますが、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 の Local Git デプロイの指示に従ってください。

使用するタイミング: エラーの可能性を減らすために、 トリガーを手動で同期する追加の手順を必要とするデプロイ方法を使用しないようにします。 可能な場合は、zip デプロイを使います。

アプリコンテンツの保存場所: ファイルシステムはアプリコンテンツを保存します。 ファイルシステムは、関数アプリを作成する際に指定したストレージアカウントのAzure Filesによってバックアップされているかもしれません。

FTPS

FTPSを使って直接Azure Functionsにファイルを転送することはできますが、このデプロイ方法は使わないでください。 FTPSを使う予定がない場合は無効にしてください。 Azure ポータルの方法については、Enforce FTPS を参照してください。

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

使用するタイミング: エラーの可能性を減らすために、 トリガーを手動で同期する追加の手順を必要とするデプロイ方法を使用しないようにします。 可能な場合は、zip デプロイを使います。

アプリのコンテンツが格納される場所: アプリのコンテンツはファイル システムに格納されます。 アプリのファイル システムが既定のホスト ストレージ アカウントのAzure Filesによってサポートされている場合、FTP/FTPS デプロイは失敗します。 FTP/FTPS は、FTP の制限が原因で、マウントされたストレージとしてAzure Filesで失敗します。

ポータルでの編集

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

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

それを使用する場合: ポータルは、Azure Functionsの使用を開始するのに適した方法です。 Azure ポータルでは開発の制限があるため、より高度な開発作業には次のいずれかのクライアント ツールを使用する必要があります。

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

コンテナイメージのデプロイ

Azure Functions on Azure Container Apps はあなたのコードをコンテナイメージとしてデプロイします。 管理されたコンテナアプリ体験を使ってコードプロジェクトからデプロイすることも、イメージの内容を管理したいときにカスタムイメージをデプロイすることもできます。 詳細については、「Code を使って Azure Container Apps で関数アプリを作成」および「Azure Functions on Azure Container Apps」の概要をご覧ください。

デプロイ動作

関数アプリのコードにアップデートをデプロイする際、その展開動作はホスティングプランによって異なります。

現在、実行中の関数は新しいコードをデプロイすると停止します。 デプロイが完了すると、新しいコードが読み込まれ、リクエストの処理が始まります。 この強制的な終わらせの行動は 再創造戦略と呼ばれます。 ほぼダウンタイムゼロの展開には展開 スロットを活用しましょう。

Azure Functions のパフォーマンスと信頼性を向上させる方法を調べ、ステートレスおよび防御的な機能を記述する方法を学びます。

デフォルトの動作は 再構築戦略を使い、デプロイ中に現在実行中の関数を停止します。 Flex Consumptionは2つのサイト更新戦略をサポートしています。 ダウンタイムなしのデプロイ用に ローリング更新プログラムを構成 できます。

Azure Container Appsは、リビジョンを使ってアプリケーションの更新を管理します。 新しいリビジョンのトラフィック受信方法の制御については、Azure Container Appsの「Update and deploy changes」をご覧ください。

デプロイ スロット

Flex Consumptionは展開スロットをサポートしていません。 ゼロダウンタイムのデプロイメントでは、 ローリングアップデートを設定しましょう。

デプロイ スロット

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

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

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

次のステップ

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

  • 最終更新: