Azure Functionsで個別の関数を計画・開発する際は、コード自体に注目してください。 Azure Functions を使用すると、Azure の関数アプリにコード プロジェクトをデプロイするだけで済み、作業が容易になります。 プロジェクトをLinux関数アプリにデプロイすると、コードはAzure Functionsが自動的に作成するコンテナ内で動作します。 このコンテナはFunctions管理ツールとシームレスに統合されます。
Functions では、コンテナー化された関数アプリのデプロイもサポートされています。 コンテナ化デプロイメントでは、サポートされたベースイメージからローカルのDockerコンテナ内に独自の関数アプリインスタンスを作成します。 その後、この コンテナー化された 関数アプリを Azure のホスティング環境にデプロイできます。 独自の関数アプリ コンテナーを作成すると、関数コードの即時ランタイム環境のカスタマイズまたは制御を行うことができます。
Important
独自のコンテナーを作成するときは、コンテナーの基本イメージを、サポートされている最新の基本イメージに更新しておく必要があります。 Azure Functions でサポートされている基本イメージは言語固有です。 Azure Functions の基本イメージ リポジトリを参照してください。
Functions チームは、これらの基本イメージの更新プログラムを毎月公開できるよう取り組んでいます。 通常の更新プログラムには、Functions ランタイムと言語の両方について、最新のマイナー バージョンの更新プログラムとセキュリティ修正プログラムが含まれます。 最新の基本イメージからコンテナーを定期的に更新し、コンテナーの更新されたバージョンを再デプロイする必要があります。 詳しくは、「カスタム コンテナーのメンテナンス」をご覧ください。
コンテナー ホスティング オプション
Tip
ほとんどのコンテナ化されたワークロードについては、関数アプリをAzure Container Appsでホストしてください。 Container Appsは、イベント駆動のスケーリング、ゼロへのスケール、GPUサポートを備えた、完全に管理されたサーバーレスのKubernetesベースの環境を提供します。 入門方法請見 Azure Functions on Azure Container Apps。
Azureでコンテナ化された関数型アプリをホスティングするオプションはいくつかあります:
| ホスティング オプション | Benefits |
|---|---|
| Azure Container Apps (Recommended) | Azure Container AppsMicrosoft.Appリソースプロバイダーを使って、関数アプリのコンテナをネイティブにホスト・管理しています。 フルマネージドでサーバーレスのKubernetesベースの環境で運用し、オープンソース監視、mTLS、DAPR、KEDAのサポートを組み込みましょう。 スケール・トゥ・ゼロ、サーバーレスの使用量分課金、専用ハードウェア、GPUをワークロードプロファイル経由でサポートします。 同じFunctionsプログラミングモデルとトリガーを使いながら、コンテナアプリの全機能セットを得られます。
Azureのコンテナ化関数アプリ向けの推奨ホスティングオプション。 |
| Azure Container Apps (legacy) | Azure FunctionsMicrosoft.Webリソースプロバイダーを用いてコンテナ化された機能アプリをコンテナアプリ環境にデプロイするための統合サポートを提供します。 現在はサポートされていますが、将来的には廃止が計画されています。 新しいワークロードの場合は、推奨されるコンテナアプリホスティングオプションをご利用ください。 |
| Azure Functions | コンテナー化された関数アプリを Azure Functions でホストするには、 Elastic Premium または App Service (専用) プランでコンテナーを実行します。 Premium プランでのホスティングには、動的スケーリングの利点があります。 既存の App Service プランの使われていないリソースを活用するには、専用プランのホスティングを使うことをお勧めします。 |
| Kubernetes | Azure Functions ランタイムは、必要な場所や方法で柔軟にホストできるため、関数アプリ コンテナーを Kubernetes クラスターで直接ホストして管理できます。 KEDA (Kubernetes ベースのイベント ドリブン自動スケーリング) は、Azure Functions ランタイムとツールとシームレスに組み合わせて、Kubernetes でイベント ドリブンスケールを提供します。 大事な： コンテナー化された関数アプリの Kubernetes ホスティングは、KEDA を使用するか、直接デプロイすることで、無料で使用できるオープンソースの作業です。 このホスティング シナリオのベスト エフォート サポートは、共同作成者とコミュニティによってのみ提供されます。 Azure Kubernetes Service (AKS) にデプロイする場合でも、クラスター内で独自の関数アプリ コンテナーを維持する責任があります。 |
機能サポートの比較
コンテナー内で関数アプリを実行する際に Azure Functions のさまざまな機能と動作がどの程度サポートされるかは、選択したコンテナー ホスティング オプションによって異なります。
| Feature/behavior | コンテナアプリ(推奨) | Container Apps (legacy)1 | プレミアムプラン | 専用プラン | Kubernetes |
|---|---|---|---|---|---|
| 製品サポート | Yes | Yes | Yes | Yes | No |
| 関数ポータル統合 | Yes | No | Yes | Yes | No |
| イベント ドリブンスケーリング | はい (スケール ルール) | Yes5 | Yes | No | No |
| 最大スケール (インスタンス) | 10002 | 10002 | 1003 | 10-304 | 星団によって異なります |
| 0 にスケーリングするインスタンス | Yes | Yes | No | No | ケダ |
| 執行期限 | Unbounded6 | Unbounded6 | Unbounded7 | Unbounded8 | None |
| Core Tools のデプロイ | No | No | No | No | func kubernetes |
| Revisions | Yes | Yes | No | No | No |
| デプロイ スロット | No | No | Yes | Yes | No |
| ストリーミング ログ | Yes | Yes | Yes | Yes | No |
| コンソール アクセス | Yes | Yes | はい( Kuduを使用) | はい( Kuduを使用) | はい (ポッド内で kubectl を使用) |
| コールド スタートの軽減策 | スケール ルール | 最小レプリカ数 | 常時準備済み/事前加熱済みインスタンス | n/a | n/a |
| App Service 認証 | Yes | Yes | Yes | Yes | No |
| カスタム ドメイン名 | Yes | Yes | Yes | Yes | No |
| 秘密キー証明書 | Yes | Yes | Yes | Yes | No |
| 仮想ネットワーク | Yes | Yes | Yes | Yes | Yes |
| 可用性ゾーン | Yes | Yes | Yes | Yes | Yes |
| Diagnostics | Yes | Yes | Yes | Yes | No |
| 専用のハードウェア | はい (ワークロード プロファイル) | はい (ワークロード プロファイル) | No | Yes | Yes |
| 専用 GPU | はい (ワークロード プロファイル) | はい (ワークロード プロファイル) | No | No | Yes |
| 構成可能なメモリ/CPU の数 | Yes | Yes | No | No | Yes |
| 「フリーグラント」オプション | Yes | Yes | No | No | No |
| 価格の詳細 | Container Apps の課金 | Container Apps の課金 | Premium プランの課金 | 専用プランの課金 | AKS の価格 |
| サービス名の要件 | 2 から 32 文字: 小文字、数字、ハイフンのみ使用できます。 先頭は文字、末尾は英数字にする必要があります。 | 2 から 32 文字: 小文字、数字、ハイフンのみ使用できます。 先頭は文字、末尾は英数字にする必要があります。 | 64 文字未満: 英数字とハイフンのみ使用できます。 先頭も末尾もハイフンにすることはできません。 | 64 文字未満: 英数字とハイフンのみ使用できます。 先頭も末尾もハイフンにすることはできません。 | 253 文字未満: 英数字とハイフンのみ使用できます。 先頭と末尾は英数字とする必要があります。 |
- 将来の廃止を想定しています。 代わりに、ネイティブのコンテナアプリのホスティングを使いましょう。
- Container Apps での既定値は 10 インスタンスですが、レプリカの最大数を設定でき、合計で最大 1,000 個です。 利用できるコア クォータが十分にある限り、この設定が使用されます。 Azure portal から関数アプリを作成する際は、300 インスタンスに制限されます。
- 一部のリージョンでは、Premium プランの Linux アプリを 100 インスタンスにスケーリングできます。 詳しくは、Premium プランに関する記事をご覧ください。
- さまざまな App Service プラン オプションに固有の制限については、App Service プランの制限に関する記事をご覧ください。
- KEDA が必要です。ほとんどのトリガーでサポートされています。 イベント ドリブン スケーリングをサポートするトリガーについては、「Container Apps ホスティングに関する考慮事項」を参照してください。
- 最小レプリカ数が 0 に設定されている場合、既定のタイムアウトはアプリで使われている特定のトリガーによって異なります。
- 実行タイムアウトの最長期間は適用されません。 ただし、関数の実行に与えられる猶予期間は、スケールイン中は 60 分、プラットフォーム更新中は 10 分です。
- App Service プランを Always On に設定する必要があります。 プラットフォームの更新中は 10 分の猶予期間が与えられます。
カスタム コンテナーのメンテナンス
自分でコンテナを作成する際は、コンテナのベースイメージを最新のサポートベースイメージに更新しておくと良いでしょう。 Azure Functions でサポートされている基本イメージは言語固有であり、Azure Functions 基本イメージ リポジトリにあります。
Functions チームは、これらの基本イメージの更新プログラムを毎月公開できるよう取り組んでいます。 通常の更新プログラムには、Functions ランタイムと言語の両方について、最新のマイナー バージョンの更新プログラムとセキュリティ修正プログラムが含まれます。 最新のベースイメージから定期的にコンテナを更新し、更新されたバージョンのコンテナを再デプロイしてください。
関数アプリで使用している言語スタックに基づいて、基本イメージを選択します。 次の表に、各スタックの例を示します。 一般的に、タグはV4関数の実行時間を示すために 4- で始まります。 新しいマイナーバージョンがリリースされると、このタグは新しいバージョンを指すように更新されます。 カスタムイメージを定期的に再構築する際に、新しいバージョンも同じタグを通して引き寄せ、アプリは同じアップデートを受けます。 マイナーランタイムバージョンを指定するタグは使わないでください。これらのタグは更新を受け取らないからです。 カスタムイメージを何度も再構築しても、アプリはパッチ未接続のまま残る可能性があります。
| 言語スタック | 推奨される基本イメージ タグの例 |
|---|---|
| .NET (分離ワーカー モデル) |
mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated8.0 またはmcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated8.0-appservice(これらの例は .NET 8 を対象とします。必要な .NET バージョンに適したイメージを選択します)。 |
| .NET (レガシ インプロセス モデル) |
mcr.microsoft.com/azure-functions/dotnet:4-dotnet8.0 またはmcr.microsoft.com/azure-functions/dotnet:4-dotnet8.0-appservice(進行中のモデルのサポートは2026年11月10日に終了します。できるだけ早く 分離されたワーカーモデルに移行してください 。) |
| Java |
mcr.microsoft.com/azure-functions/java:4-java21 またはmcr.microsoft.com/azure-functions/java:4-java21-appservice(これらの例は Java 21 を対象とします。必要な Java バージョンに適したイメージを選択します)。) |
| Node.js (JavaScript または TypeScript) |
mcr.microsoft.com/azure-functions/node:4-node22 またはmcr.microsoft.com/azure-functions/node:4-node22-appservice(これらの例では、Node.js 22 を対象とします。必要な Node.js バージョンに適したイメージを選択します)。 |
| PowerShell |
mcr.microsoft.com/azure-functions/powershell:4-powershell7.4 またはmcr.microsoft.com/azure-functions/powershell:4-powershell7.4-appservice(これらの例は PowerShell 7.4 を対象とします。必要な PowerShell バージョンに適したイメージを選択します)。 |
| Python |
mcr.microsoft.com/azure-functions/python:4-python3.12 またはmcr.microsoft.com/azure-functions/python:4-python3.12-appservice(これらの例は Python 3.12 を対象とします。必要な Python バージョンに適したイメージを選択します)。) |
| カスタム ハンドラー/その他 |
mcr.microsoft.com/azure-functions/base:4 またはmcr.microsoft.com/azure-functions/base:4-appservice |
-appserviceで終わる基本イメージは、プラットフォームからのSSHおよびリモートデバッグを可能にします。 これらの機能が必要な場合を除き、 -appservice の接尾辞を付けずにベース画像を使うのが良いでしょう。
Important
Dockerfileに前のタグのいずれかを入れるだけでは不十分です。 カスタム イメージを再構築して最新の更新プログラムを含めることができるように、そのタグから最新のイメージを定期的にプルする必要があります。 最新のイメージを取得して再構築しなければ、アプリは古いベースイメージ上で動作を続けます。
カスタムイメージを使って自分でコンテナ化アプリを作成またはデプロイする際、カスタムイメージがリリースされたベースイメージと常に更新されているか up-to責任があります。 これらの基本イメージの更新プログラムには、新機能と機能強化に加えて、ユーザーのアプリにとって重要なセキュリティ更新プログラムが含まれることもあります。 アプリが確実に保護されるようにするには、最新の状態を維持していることを確認します。 定期的にベースイメージの最新バージョンを取得し、カスタムコンテナイメージを再構築し、アプリを再デプロイしてそれを使ってください。
場合によっては、Microsoftがプラットフォームレベルの変更を行う必要があり、古いベースイメージを使用したカスタムコンテナ内のアプリが正常に動作しなくなる可能性があります。 このような大きな変更に対しては、Microsoftは定期的にアップデートされるアプリが悪影響を受けないように、かなり前もってアップデート画像を展開しています。 カスタム コンテナーで実行されているアプリに関する潜在的な問題を回避するため、リリースされた最新のマイナー バージョンへの更新があまり遅くならないようにしてください。 サポートケース中に、Microsoftがあなたのアプリが古いバージョンやサポートされていないバージョンで問題が発生していると判断した場合、Microsoftはサポートを続ける前にコンテナを最新の基本イメージバージョンに更新するよう要求します。
作業の開始
Linux コンテナーで Azure Functions を使い始めるには、次のリンクをご覧ください。
| 行いたいこと | 記事を参照してください。 |
|---|---|
| Deploy functions to Azure Container Apps (recommended) | Azure Container Apps で最初のコンテナ化された関数を作成する |
| ローカルで初めてコンテナ化関数を作成しました | ローカル Linux コンテナーに関数アプリを作成する |
| コンテナ化機能をプレミアムまたは専用プランに展開します | コンテナー化された最初の Azure Functions を作成する |