関数アプリのデプロイを自動化するには、Bicep ファイルまたは Azure Resource Manager テンプレート (ARM テンプレート) を使用します。 デプロイ時に、既存の Azure リソースを使用することも、新しいリソースを作成することもできます。
デプロイの自動化 (コードとしてのインフラストラクチャ (IaC) と継続的インテグレーションとデプロイ (CI/CD) の両方) を使用すると、運用アプリに次の利点をもたらします。
- 整合性: 環境間で一貫したデプロイを確保するために、コードでインフラストラクチャを定義します。
- バージョン管理: プロジェクト コードと共に、ソース管理のインフラストラクチャとアプリケーション構成に対する変更を追跡します。
- 自動化: デプロイを自動化します。これにより、手動エラーが減り、リリース プロセスが短縮されます。
- スケーラビリティ: 開発、テスト、運用など、複数の環境のインフラストラクチャを簡単にレプリケートできます。
- ディザスター リカバリー: 障害が発生した後、または移行中にインフラストラクチャをすばやく再作成します。
この記事では、Azure FunctionsのAzure リソースとデプロイ構成の作成を自動化する方法について説明します。 プロジェクト コードの継続的配置の詳細については、Azure Functions の
必要なAzure リソースを作成するテンプレート コードは、関数アプリに必要なホスティング オプションによって異なります。 この記事では、次のホスティング オプションをサポートしています。
| ホスティング オプション | 展開の種類 | サンプル テンプレート |
|---|---|---|
| Flex 従量課金プラン | Code-only |
Bicep ARM テンプレート Teraform |
| プレミアムプラン | コード | コンテナー |
Bicep ARM テンプレート |
| 専用プラン | コード | コンテナー |
Bicep ARM テンプレート |
| Azure Container Apps | Container-only | Bicep |
| 従量課金プラン (旧) | Code-only |
Bicep ARM テンプレート |
新しいサーバーレス関数アプリの場合は、Flex 従量課金プランを使用します。
従量課金プランは、従来のホスティング プランです。 既存のアプリの場合は、 Flex 従量課金プランに移行します。
記事の上部にあるホスティング プランを選択してください。
Important
従量課金プランで Linux で 有効期間終了 v3 ランタイム を実行している関数アプリは、2026 年 9 月 30 日以降も実行を停止します。 サービスの中断を回避するには、 アプリを v4 ランタイムに移行します。
従量課金プランで Linux で関数アプリをホストするオプションは、2028 年 9 月 30 日に廃止されます。 Linux 従量課金プランでは、新しい機能や 言語バージョンは取得されません。 従量課金プランのWindowsで実行されているアプリは、現在影響を受けません。 提供終了日より前に、アプリを Flex 従量課金プランに移行します。
この記事を使用する際には、以下の考慮事項に留意してください。
ARM テンプレートを構造化する標準的な方法はありません。
Bicep デプロイは、複数の Bicep ファイルと Azure Verified Modules (AVM) にモジュール化できます。
この記事では、Bicep ファイルの作成またはAzure Resource Manager テンプレートの作成の基本的な理解があることを前提としています。
- 例は、特定のリソースの個々のセクションとして示されています。 Bicep ファイルと ARM テンプレートの幅広い例については、これらの関数アプリのデプロイの例を参照してください。
- 例は、特定のリソースの個々のセクションとして示されています。 Bicepの場合は、Azure Verified Modules (AVM) が表示されます (使用可能な場合)。 Bicep ファイルと ARM テンプレートの幅広い例については、 Flex Consumption アプリのデプロイ例を参照してください。
- 例は、特定のリソースの個々のセクションとして示されています。
必要なリソース
Azure Functionsホスト型デプロイ用にこれらのリソースを作成または構成する必要があります。
| Resource | Requirement | 構文とプロパティの参照 |
|---|---|---|
| ストレージ アカウント | Required | Microsoft。Storage/storageAccounts |
| Application Insights コンポーネント | Recommended | Microsoft。Insights/components* |
| ホスティング プラン | Required | Microsoft/Web/serverfarms |
| 関数アプリ | Required | Microsoft.Web/sites |
Azure Functionsホスト型デプロイ用にこれらのリソースを作成または構成する必要があります。
| Resource | Requirement | 構文とプロパティの参照 |
|---|---|---|
| ストレージ アカウント | Required | Microsoft。Storage/storageAccounts |
| Application Insights コンポーネント | Recommended | Microsoft。Insights/components* |
| 関数アプリ | Required | Microsoft.Web/sites |
Azure Container Appsホスト型デプロイは、通常、次のリソースで構成されます。
| Resource | Requirement | 構文とプロパティの参照 |
|---|---|---|
| ストレージ アカウント | Required | Microsoft。Storage/storageAccounts |
| Application Insights コンポーネント | Recommended | Microsoft。Insights/components* |
| マネージド環境 | Required | Microsoft.App/managedEnvironments |
| 関数アプリ | Required | Microsoft.Web/sites |
*Application Insights インスタンスで使用できる Log Analytics ワークスペースがまだない場合は、このリソースも作成する必要があります。
1 つのBicep ファイルまたは ARM テンプレートに複数のリソースをデプロイする場合、リソースを作成する順序が重要です。 この要件は、リソース間の依存関係に起因します。 このような依存関係では、必ず dependsOn 要素を使用して依存リソースの依存関係を定義してください。 詳細については、「ARM テンプレートでリソースをデプロイする順序を定義する」または「Bicep のリソース依存関係」を参照してください。
Prerequisites
- これらの例は、既存のリソース グループのコンテキストで機能します。
- Application Insights とストレージ ログの両方に、既存の Azure Log Analytics ワークスペースが必要です。 サービス間でワークスペースを共有できます。 パフォーマンスを向上させるには、各地理的リージョンにワークスペースを作成します。 Log Analytics ワークスペースを作成する方法の例については、「Log Analytics ワークスペースを作成するを参照してください。 完全指定のワークスペース リソース ID はAzure portal のワークスペース ページの [設定]>、[プロパティ]>[リソース ID] で見つけることができます。
- この記事では、Azure Container Apps で マネージド環境 を既に作成していることを前提としています。 Container Apps でホストされる関数アプリを作成するには、マネージド環境の名前と ID の両方が必要です。
ストレージ アカウントの作成
すべての関数アプリには、Azureストレージ アカウントが必要です。 BLOB、テーブル、キュー、ファイルをサポートする汎用アカウントが必要です。 詳細については、「Azure Functions ストレージ アカウントの要件を参照してください。
Important
ストレージ アカウントは、重要なアプリ データを格納するために使用されます。このデータには、アプリケーション コード自体が含まれることがあります。 他のアプリやユーザーによるストレージ アカウントへのアクセスを制限する必要があります。
このセクションの例では、Standard 汎用 v2 ストレージ アカウントを作成します。
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = {
name: storageAccountName
location: location
kind: 'StorageV2'
sku: {
name: 'Standard_LRS'
}
properties: {
supportsHttpsTrafficOnly: true
defaultToOAuthAuthentication: true
allowBlobPublicAccess: false
minimumTlsVersion: 'TLS1_2'
}
}
詳細については、テンプレート リポジトリの完全な main.bicep ファイルを参照してください。
詳細については、サンプル リポジトリの完全な storage-PrivateEndpoint.bicep ファイルを参照してください。
関数アプリには、このストレージ アカウントへの接続が必要です。
AzureWebJobsStorage設定を使用して、この接続を構成します。 詳細については、「 アプリケーションの構成」を参照してください。
Tip
セキュリティを強化するには、ストレージ アカウントのプロパティに allowSharedKeyAccess: false を追加し、接続文字列ではなくマネージド ID ベースの接続を使用します。 この記事の Flex Consumption プランの例では、 AzureWebJobsStorage__* ID ベースの設定やシステム割り当てマネージド ID など、このアプローチを使用します。 詳細については、「識別情報を使用してホストストレージに接続する方法」を参照してください。
Tip
セキュリティを強化するには、 allowSharedKeyAccess をストレージ アカウントで false に設定し、接続文字列ではなくマネージド ID ベースの接続を使用します。 詳細については、「アイデンティティを使用してホストストレージに接続するを参照してください。
Important
Elastic Premium プランと従量課金プランでは、コンテンツ共有に Azure Files が使用されており、Azure Files では現在、マネージド ID ベースの接続はサポートされていません。 この制限は、これらのプランではストレージ アカウントへの共有キー アクセスが必要であるため、 allowSharedKeyAccess を false に設定しないでください。 接続文字列を使用する必要がある場合は、Azure Key Vault に格納し、キーを直接格納するのではなく、アプリ設定で Key Vault 参照 を使用します。 Azure Files の依存関係を削除する場合は、「Azure Files を使用せずにアプリを作成する」を参照してください。
デプロイ コンテナー
Flex Consumption プランで実行されているアプリにデプロイするには、デプロイ ソースとして Azure Blob Storage 内のコンテナーが必要です。 既定のストレージ アカウントを使用することも、別のストレージ アカウントを指定することもできます。 詳しくは、「展開の設定を構成する」を参照してください。
アプリの作成時に、デプロイに使用される特定のコンテナーを含め、このデプロイ アカウントを構成する必要があります。 デプロイの構成の詳細については、「 デプロイ ソース」を参照してください。
この例は、ストレージ アカウントにコンテナーを作成する方法を示しています。
}
// Azure Functions Flex Consumption
module functionApp 'br/public:avm/res/web/site:0.16.0' = {
name: 'functionapp'
scope: rg
params: {
kind: 'functionapp,linux'
name: functionAppName_resolved
location: location
tags: union(tags, { 'azd-service-name': 'api' })
serverFarmResourceId: appServicePlan.outputs.resourceId
managedIdentities: {
systemAssigned: true
}
functionAppConfig: {
deployment: {
storage: {
type: 'blobContainer'
value: '${storage.outputs.primaryBlobEndpoint}${deploymentStorageContainerName}'
authentication: {
type: 'SystemAssignedIdentity'
}
この例では、ストレージ アカウントに AVM を使用して、ストレージ アカウントと共に BLOB ストレージ コンテナーを作成する方法を示します。 コンテキスト内のスニペットについては、このデプロイ例を参照してください。
アプリ自体で他の展開設定を構成します。
ストレージ ログを有効にする
ストレージ アカウントは重要な関数アプリ データに使用されるため、そのコンテンツの変更についてアカウントを監視します。 ストレージ アカウントを監視するには、Azure Storage の Azure Monitor リソース ログを構成します。 この例のセクションでは、myLogAnalytics という名前のLog Analytics ワークスペースをこれらのログの宛先として使用します。
resource blobService 'Microsoft.Storage/storageAccounts/blobServices@2023-05-01' existing = {
name:'default'
parent:storageAccountName
}
resource storageDataPlaneLogs 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
name: '${storageAccountName}-logs'
scope: blobService
properties: {
workspaceId: myLogAnalytics.id
logs: [
{
category: 'StorageWrite'
enabled: true
}
]
metrics: [
{
category: 'Transaction'
enabled: true
}
]
}
}
後で定義した Application Insights リソースに同じワークスペースを使用できます。 これらのログの操作方法など、詳細については、「Monitoring Azure Storageを参照してください。
Application Insights の作成
Application Insights を使用して、関数アプリの実行を監視します。 Application Insights には、共有できる Azure Log Analytics ワークスペースが必要になりました。 これらの例は、既存のワークスペースを使用していて、ワークスペースの完全修飾リソース ID があることを前提としています。 詳細については、「Azure Log Analytics workspace」を参照してください。
この例のセクションでは、 Microsoft.Insights/components の種類と webの種類を使用して Application Insights リソースを定義します。
resource applicationInsight 'Microsoft.Insights/components@2020-02-02' = {
name: applicationInsightsName
location: appInsightsLocation
tags: tags
kind: 'web'
properties: {
Application_Type: 'web'
WorkspaceResourceId: '<FULLY_QUALIFIED_RESOURCE_ID>'
}
}
詳細については、テンプレート リポジトリの完全な main.bicep ファイルを参照してください。
APPLICATIONINSIGHTS_CONNECTION_STRING アプリケーション設定を使用して、関数アプリへの接続を指定する必要があります。 詳細については、「 アプリケーションの構成」を参照してください。
この記事の例では、作成されたインスタンスの接続文字列値を取得します。 以前のバージョンでは、代わりに APPINSIGHTS_INSTRUMENTATIONKEY を使用してインストルメンテーション キーを設定する場合がありますが、これは推奨されません。
ホスティング プランの作成
Azure Functions Flex Consumption プラン、Premium プラン、または専用 (App Service) プランでホストされているアプリのホスティング プランを明示的に定義する必要があります。
Flex 従量課金は Linux ベースのホスティング プランで、従量課金の "使用した分だけ支払う" サーバーレス課金モデルに基づいています。 このプランの特徴は、プライベート ネットワーク、インスタンス メモリ サイズの選択のサポートと、マネージド ID のサポート向上です。
Flex 従量課金プランは、特殊なタイプの serverfarm リソースです。 これは、FC1 の値が Name の sku プロパティで tier プロパティ値に FlexConsumption を使用することで指定できます。
このセクションの例では、Flex 従量課金プランを作成します。
scaleAndConcurrency: {
maximumInstanceCount: maximumInstanceCount
instanceMemoryMB: instanceMemoryMB
}
runtime: {
name: functionAppRuntime
version: functionAppRuntimeVersion
}
}
siteConfig: {
alwaysOn: false
}
configs: [{
name: 'appsettings'
properties:{
この例では、App Service プランの AVM を使用します。 コンテキスト内のスニペットについては、このデプロイ例を参照してください。
Flex 従量課金プランは現在 Linux のみをサポートしているため、reserved プロパティを true に設定する必要もあります。
Premium プランでは、従量課金プランと同じスケーリングが提供されますが、専用リソースとその他の機能が含まれています。 詳細については、「Azure Functions Premium プラン」を参照してください。
Premium プランは、特殊なタイプの serverfarm リソースです。 これは、EP1 プロパティで EP2 プロパティの EP3、Name、sku のいずれかの値を使用して指定できます。 Functions ホスティング プランを定義する方法は、関数アプリが Windows または Linux で実行されているかどうかによって異なります。 次の例のセクションでは EP1 プランを作成します。
resource hostingPlan 'Microsoft.Web/serverfarms@2024-04-01' = {
name: hostingPlanName
location: location
sku: {
name: 'EP1'
tier: 'ElasticPremium'
family: 'EP'
}
kind: 'elastic'
properties: {
maximumElasticWorkerCount: 20
}
}
詳細については、テンプレート リポジトリの完全な main.bicep ファイルを参照してください。
sku オブジェクトに関する詳細については、SkuDefinition を参照するか、テンプレートの例を確認してください。
専用 (App Service) プランでは、関数アプリは、Web アプリと同様に、App Service プランの Basic、Standard、Premium SKU 上の専用仮想マシン上で実行されます。 詳細については、「 専用プラン」を参照してください。
Azure App Service プランの Function アプリのサンプル Bicep ファイル/Azure Resource Manager テンプレートを参照してください。
Functions では、Dedicated プランは、serverfarm リソースによって定義される通常の App Service プランです。 少なくとも name 個の値を指定する必要があります。 サポートされているプラン名の一覧については、専用プランで現在サポートされている値の一覧で --sku の az appservice plan create 設定を参照してください。
ホスティング プランを定義する方法は、関数アプリが Windows または Linux で実行されているかどうかによって異なります。
resource hostingPlanName 'Microsoft.Web/serverfarms@2024-04-01' = {
name: hostingPlanName
location: location
sku: {
tier: 'Standard'
name: 'S1'
size: 'S1'
family: 'S'
capacity: 1
}
}
詳細については、テンプレート リポジトリの完全な main.bicep ファイルを参照してください。
ホスティング プランの作成
従量課金ホスティング プランのリソースを明示的に定義する必要はありません。 このリソース定義をスキップすると、関数アプリ リソースを作成する際に、ポータルによってリージョンごとにプランが自動的に作成または選択されます。
従量課金プランは、特別な種類の serverfarm リソースとして明示的に定義できます。
computeModeプロパティとskuプロパティをDynamicに設定します。 このセクションの例は、従量課金プランを明示的に定義する方法を示しています。 ホスティング プランを定義する方法は、関数アプリが Windows または Linux で実行されているかどうかによって異なります。
resource hostingPlan 'Microsoft.Web/serverfarms@2024-04-01' = {
name: hostingPlanName
location: location
sku: {
name: 'Y1'
tier: 'Dynamic'
size: 'Y1'
family: 'Y'
capacity: 0
}
properties: {
computeMode: 'Dynamic'
}
}
詳細については、テンプレート リポジトリの完全な main.bicep ファイルを参照してください。
関数アプリの作成
関数アプリ リソースを、Microsoft.Web/sitesを含むkind プロパティを使用してfunctionapp型のリソースとして定義します。
関数アプリ リソースを定義する方法は、Linux と Windows のどちらをホストしているかによって異なります。
Windowsで実行するときに必要なアプリケーション設定の一覧については、アプリケーション構成を参照してください。 Bicep ファイルまたは Azure Resource Manager テンプレートのサンプルについては、 従量課金プラン テンプレートの Windows でホストされている関数アプリを 参照してください。
Windowsで実行するときに必要なアプリケーション設定の一覧については、アプリケーション構成を参照してください。
Flex Consumption は、Bicepおよび ARM テンプレートの展開で使用される標準のアプリケーション設定とサイト構成プロパティの多くを置き換えます。 詳細については、「 アプリケーションの構成」を参照してください。
AzureWebJobsStorage__blobServiceUri: 'https://${storage.outputs.name}.blob.${environment().suffixes.storage}'
AzureWebJobsStorage__queueServiceUri: 'https://${storage.outputs.name}.queue.${environment().suffixes.storage}'
AzureWebJobsStorage__tableServiceUri: 'https://${storage.outputs.name}.table.${environment().suffixes.storage}'
// Application Insights settings are always included
APPLICATIONINSIGHTS_CONNECTION_STRING: applicationInsights.outputs.connectionString
APPLICATIONINSIGHTS_AUTHENTICATION_STRING: 'Authorization=AAD'
}
}]
}
}
// Consolidated Role Assignments
module rbacAssignments 'rbac.bicep' = {
name: 'rbacAssignments'
scope: rg
params: {
storageAccountName: storage.outputs.name
appInsightsName: applicationInsights.outputs.name
managedIdentityPrincipalId: functionApp.outputs.?systemAssignedMIPrincipalId ?? ''
userIdentityPrincipalId: principalId
allowUserIdentityPrincipal: !empty(principalId)
}
}
// Outputs
output AZURE_LOCATION string = location
output AZURE_TENANT_ID string = tenant().tenantId
output AZURE_FUNCTION_NAME string = functionApp.outputs.name
output APPLICATIONINSIGHTS_CONNECTION_STRING string = applicationInsights.outputs.connectionString
この例では、AVM を関数アプリに使用します。 コンテキスト内のスニペットについては、このデプロイ例を参照してください。
Note
従量課金プランをオプションで定義することを選択する場合は、アプリで serverFarmId プロパティを設定して、それがプランのリソース ID を指すようにする必要があります。 同様に、そのプランを参照する dependsOn 設定が関数アプリに含まれていることを確認してください。 明示的にプランを定義していない場合は、ユーザー向けのプランが作成されます。
プランのリソース ID を参照するようにアプリの serverFarmId プロパティを設定します。 同様に、そのプランを参照する dependsOn 設定が関数アプリに含まれていることを確認してください。
resource functionAppName_resource 'Microsoft.Web/sites@2024-04-01' = {
name: functionAppName
location: location
kind: 'functionapp'
properties: {
serverFarmId: hostingPlanName.id
siteConfig: {
appSettings: [
{
name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
value: applicationInsightsName.properties.ConnectionString
}
{
name: 'AzureWebJobsStorage'
value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${storageAccount.listKeys().keys[0].value}'
}
{
name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING'
value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${storageAccount.listKeys().keys[0].value}'
}
{
name: 'WEBSITE_CONTENTSHARE'
value: toLower(functionAppName)
}
{
name: 'FUNCTIONS_EXTENSION_VERSION'
value: '~4'
}
{
name: 'FUNCTIONS_WORKER_RUNTIME'
value: 'node'
}
{
name: 'WEBSITE_NODE_DEFAULT_VERSION'
value: '~20'
}
]
}
}
}
完全なエンドツーエンドの例については、このmain.bicep ファイルを参照してください。
resource functionApp 'Microsoft.Web/sites@2024-04-01' = {
name: functionAppName
location: location
kind: 'functionapp'
properties: {
serverFarmId: hostingPlan.id
siteConfig: {
alwaysOn: true
appSettings: [
{
name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
value: applicationInsightsName.properties.ConnectionString
}
{
name: 'AzureWebJobsStorage'
value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${storageAccount.listKeys().keys[0].value}'
}
{
name: 'FUNCTIONS_EXTENSION_VERSION'
value: '~4'
}
{
name: 'FUNCTIONS_WORKER_RUNTIME'
value: 'node'
}
{
name: 'WEBSITE_NODE_DEFAULT_VERSION'
value: '~20'
}
]
}
}
}
完全なエンドツーエンドの例については、このmain.bicep ファイルを参照してください。
デプロイ ソース
linuxFxVersion サイト設定を使用して、作成時にアプリにデプロイする特定の Linux コンテナーを要求します。 プライベート リポジトリ内のイメージにアクセスするには、さらに設定が必要です。 詳細については、「 アプリケーションの構成」を参照してください。
Important
独自のコンテナーを作成するときは、コンテナーの基本イメージを、サポートされている最新の基本イメージに更新しておく必要があります。 Azure Functionsでサポートされている基本イメージは言語固有です。 Azure Functions基本イメージ リポジトリを参照してください。
Functions チームは、これらの基本イメージの更新プログラムを毎月公開できるよう取り組んでいます。 通常の更新プログラムには、Functions ランタイムと言語の両方について、最新のマイナー バージョンの更新プログラムとセキュリティ修正プログラムが含まれます。 最新の基本イメージからコンテナーを定期的に更新し、コンテナーの更新されたバージョンを再デプロイする必要があります。 詳しくは、「カスタム コンテナーのメンテナンス」をご覧ください。
Bicep ファイルまたは ARM テンプレートでは、必要に応じて関数コードのデプロイを定義することもできます。 このデプロイには、次の方法を含めることができます。
Flex Consumption プランでは、 デプロイ コンテナーと呼ばれる BLOB ストレージ コンテナー内の zip 圧縮パッケージ ファイルにプロジェクト コードが保持されます。 デプロイに使用するストレージ アカウントとコンテナーの両方を構成できます。 詳細については、「 デプロイ」を参照してください。
コード パッケージをデプロイ コンテナーに発行するには、 1 つの デプロイを使用する必要があります。 ARM テンプレートまたは Bicep のデプロイ中に、拡張機能を使用する/onedeployすることで、この手順を実行できます。 代わりにパッケージをコンテナーに直接アップロードすることを選択した場合、パッケージは自動的にデプロイされません。
デプロイ コンテナー
サイトのfunctionAppConfig.deployment.storageのproperties要素で、デプロイに使用される特定のストレージ アカウントとコンテナー、認証方法、資格情報を設定します。 コンテナーとアプリケーション設定は、アプリの作成時に存在する必要があります。 ストレージ コンテナーを作成する方法の例については、「 デプロイ コンテナー」を参照してください。
この例は、システム割り当てマネージド ID を使用して、指定された Blob Storage コンテナーにアクセスします。これはデプロイ内の別の場所に作成されます。
// Consolidated Role Assignments
module rbacAssignments 'rbac.bicep' = {
name: 'rbacAssignments'
scope: rg
params: {
storageAccountName: storage.outputs.name
appInsightsName: applicationInsights.outputs.name
managedIdentityPrincipalId: functionApp.outputs.?systemAssignedMIPrincipalId ?? ''
userIdentityPrincipalId: principalId
allowUserIdentityPrincipal: !empty(principalId)
}
}
// Outputs
output AZURE_LOCATION string = location
output AZURE_TENANT_ID string = tenant().tenantId
output AZURE_FUNCTION_NAME string = functionApp.outputs.name
output APPLICATIONINSIGHTS_CONNECTION_STRING string = applicationInsights.outputs.connectionString
この例では、AVM を関数アプリに使用します。 コンテキスト内のスニペットについては、このデプロイ例を参照してください。
マネージド ID を使用する場合は、次の例に示すように、関数アプリが ID を使用してストレージ アカウントにアクセスできるようにする必要もあります。
module storageRoleAssignment_User 'br/public:avm/ptn/authorization/resource-role-assignment:0.1.2' = if (allowUserIdentityPrincipal && !empty(userIdentityPrincipalId)) {
name: 'storageRoleAssignment-User-${uniqueString(storageAccount.id, userIdentityPrincipalId)}'
params: {
resourceId: storageAccount.id
roleDefinitionId: roleDefinitions.storageBlobDataOwner
principalId: userIdentityPrincipalId
principalType: 'User'
description: 'Storage Blob Data Owner role for user identity (development/testing)'
roleName: 'Storage Blob Data Owner'
}
}
この例では、リソーススコープのロール割り当てとしてAVMを使用します。 コンテキスト内のスニペットについては、このデプロイ例を参照してください。
この例では、割り当てるロールの GUID 値を知っている必要があります。 フレンドリ ロール名に対してこの ID 値を取得するには、次の例に示すように az role definition list コマンドを使用します。
az role definition list --output tsv --query "[?roleName=='Storage Blob Data Owner'].{name:name}"
マネージド ID の代わりに接続文字列を使用する場合は、 authentication.type を StorageAccountConnectionString に設定し、 authentication.storageAccountConnectionStringName デプロイ ストレージ アカウントの接続文字列を含むアプリケーション設定の名前に設定します。
展開パッケージ
Flex Consumption プランでは、コード プロジェクトの デプロイに 1 つのデプロイ が使用されます。 コード パッケージ自体は、他の Functions ホスティング プランで zip デプロイに使用するパッケージと同じです。 ただし、パッケージ ファイルの名前は released-package.zipする必要があります。
テンプレートに 1 つのデプロイ パッケージを含めるには、デプロイ パッケージを含むリモート URL の /onedeploy リソース定義を使用します。 Functions ホストは、このリモート パッケージ ソースとデプロイ コンテナーの両方にアクセスできる必要があります。
次の例では、既存のアプリに 1 つのデプロイ ソースを追加します。
@description('The name of the function app.')
param functionAppName string
@description('The location into which the resources should be deployed.')
param location string = resourceGroup().location
@description('The zip content URL for released-package.zip.')
param packageUri string
resource functionAppName_OneDeploy 'Microsoft.Web/sites/extensions@2022-09-01' = {
name: '${functionAppName}/onedeploy'
location: location
properties: {
packageUri: packageUri
remoteBuild: false
}
}
Bicep ファイルまたは ARM テンプレートでは、必要に応じて 、zip デプロイ パッケージを使用して関数コードのデプロイを定義することもできます。
Azure Resource Manager を使用してアプリケーションを正常にデプロイするには、Azure でのリソースのデプロイ方法を理解する必要があります。 ほとんどの例では、 siteConfigを使用して最上位レベルの構成を適用します。 これらの構成は、Functions ランタイムおよびデプロイ エンジンに情報を伝達するため、最上位レベルで設定します。 デプロイ エンジンでは、子 sourcecontrols/web リソースを適用する前に、最上位レベルの情報が必要です。 これらの設定は子レベルのconfig/appSettings リソースで構成できますが、場合によっては、関数アプリを適用する前にデプロイする必要がありますconfig/appSettings。
zip 展開パッケージ
Zip デプロイは、関数アプリ コードをデプロイするための推奨される方法です。 既定では、zip 展開を使用する関数は展開パッケージ自体で実行されます。 展開パッケージの要件を含む詳細については、「Azure Functions の
テンプレートで zip 展開を使用するには、アプリの WEBSITE_RUN_FROM_PACKAGE 設定を 1 に設定し、/zipDeploy リソース定義を含めます。
Linux の従量課金プランでは、デプロイ パッケージの URI を直接 WEBSITE_RUN_FROM_PACKAGE 設定に設定します。例として、このサンプル テンプレート を参照してください。
次の例では、既存のアプリに zip 展開ソースを追加します。
@description('The name of the function app.')
param functionAppName string
@description('The location into which the resources should be deployed.')
param location string = resourceGroup().location
@description('The zip content url.')
param packageUri string
resource functionAppName_ZipDeploy 'Microsoft.Web/sites/extensions@2024-04-01' = {
name: '${functionAppName}/ZipDeploy'
location: location
properties: {
packageUri: packageUri
}
}
テンプレートに zip デプロイ リソースを含めるとき、次の考慮事項に注意してください。
- Linux の従量課金プランは
WEBSITE_RUN_FROM_PACKAGE = 1をサポートしていません。 代わりに、WEBSITE_RUN_FROM_PACKAGE設定で展開パッケージの URI を直接設定する必要があります。 詳細については、 WEBSITE_RUN_FROM_PACKAGEを参照してください。 テンプレートの例については、従量課金プランで Linux でホストされている Function アプリを参照してください。
packageUriは、Functions がアクセスできる場所である必要があります。 Shared Access Signature (SAS) で Azure Blob Storage を使用することを検討してください。 SAS の有効期限が切れると、Functions はデプロイのために共有にアクセスできなくなります。 SAS を再生成する場合は、WEBSITE_RUN_FROM_PACKAGE設定を新しい URI 値で更新することを忘れないでください。WEBSITE_RUN_FROM_PACKAGEを URI に設定する場合は、トリガーを手動で同期する必要があります。設定を追加または更新するときは、常に
appSettingsコレクション内のすべての必要なアプリケーション設定を設定します。 この更新プログラムは、明示的に設定していない既存の設定を削除します。 詳細については、「 アプリケーションの構成」を参照してください。関数は、パッケージの展開に対して Web 配置 (
msdeploy) をサポートしていません。 代わりに、デプロイ パイプラインと自動化で zip 展開を使用する必要があります。 詳細については、「Azure Functions のZip 展開」を参照してください。
リモート ビルド
デプロイ プロセスでは、使用する .zip ファイルまたは zip デプロイに、すぐに実行できるアプリが含まれていることを前提としています。 この前提は、既定ではカスタマイズが実行されていないことを意味します。
一部のシナリオでは、アプリをリモートで再構築する必要があります。 1 つの例として、Linux 固有のパッケージを Python または Windows コンピューターで開発した Node.js アプリに含める必要がある場合があります。 この場合、zip 展開後にコードのリモート構築を実行するように Functions を構成できます。
リモート ビルドを要求する方法は、デプロイ先のオペレーティング システムによって異なります。
Linux コンテナー
コンテナー化された関数アプリを Azure Functions Premium または Dedicated プランにデプロイする場合は、次の手順を実行する必要があります。
-
linuxFxVersionサイト設定にコンテナー イメージの識別子を設定します。 - プライベート レジストリからコンテナーを取得する場合に必要な
DOCKER_REGISTRY_SERVER_*設定を設定します。 -
WEBSITES_ENABLE_APP_SERVICE_STORAGEアプリケーション設定をfalseに設定します。
一部の設定が見つからない場合は、こちらの HTTP/500 エラーでアプリケーションのプロビジョニングが失敗する可能性があります。
Function app provisioning failed.
詳細については、「 アプリケーションの構成」を参照してください。
resource functionApp 'Microsoft.Web/sites@2024-04-01' = {
name: functionAppName
location: location
kind: 'functionapp'
properties: {
serverFarmId: hostingPlan.id
siteConfig: {
appSettings: [
{
name: 'AzureWebJobsStorage'
value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};AccountKey=${storageAccount.listKeys().keys[0].value}'
}
{
name: 'FUNCTIONS_WORKER_RUNTIME'
value: 'node'
}
{
name: 'WEBSITE_NODE_DEFAULT_VERSION'
value: '~20'
}
{
name: 'FUNCTIONS_EXTENSION_VERSION'
value: '~4'
}
{
name: 'DOCKER_REGISTRY_SERVER_URL'
value: dockerRegistryUrl
}
{
name: 'DOCKER_REGISTRY_SERVER_USERNAME'
value: dockerRegistryUsername
}
{
name: 'DOCKER_REGISTRY_SERVER_PASSWORD'
value: dockerRegistryPassword
}
{
name: 'WEBSITES_ENABLE_APP_SERVICE_STORAGE'
value: 'false'
}
]
linuxFxVersion: 'DOCKER|myacr.azurecr.io/myimage:mytag'
}
}
dependsOn: [
storageAccount
]
}
コンテナー化された関数を Azure Container Apps にデプロイする場合、テンプレートは次の手順を実行する必要があります。
-
kindフィールドをfunctionapp,linux,container,azurecontainerappsの値に設定します。 -
managedEnvironmentIdサイト プロパティに、Container Apps 環境の完全修飾 URI を設定します。 -
dependsOnリソースをサイトと同時に作成するときに、サイトのMicrosoft.App/managedEnvironmentsコレクションにリソース リンクを追加します。
プライベート コンテナー レジストリから既存の Container Apps 環境にデプロイされるコンテナー化関数アプリの定義は、次の例のようになります。
resource functionApp 'Microsoft.Web/sites@2024-04-01' = {
name: functionAppName
kind: 'functionapp,linux,container,azurecontainerapps'
location: location
properties: {
serverFarmId: hostingPlanName
siteConfig: {
linuxFxVersion: 'DOCKER|myacr.azurecr.io/myimage:mytag'
appSettings: [
{
name: 'FUNCTIONS_EXTENSION_VERSION'
value: '~4'
}
{
name: 'AzureWebJobsStorage'
value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};AccountKey=${storageAccount.listKeys().keys[0].value}'
}
{
name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
value: applicationInsightsName.properties.ConnectionString
}
]
}
managedEnvironmentId: managedEnvironmentId
}
dependsOn: [
storageAccount
hostingPlan
]
}
アプリケーションの構成
Flex 従量課金プランでは、次の 2 種類のプロパティを使用して、Azureで関数アプリを構成します。
| Configuration |
Microsoft.Web/sites プロパティ |
|---|---|
| アプリケーションの構成 | functionAppConfig |
| アプリケーションの設定 |
siteConfig.appSettings コレクション |
これらのアプリケーション構成は、 functionAppConfigで管理します。
| Behavior |
functionAppConfig での設定 |
|---|---|
| 常時使用可能なインスタンス | scaleAndConcurrency.alwaysReady |
| デプロイ ソース | deployment |
| インスタンス サイズ | scaleAndConcurrency.instanceMemoryMB |
| HTTP トリガーのコンカレンシー | scaleAndConcurrency.triggers.http.perInstanceConcurrency |
| 言語ランタイム | runtime.name |
| 言語バージョン | runtime.version |
| 最大インスタンス数 | scaleAndConcurrency.maximumInstanceCount |
| サイトの更新戦略 | siteUpdateStrategy.type |
Flex 従量課金プランは、次のアプリケーション設定もサポートしています。
- 接続文字列ベースの設定:
- マネージド ID ベースの設定:
Functions には、Azureで関数アプリを構成するための次のオプションが用意されています。
| Configuration |
Microsoft.Web/sites プロパティ |
|---|---|
| サイトの設定 | siteConfig |
| アプリケーションの設定 |
siteConfig.appSettings コレクション |
siteConfig プロパティには、次のサイト設定が必要です。
これらのサイト設定は、マネージド ID を使用して Azure Container Registry インスタンスからイメージを取得する場合にのみ必要です。
これらのアプリケーション設定は、特定のオペレーティング システムとホスティング オプションに必須 (または推奨) です。
次のアプリケーション設定は、コンテナーのデプロイに必要です。
次の設定は、プライベート コンテナー レジストリからデプロイする場合にのみ必要です。
Bicep ファイルまたは ARM テンプレートを使用してサイトとアプリケーションの設定を操作する場合は、次の考慮事項に注意してください。
- 省略可能な
alwaysReadyの設定には、1 つ以上の{name,instanceCount}オブジェクトの配列が含まれます。このオブジェクトは、関数別のスケール グループごとに 1 つあります。 これらのスケール グループは、常に準備が整ったスケールの決定を行います。 この例では、httpグループと、グループ化されていないトリガーの種類であるhelloworldという名前の 1 つの関数の両方に対して、常時使用可能な数を設定します。alwaysReady: [ { name: 'http' instanceCount: 2 } { name: 'function:helloworld' instanceCount: 1 } ]
- 自動デプロイで
WEBSITE_CONTENTSHAREを設定するタイミングを検討します。 詳しいガイダンスについては、WEBSITE_CONTENTSHAREリファレンスを参照してください。
- コンテナー デプロイの場合、アプリのコンテンツはコンテナー自体で提供されるため、
WEBSITES_ENABLE_APP_SERVICE_STORAGEをfalseにも設定します。
この記事の例に示すように、作成する
siteConfig/appSettingsリソースのMicrosoft.Web/sitesコレクションとしてアプリケーション設定を常に定義します。 この定義により、関数アプリの実行に必要な設定が初期起動時に利用できるようになります。テンプレートを使用してアプリケーション設定を追加または更新する場合は、既存のすべての設定を更新プログラムに含めるようにしてください。 基礎となる更新 REST API 呼び出しは
/config/appsettingsリソース全体を置き換えるため、これを行う必要があります。 既存の設定を削除すると、関数アプリは実行されません。 プログラムによって個々のアプリケーション設定を更新するには、代わりにAzure CLI、Azure PowerShell、またはAzure ポータルを使用してこれらの変更を行うことができます。 詳細については、「アプリケーション設定を操作する」を参照してください。可能であれば、
AzureWebJobsStorage接続を含む他の Azure サービスへのマネージド ID ベースの接続を使用します。 詳細については、「ID ベースの接続を構成する」を参照してください。
スロットのデプロイ
Functions を使用すると、異なるバージョンのコードを関数アプリ内の固有のエンドポイントにデプロイできます。 このオプションにより、運用環境で実行中の関数に影響を与えることなく、関数の更新の開発、検証、デプロイが簡略化されます。 デプロイ スロットは、Azure App Serviceの機能です。 使用できるスロットの数は、ホスティング プランによって異なります。 詳細については、「Azure Functions デプロイ スロットを参照してください。
スロット リソースは、関数アプリ リソース (Microsoft.Web/sites) と同じ方法で定義しますが、代わりに Microsoft.Web/sites/slots リソース識別子を使用します。 Premium プランで運用スロットとステージング スロットの両方を作成するデプロイの例 (Bicep と ARM テンプレートの両方) については、「
テンプレートを使用してスロットをスワップする方法については、「Resource Manager テンプレートを使用した自動を参照してください。
スロットのデプロイをを行う場合は、次の考慮事項に留意してください。
デプロイ スロットの定義で
WEBSITE_CONTENTSHARE設定を明示的に設定しないでください。 デプロイ スロットのアプリ作成プロセスによって、この設定が生成されます。スロットを入れ替えると、いくつかのアプリケーション設定は "粘着性" とみなされ、入れ替えるコードではなくスロットに保持されます。 このような スロット設定 は、テンプレートの特定のアプリケーション設定定義に
"slotSetting":trueを含めることで定義できます。 詳細については、「設定の 管理」を参照してください。
セキュリティで保護された展開
仮想ネットワークと統合することで、1 つ以上のリソースをセキュリティで保護するデプロイで関数アプリを作成できます。
Microsoft.Web/sites/networkConfig リソースは、関数アプリの仮想ネットワーク統合を定義します。 この統合は、参照される関数アプリと仮想ネットワーク リソースの両方に依存します。 お使いの関数アプリが、プライベート エンドポイントやルートなど、他のプライベート ネットワーク リソースに依存する場合もあります。 詳細については、「Azure Functions ネットワーク オプションを参照してください。
これらのプロジェクトは、ネットワーク アクセス制限を含め、仮想ネットワークに関数アプリをデプロイする方法のBicepベースの例を提供します。
- 高度な HTTP トリガー関数は、仮想ネットワークによってセキュリティで保護されたイベント ハブに接続します: HTTP によってトリガーされる関数 (.NET分離ワーカー モード) は、任意のソースからの呼び出しを受け入れ、仮想ネットワーク統合を使用して、仮想ネットワークで実行されているセキュリティで保護されたイベント ハブにそれらの HTTP 呼び出しの本文を送信します。
- Function は、仮想ネットワークでセキュリティ保護されたService Bus キューによってトリガーされます: Python関数は、仮想ネットワークでセキュリティ保護されたService Bus キューによってトリガーされます。 キューは、仮想ネットワーク内でプライベート エンドポイントを使用してアクセスされます。 仮想ネットワーク内の仮想マシンは、メッセージを送信するために使用されます。
セキュリティで保護されたストレージ アカウントを使用するデプロイを作成する場合は、 WEBSITE_CONTENTSHARE 設定を明示的に設定し、この設定で指定されたファイル共有リソースを作成する必要があります。 この例 (Microsoft.Storage/storageAccounts/fileServices/sharesWEBSITE_CONTENTSHAREBicep ファイル) に示すように、|の値を使用して、 リソースを作成してください。 また、サイト プロパティの vnetContentShareEnabled を true に設定する必要があります。
Note
これらの設定が、セキュリティで保護されたストレージ アカウントを使用するデプロイの一部でない場合は、展開の検証中に次のエラーが表示されます: Could not access storage account using provided connection string。
これらのプロジェクトには、ネットワーク アクセス制限を含め、仮想ネットワークに関数アプリをデプロイする方法のBicepと ARM テンプレートの両方の例が用意されています。
| 制限付きシナリオ | Description |
|---|---|
| 仮想ネットワーク統合を使用して関数アプリを作成します | 関数アプリは、そのネットワーク内のリソースにフル アクセスできる仮想ネットワーク内に作成します。 関数アプリへの受信および送信アクセスは制限されません。 詳細については、「仮想ネットワークの統合」を参照してください。 |
| セキュリティで保護されたストレージ アカウントにアクセスする関数アプリを作成します | 作成した関数アプリは、セキュリティで保護されたストレージ アカウントを使用します。これは、プライベート エンドポイントを使用して Functions でアクセスします。 詳細については、「ストレージ アカウントを仮想ネットワークに制限する」を参照してください。 |
| プライベート エンドポイントを使用する関数アプリとストレージ アカウントを作成します | 作成した関数アプリは、プライベート エンドポイントを使用することでのみアクセスでき、プライベート エンドポイントを使用してストレージ リソースにアクセスします。 詳細については、プライベート エンドポイントに関する記事を参照してください。 |
制限付きネットワーク設定
関数アプリにネットワーク制限がある場合にも、次のような設定が必要になる場合があります。
| Setting | Value | Description |
|---|---|---|
WEBSITE_CONTENTOVERVNET |
1 |
ストレージ アカウントを仮想ネットワークに制限している場合に、関数アプリをスケーリングできるアプリケーション設定。 詳細については、「ストレージ アカウントを仮想ネットワークに制限する」を参照してください。 |
vnetrouteallenabled |
1 |
関数アプリからのすべてのトラフィックに強制的に仮想ネットワークを使用させるサイト設定。 詳細については、リージョン仮想ネットワーク統合に関する記事を参照してください。 このサイト設定は、アプリケーション設定 WEBSITE_VNET_ROUTE_ALL に優先します。 |
ネットワークの制限に対する考慮事項
プライベート エンドポイントを介してストレージ アカウントへのアクセスを制限する場合、ポータルまたは仮想ネットワークの外部の任意のデバイスからストレージ アカウントにアクセスすることはできません。 既定のネットワーク アクセス ルールを管理することで、セキュリティで保護された IP アドレスまたはストレージ アカウントの仮想ネットワークにアクセス権を付与できます。
関数のアクセス キー
ホスト レベルの 関数アクセス キー を Azure リソースとして定義します。 この方法では、ARM テンプレートと Bicep ファイルでホスト キーを作成および管理できます。 ホスト キーは、Microsoft.Web/sites/host/functionKeys 型のリソースとして定義されます。 次の例では、関数アプリの作成時に my_custom_key という名前のホスト レベルのアクセス キーを作成します。
resource functionKey 'Microsoft.Web/sites/host/functionKeys@2022-09-01' = {
name: '${parameters('name')}/default/my_custom_key'
properties: {
name: 'my_custom_key'
}
dependsOn: [
resourceId('Microsoft.Web/Sites', parameters('name'))
]
}
この例では、name パラメーターは新しい関数アプリの名前です。 新しい関数アプリでキーが作成されることを保証するには、dependsOn 設定を含める必要があります。 最後に、ホスト キーの properties オブジェクトには、特定のキーを設定するために使用できる value プロパティを含めることもできます。
value プロパティを設定しない場合、リソースの作成時に関数によって新しいキーが自動的に生成されます。これは推奨されます。 アクセス キーの操作に関するセキュリティのベスト プラクティスなど、アクセス キーの詳細については、「Work with access keys in Azure Functions」を参照してください。
テンプレートを作成する
Bicep または ARM テンプレートを使用するエキスパートは、単純なテキスト エディターを使用してデプロイを手動でコーディングできます。 残りの部分では、いくつかのオプションを使用すると、開発プロセスが簡単になります。
Visual Studio Code: 拡張機能は、 Bicep ファイル と ARM テンプレートの両方を操作するのに役立ちます。 これらのツールを使用して、コードが正しいことを確認します。 基本的な検証を提供します。
Azure portal: ポータルで関数アプリと関連リソースを作成します 最後の Review + create 画面には、オートメーション用テンプレートのダウンロード リンクがあります。
このリンクには、ポータルで選択したオプションに基づいて生成された ARM テンプレートが表示されます。 多くの新しいリソースを含む関数アプリを作成する場合、このテンプレートは少し複雑に見える可能性があります。 ただし、ARM テンプレートの外観に関する適切なリファレンスを提供できます。
テンプレートを検証する
展開テンプレート ファイルを手動で作成する場合、デプロイ前にテンプレートを検証することが重要です。 すべてのデプロイ手法でテンプレートの構文を検証し、次の JSON 形式の例に示すように validation failed エラー メッセージが発生します。
{"error":{"code":"InvalidTemplate","message":"Deployment template validation failed: 'The resource 'Microsoft.Web/sites/func-xyz' is not defined in the template. Please see https://aka.ms/arm-template for usage details.'.","additionalInfo":[{"type":"TemplateViolation","info":{"lineNumber":0,"linePosition":0,"path":""}}]}}
デプロイ前にテンプレートを検証するには、次の方法を使用します。
次の Azure リソース グループデプロイ v2 タスクdeploymentMode: 'Validation' では、テンプレートの検証をAzure Pipelinesに指示します。
- task: AzureResourceManagerTemplateDeployment@3
inputs:
deploymentScope: 'Resource Group'
subscriptionId: # Required subscription ID
action: 'Create Or Update Resource Group'
resourceGroupName: # Required resource group name
location: # Required when action == Create Or Update Resource Group
templateLocation: 'Linked artifact'
csmFile: # Required when TemplateLocation == Linked Artifact
csmParametersFile: # Optional
deploymentMode: 'Validation'
テスト リソース グループを作成して、 プレフライト と デプロイ のエラーを見つけることもできます。
テンプレートのデプロイ
Bicep ファイルとテンプレートをデプロイするには、次のいずれかの方法を使用します。
[deploy to Azure]\(Azureへのデプロイ\) ボタン
Note
このメソッドは、現在Bicepファイルのデプロイをサポートしていません。
<url-encoded-path-to-azuredeploy-json> を、GitHub内の ファイルの生パスの azuredeploy.json バージョンに置き換えます。
マークダウンを使用する例を次に示します。
[](https://portal.azure.com/#create/Microsoft.Template/uri/<url-encoded-path-to-azuredeploy-json>)
HTML を使用する例を次に示します。
<a href="https://portal.azure.com/#create/Microsoft.Template/uri/<url-encoded-path-to-azuredeploy-json>" target="_blank"><img src="https://azuredeploy.net/deploybutton.png"></a>
PowerShell を使用したデプロイ
次の PowerShell コマンドは、リソース グループを作成し、必要なリソースを含む関数アプリを作成するBicep ファイルまたは ARM テンプレートをデプロイします。 コマンドをローカルで実行するには、 Azure PowerShell がインストールされている必要があります。 Azure にサインインするには、最初に Connect-AzAccountを実行します。
# Register Resource Providers if they're not already registered
Register-AzResourceProvider -ProviderNamespace "microsoft.web"
Register-AzResourceProvider -ProviderNamespace "microsoft.storage"
# Create a resource group for the function app
New-AzResourceGroup -Name "MyResourceGroup" -Location 'West Europe'
# Deploy the template
New-AzResourceGroupDeployment -ResourceGroupName "MyResourceGroup" -TemplateFile main.bicep -Verbose
このデプロイをテストするには、従量課金プランで Windows 上に関数アプリを作成する 、次のようなテンプレート を使用します。
次のステップ
Azure Functionsを開発および構成する方法の詳細について説明します。