Azure Functions の Azure Container Apps ホスティング

  • [アーティクル]

Azure Functions では、Azure Container Apps でコンテナー化された関数アプリを開発、デプロイ、管理するための統合サポートが提供されます。 Azure 内の、他のマイクロサービス、API、Web サイト、ワークフロー、またはコンテナーでホストされているプログラムと同じ環境で、イベント ドリブン関数を実行する必要がある場合は、Azure Container Apps を使って関数アプリ コンテナーをホストします。 Container Apps によるホスティングを使用すると、オープンソースの監視、mTLS、Dapr、Kubernetes Event-driven Autoscaling (KEDA) の組み込みサポートを使って、フル マネージドの Kubernetes ベースの環境内で関数を実行できます。

Functions でサポートされている言語スタックで関数のコードを記述できます。 イベント ドリブンのスケーリングでは、同じ Functions のトリガーとバインドを使用できます。 また、既存の Functions クライアント ツールと Azure portal を使ってコンテナーを作成し、関数アプリ コンテナーを Container Apps にデプロイして、継続的デプロイを構成できます。

Container Apps の統合は、コンテナー アプリ環境レベルで定義されたネットワークと監視の構成が、Container Apps 環境内で実行されるすべてのマイクロサービスと同様に、ユーザーの関数アプリにも適用されることを意味します。 また、KEDA、Dapr、Envoy など、Container Apps の他のクラウドネイティブ機能も使用できます。 Application Insights を使って関数の実行を監視することもでき、関数アプリでは、環境によって提供される同じ仮想ネットワーク リソースにアクセスできます。

Azure Functions のコンテナー ホスティング オプションの一般的な概要については、Azure Functions での Linux コンテナーのサポートに関する記事をご覧ください。

ホスティングとワークロード プロファイル

Container Apps には、サーバーレスの従量課金プランと、ワークロード プロファイルを使ってデプロイ リソースをより適切に制御する専用プランの、2 つの主要なホスティング プランがあります。 ワークロード プロファイルにより、環境にデプロイされたコンテナー アプリで使用できるコンピューティング リソースとメモリ リソースの量が決定されます。 これらのプロファイルは、アプリケーションのさまざまなニーズに合わせて構成されます。

従量課金ワークロード プロファイルは、すべてのワークロード プロファイルの環境の種類に追加される既定のプロファイルです。 専用ワークロード プロファイルは、環境の作成時または作成後に環境に追加できます。 ワークロード プロファイルについて詳しくは、「Azure Container Apps のワークロード プロファイル」をご覧ください。

コンテナー化された関数アプリの Container Apps によるホスティングは、Container Apps をサポートするすべてのリージョンでサポートされます。

アプリに特定のハードウェア要件がない場合は、従量課金プランまたは既定の従量課金ワークロード プロファイルを使う専用プランのどちらでも、環境を実行できます。 Container Apps で関数を実行する場合、Container Apps の使用に対してのみ課金されます。 詳細については、Azure Container Apps の価格ページを参照してください。

Azure Container Apps 上の Azure Functions では、ワークロード プロファイルを使用する専用プランでの GPU が有効なホスティングがサポートされています。

既定の従量課金プランで関数アプリ コンテナーを作成して Container Apps にデプロイする方法については、「Azure Container Apps で最初のコンテナー化された関数を作成する」をご覧ください。

ワークロード プロファイルを使って Container Apps 環境を作成し、関数アプリ コンテナーを特定のワークロードにデプロイする方法については、Container Apps のワークロード プロファイルに関する記事をご覧ください。

コンテナー内の関数

Container Apps のホスティングを使うには、自分で作成して管理する Linux コンテナー内の関数アプリで、コードを実行する必要があります。 Functions では、コンテナー化された関数アプリの生成に使用できる言語固有の基本イメージのセットが保持されます。

Azure Functions Core Tools を使ってコード プロジェクトを作成し、--docker オプションを含めると、Core Tools によって正しい基本イメージを含む Dockerfile が生成されます。これを基にして、自分でコンテナーを作成できます。

重要

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

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

関数コードに変更を加える場合は、コンテナー イメージを再構築して再パブリッシュする必要があります。 詳細については、「レジストリ内のイメージを更新する」を参照してください。

デプロイ オプション

現在、Azure Functions では、コンテナー化された関数アプリを Azure Container Apps にデプロイする次の方法がサポートされています。

仮想ネットワークの統合

関数アプリを Container Apps 環境でホストすると、関数は内部と外部両方のアクセス可能な仮想ネットワークを利用できます。 環境のネットワークについて詳しくは、「Azure Container Apps 環境でのネットワーク」をご覧ください。

スケール ルールを構成する

Container Apps の Azure Functions は、イベント ターゲットに従ってスケール パラメーターとルールを構成するように設計されています。 KEDA スケーリング オブジェクトの構成について考慮する必要はありません。 関数アプリを作成または変更する場合に、引き続きレプリカの最小数と最大数を設定できます。 次の Azure CLI コマンドでは、Container Apps 環境で Azure Container Registry から新しい関数アプリを作成するときの最小レプリカ数と最大レプリカ数を設定します。

az functionapp create --name <APP_NAME> --resource-group <MY_RESOURCE_GROUP> --max-replicas 15 --min-replicas 1 --storage-account <STORAGE_NAME> --environment MyContainerappEnvironment --image <LOGIN_SERVER>/azurefunctionsimage:v1 --registry-username <USERNAME> --registry-password <SECURE_PASSWORD> --registry-server <LOGIN_SERVER>

次のコマンドでは、既存の関数アプリで同じ最小レプリカ数と最大レプリカ数を設定します。

az functionapp config container set --name <APP_NAME> --resource-group <MY_RESOURCE_GROUP> --max-replicas 15 --min-replicas 1

管理対象リソース グループ

Container Apps 上の Azure Functions は、コンテナー化された関数アプリ リソースを特別に管理されたリソース グループで実行します。 これらの管理対象リソース グループは、サービス プリンシパルによるものであっても、管理対象グループ内のリソースの意図しない、または未承認の変更や削除を防止するので、アプリの一貫性の保護に役立ちます。

管理対象リソース グループは、ユーザーが Container Apps 環境で関数アプリ リソースを初めて作成するときに、自動的に作成されます。 コンテナー化された関数アプリに必要な Container Apps リソースは、この管理対象リソース グループ内で実行されます。 同じ環境で作成した他のすべての関数アプリも、この既存のグループを使います。

すべての関数アプリ コンテナー リソースが環境から削除されると、管理対象リソース グループは自動的に削除されます。 管理対象リソース グループを表示できる間は、管理対象リソース グループを変更または削除しようとするとエラーが発生します。 環境から管理対象リソース グループを削除するには、すべての関数アプリ コンテナー リソースを削除すると、自動的に削除されます。

これらの管理対象リソース グループで問題が発生する場合は、サポートにお問い合わせください。

Container Apps ホスティングに関する考慮事項

Container Apps に関数アプリ コンテナーをデプロイする際には、次の考慮事項に注意してください。

  • すべてのトリガーを使用できますが、Container Apps 環境で実行するときは、(0 個のインスタンスから) 動的にスケーリングできるのは次のトリガーのみです。
    • HTTP
    • Azure Queue Storage
    • Azure Service Bus
    • Azure Event Hubs
    • Kafka
    • タイマー
  • Kafka トリガーには、次の制限が適用されます。
    • Container Apps でホストされているときは、プロトコル値 ssl はサポートされません。 別のプロトコル値を使用します。
    • Kafka トリガーが Event Hubs に接続された状態で動的にスケーリングするには、username プロパティが、実際のユーザー名の値を含むアプリケーション設定に解決される必要があります。 既定の $ConnectionString 値を使うと、Kafka トリガーでアプリを動的にスケーリングすることはできません。
  • 組み込みの Container Apps ポリシー定義では、現在、環境レベルのポリシーのみが Azure Functions コンテナーに適用されます。
  • マネージド ID は、トリガーとバインドの接続と、Azure Container Registry からのデプロイの両方に使用できます。
  • 関数アプリと Azure Container Registry ベースのデプロイのいずれかでマネージド ID ベースの接続が使われている場合、ポータルで CPU とメモリの割り当ての設定を変更することはできません。 代わりに、Azure CLI を使う必要があります。
  • 現在、リソース グループやサブスクリプション間で Container Apps でホストされる関数アプリの配置を移動できません。 代わりに、既存のコンテナー化されたアプリの配置を新しいリソース グループ、サブスクリプション、またはリージョンに再作成する必要があります。
  • Container Apps を使用する場合、下位レベルの Kubernetes API に直接アクセスすることはできません。
  • containerapp 拡張機能は Azure CLI の appservice-kube 拡張機能と競合します。 以前に Azure Arc にアプリをパブリッシュしたことがある場合は、az extension list を実行し、appservice-kube がインストールされていないことを確認してください。 インストールされている場合は、az extension remove -n appservice-kube を実行して削除できます。

次のステップ