昨日、「Azure Container Apps に Java Azure 関数をデプロイする」というタイトルの記事を書きました。
そのエントリでは、Azure の統合管理機能の使用について言及しましたが、それが何を意味するのか、そしてそれがこの記事で以前の方法とどのように異なるのかを明確にしたいと思います。
Azure Container Apps は、Azure のコンテナー実行環境の 1 つであり、コンテナー化されたサービスを実行できます。以前は、Azure Container Apps で Azure Functions を実行する場合は、次のコマンドを使用してインスタンスを作成していました。
az containerapp create \ --name general-container-app \ --resource-group $RESOURCE_GROUP_NAME \ --environment $CONTAINER_ENVIRONMENT \ --registry-server $CONTAINER_REGISTRY_SERVER \ --image $CONTAINER_REGISTRY_SERVER/$C_IMAGE_NAME:$C_IMAGE_TAG \ --target-port 80 \ --ingress external \ --query properties.configuration.ingress.fqdn
コマンドを実行すると、次のようなメッセージが表示されます。
Container app created. Access your app at https://general-container-app.niceocean-********.eastus.azurecontainerapps.io/
その後、curl コマンドを使用して Azure Functions サービスに接続できます。
curl https://general-container-app.niceocean-********.eastus.azurecontainerapps.io/api/httpexample?name=World
Azure Container Apps 環境にアクセスすると、general-container-app がコンテナ アプリとして作成され、この管理インターフェイスはデプロイされたコンテナ化されたアプリケーションで利用できることがわかります。
https://raw.githubusercontent.com/yoshioterada/Azure-Functions-Deploy-To-Azure-Container-Apps/main/images/ACA-Instance-for-Azure-Functions.png
新しい方法では、az contextapp create の代わりに az functionapp create コマンドを使用して、Azure Container Apps で Azure Functions を作成できます。
az functionapp create \ --name $AZURE_FUNCTION_NAME \ --resource-group $RESOURCE_GROUP_NAME \ --environment $CONTAINER_ENVIRONMENT \ --storage-account $STORAGE_NAME \ --workload-profile-name "Consumption" \ --max-replicas 15 \ --min-replicas 1 \ --functions-version 4 \ --runtime java \ --image $CONTAINER_REGISTRY_SERVER/$C_IMAGE_NAME:$C_IMAGE_TAG \ --assign-identity
このコマンドを使用すると、Azure Functions が Azure Container Apps に作成され、管理インターフェイスにはそれが Function App であることが明確に表示されます。
これは、Azure Functions が専用の Azure Functions 管理インターフェイスを通じて管理できるようになり、他のコンテナー アプリケーションとは異なることを意味します。
ただし、Azure App Service で提供される管理機能と、コンテナ アプリ上の Azure Functions で利用できる管理機能の間には、いくつかの違いがあります。たとえば、診断ツール、展開機能などの特定の機能が利用できない場合があります。
比較のために、Azure App Service にデプロイされた Azure Functions の管理インターフェイスを次に示します。
App Service と Azure Container Apps の管理機能には次のような違いがあります。
- Diagnose and solve problems - Microsoft Defender for Cloud - Events (preview) - Log stream - Deployment - App Service plan - Development Tools - Monitoring - Support + troubleshooting
特定の機能がないということは、機能が欠落していることを示唆していると考える人もいるかもしれません。
ただし、Azure Container Apps にデプロイすると、オペレーティング環境はコンテナベースになるため、デプロイと管理の方法が変わります。 Azure Functions 管理インターフェイスに含まれていない機能は、Azure Container Apps インターフェイスを通じて個別に管理する必要があります。
az functionapp create コマンドを使用して Azure Container Apps 上に Azure Functions インスタンスを作成すると、コンテナー インスタンスを収容する新しいリソース グループが自動的に作成されます。
私の環境では、リソース グループ名は次の規則に従います:
$CONTAINER_ENVIRONMENT_FunctionApps_$UUID
指定した $AZURE_FUNCTION_NAME にちなんで名付けられた Azure Container Apps インスタンスが生成されたことがわかります。
このインスタンスをクリックすると、Azure Container Apps に固有の管理インターフェイスに移動し、そこで Azure Functions がコンテナー インスタンスとして実行されます。
Azure Container Apps は、Azure App Service とは異なる CI/CD およびデプロイ方法を提供します。また、Dapr や Service Connector など、コンテナー レベルで提供される機能を利用できるようになります。
Previously, it was possible to run Azure Functions by containerizing them in a container execution environment, but there was no dedicated management interface for Azure Functions.
With this new method, Azure Functions and Azure Container Apps have integrated, offering a container environment with an associated Azure Functions management interface.
I know some customers operate Azure Functions Container on Azure Kubernetes Service (AKS). Previously, they lacked a dedicated management interface. However, by deploying to Azure Container Apps, they can now use Azure Functions management while enjoying the simplicity of managing Azure Container Apps compared to managing operations on AKS.
The methods for deploying Azure Functions to Azure Container Apps are likely to evolve further. I look forward to seeing how this develops.
以上がAzure Functions を Azure Container Apps にデプロイする 2 つの方法の比較の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。