次の方法で共有

Azure Functions での Linux コンテナーのサポート

Azure Functions で実行する個々の関数を計画して開発する場合、通常、コード自体に重点を置きます。 Azure Functions を使用すると、Azure の関数アプリにコード プロジェクトをデプロイするだけで済み、作業が容易になります。 プロジェクトを Linux 関数アプリにデプロイすると、コードは自動的に作成されたコンテナーで実行され、Functions 管理ツールとシームレスに統合されます。

Functions では、コンテナー化された関数アプリのデプロイもサポートされています。 コンテナー化されたデプロイでは、サポートされているベース イメージからローカルの Docker コンテナーに独自の関数アプリ インスタンスを作成します。 その後、この "コンテナー化された" 関数アプリを Azure 内のホスティング環境にデプロイできます。 独自の関数アプリ コンテナーを作成すると、関数コードの即時ランタイム環境のカスタマイズまたは制御を行うことができます。

重要

独自のコンテナーを作成する場合は、コンテナーの基本イメージを、サポートされている最新の基本イメージに更新しておく必要があります。 Azure Functions でサポートされている基本イメージは言語固有であり、Azure Functions 基本イメージ リポジトリにあります。

Functions チームは、これらの基本イメージの更新プログラムを毎月公開できるよう取り組んでいます。 通常の更新プログラムには、Functions ランタイムと言語の両方について、最新のマイナー バージョンの更新プログラムとセキュリティ修正プログラムが含まれます。 最新の基本イメージからコンテナーを定期的に更新し、コンテナーの更新されたバージョンを再デプロイする必要があります。 詳しくは、「カスタム コンテナーのメンテナンス」をご覧ください。

コンテナー ホスティング オプション

コンテナー化された関数アプリを Azure でホストするには、いくつかのオプションがあります。

ホスティング オプション 利点
Azure Container Apps Azure Functions では、Azure Container Apps でコンテナー化された関数アプリを開発、デプロイ、管理するための統合サポートが提供されます。 この統合により、Azure portal で同じ Functions ツールとページを使ってアプリを管理できます。 Azure Container Apps を使用して、他のマイクロサービス、API、Web サイト、ワークフロー、またはその他のコンテナーでホストされているプログラムと同じ環境で関数アプリ コンテナーをホストします。 Container Apps によるホスティングを使用すると、オープンソースの監視、mTLS、Dapr、KEDA の組み込みサポートを使って、マネージド Kubernetes ベースの環境内で関数を実行できます。 ゼロへのスケーリングをサポートすると、サーバーレスの従量課金制ホスティング モデルが提供されます。 ワークロード プロファイルを使うと、専用のハードウェアを (GPU でさえ) 要求できます。 コンテナー化された関数アプリ n Azure の推奨ホスティング オプション。
Azure Arc 対応 Kubernetes クラスター (プレビュー) Azure Arc 対応 Kubernetes クラスターで、関数アプリをコードのみのデプロイまたはカスタム Linux コンテナー内のいずれかとしてホストできます。 Azure Arc を使用すると、Kubernetes クラスターをアタッチできるため、Azure で管理および構成できます。 Azure Arc 対応 Kubernetes クラスターでの Azure Functions コンテナーのホスティングは、現在プレビュー段階です。 詳細については、「コンテナーと Azure Functions を使用する」を参照してください。
Azure Functions コンテナー化された関数アプリを Azure Functions でホストするには、 Elastic Premium または App Service (専用) プランでコンテナーを実行します。 Container Apps の豊富なコンテナー サポートには、Container Apps ホスティングを使用します。 Premium プランでのホスティングには、動的スケーリングの利点があります。 既存の App Service プランの使われていないリソースを活用するには、専用プランのホスティングを使うことをお勧めします。
Kubernetes Azure Functions ランタイムは、必要な場所や方法で柔軟にホストできるため、関数アプリ コンテナーを Kubernetes クラスターで直接ホストして管理できます。 KEDA (Kubernetes ベースのイベント駆動型自動スケーリング) は、Azure Functions ランタイムとツールにシームレスに組み合わされ、Kubernetes でのイベント駆動型スケーリングを提供します。 大事な： コンテナー化された関数アプリの Kubernetes ホスティングは、KEDA を使用するか、直接デプロイすることで、無料で使用できるオープンソースの作業です。 このホスティング シナリオのベスト エフォート サポートは、共同作成者とコミュニティによってのみ提供されます。 Azure Kubernetes Service (AKS) にデプロイする場合でも、クラスター内で独自の関数アプリ コンテナーを維持する責任があります。

機能サポートの比較

コンテナー内で関数アプリを実行する際に Azure Functions のさまざまな機能と動作がどの程度サポートされるかは、選択したコンテナー ホスティング オプションによって異なります。

機能/動作 Container Apps (統合) Container Apps (直接) Premium プラン 専用プラン Kubernetes（クバネティス）
製品のサポート はい いいえ はい はい いいえ
Functions ポータルの統合 はい いいえ はい はい いいえ
イベント駆動型スケーリング はい5 はい (スケール ルール) はい いいえ いいえ
最大スケール (インスタンス) 10001  10001  1002  10 から 303  クラスターによって異なります
ゼロ インスタンスへのスケーリング はい はい いいえ いいえ KEDA
実行時間の制限 無制限6 無制限6 無制限7 無制限8 なし
Core Tools のデプロイ func azurecontainerapps いいえ いいえ いいえ func kubernetes 
リビジョン いいえ はい いいえ いいえ いいえ
デプロイ スロット  いいえ いいえ はい はい いいえ
ストリーミング ログ  はい はい  はい はい いいえ
コンソール アクセス  現在使用できません4  はい はい (Kudu を使用) はい (Kudu を使用) はい (ポッド内で kubectl を使用)
コールド スタートの軽減策 最小レプリカ数 スケール ルール  常時使用可能な、または事前ウォーミングされたインスタンス  n/a n/a
App Service 認証  現在使用できません4  はい はい はい いいえ
カスタム ドメイン名  現在使用できません4  はい はい はい いいえ
秘密キー証明書  現在使用できません4  はい はい はい いいえ
仮想ネットワーク はい はい はい はい はい
可用性ゾーン はい はい はい はい はい
診断 現在使用できません4  はい はい  はい  いいえ
専用ハードウェア はい (ワークロード プロファイル) はい (ワークロード プロファイル) いいえ はい はい
専用 GPU はい (ワークロード プロファイル) はい (ワークロード プロファイル) いいえ いいえ はい
構成可能なメモリ/CPU の数 はい はい いいえ いいえ はい
"無料提供" オプション はい はい いいえ いいえ いいえ
価格の詳細 Container Apps の課金 Container Apps の課金 Premium プランの課金 専用プランの課金 AKS の価格
サービス名の要件 2 から 32 文字: 小文字、数字、ハイフンのみ使用できます。 先頭は文字、末尾は英数字にする必要があります。 2 から 32 文字: 小文字、数字、ハイフンのみ使用できます。 先頭は文字、末尾は英数字にする必要があります。 64 文字未満: 英数字とハイフンのみ使用できます。 先頭も末尾もハイフンにすることはできません。 64 文字未満: 英数字とハイフンのみ使用できます。 先頭も末尾もハイフンにすることはできません。 253 文字未満: 英数字とハイフンのみ使用できます。 先頭と末尾は英数字とする必要があります。
  1. Container Apps での既定値は 10 インスタンスですが、レプリカの最大数を設定でき、合計で最大 1,000 個です。 利用できるコア クォータが十分にある限り、この設定が使用されます。 Azure portal から関数アプリを作成する際は、300 インスタンスに制限されます。
  2. 一部のリージョンでは、Premium プランの Linux アプリを 100 インスタンスにスケーリングできます。 詳しくは、Premium プランに関する記事をご覧ください。
  3. さまざまな App Service プラン オプションに固有の制限については、App Service プランの制限に関する記事をご覧ください。
  4. 機能パリティは、Azure Container Apps での統合されたホスティングの目標です。
  5. KEDA (ほとんどのトリガーでサポートされる) を必要とします。 イベント ドリブン スケーリングをサポートするトリガーについては、「Container Apps ホスティングに関する考慮事項」を参照してください。
  6. 最小レプリカ数が 0 に設定されている場合、既定のタイムアウトはアプリで使われている特定のトリガーによって異なります。
  7. 実行タイムアウトの最長期間は適用されません。 ただし、関数の実行に与えられる猶予期間は、スケールイン中は 60 分、プラットフォーム更新中は 10 分です。
  8. App Service プランが Always On に設定されている必要があります。 プラットフォームの更新中は 10 分の猶予期間が与えられます。

カスタム コンテナーのメンテナンス

独自のコンテナーを作成する場合は、コンテナーの基本イメージを、サポートされている最新の基本イメージに更新しておく必要があります。 Azure Functions でサポートされている基本イメージは言語固有であり、Azure Functions 基本イメージ リポジトリにあります。

Functions チームは、これらの基本イメージの更新プログラムを毎月公開できるよう取り組んでいます。 通常の更新プログラムには、Functions ランタイムと言語の両方について、最新のマイナー バージョンの更新プログラムとセキュリティ修正プログラムが含まれます。 最新の基本イメージからコンテナーを定期的に更新し、コンテナーの更新されたバージョンを再デプロイする必要があります。

Linux 上の標準デプロイなど、基本イメージが Functions によって管理されている場合、アプリは、Functions チームによってリリースされる通常の基本イメージ更新プログラムによって、自動的に最新の状態に保たれます。 このようなカスタマイズされていないコンテナーの場合、アプリは、ホスト ランタイムの新しいマイナー バージョンまたはパッチ適用バージョンを使用する基本イメージで実行するように更新されます。

カスタム イメージを使って独自のコンテナー化されたアプリを作成またはデプロイする場合、リリースされた基本イメージでカスタム イメージを最新の状態に保つのはお客様の責任になります。 これらの基本イメージの更新プログラムには、新機能と機能強化に加えて、ユーザーのアプリにとって重要なセキュリティ更新プログラムが含まれることもあります。 アプリを確実に保護するには、最新の状態が維持されるようにします。

場合によっては、プラットフォーム レベルの変更を行う必要があり、古い基本イメージを使っているカスタム コンテナー内のアプリが正常に動作しなくなる可能性があります。 このような大きな変更の場合は、定期的に更新されるアプリに悪影響がないよう、更新されたイメージのロールアウトは十分な余裕を持って事前に行われます。 カスタム コンテナーで実行されているアプリに関する潜在的な問題を回避するため、リリースされた最新のマイナー バージョンへの更新があまり遅くならないようにしてください。 サポート ケースの間に、アプリが古いバージョンまたはサポートされていないバージョンで動作しているために問題が発生しているかどうかを判断する必要があるため、サポートを続ける前に、コンテナーを最新の基本イメージ バージョンに更新するようお客様にお願いします。

作業の開始

Linux コンテナーで Azure Functions を使い始めるには、次のリンクをご覧ください。

行いたいこと 参照する記事:
最初のコンテナー化された関数を作成する ローカル Linux コンテナーに関数アプリを作成する
関数を作成して Azure Container Apps にデプロイする Azure Container Apps で最初のコンテナ化された関数を作成する
コンテナー化された関数を作成して Azure Functions にデプロイする コンテナー化された最初の Azure Functions を作成する