Azure Functions の関数アプリのリソース デプロイを自動化
Bicep ファイルまたは Azure Resource Manager (ARM) テンプレートを使用して、関数アプリのデプロイ プロセスを自動化できます。 デプロイ時には、既存の Azure リソースを使用することも、新規に作成することもできます。 自動化は、次のシナリオに役立ちます。
- Azure Pipelines および GitHub Actions ベースのデプロイでリソース デプロイとソース コードを統合する。
- 関数アプリと関連リソースをバックアップから復元する。
- アプリ トポロジを複数回デプロイする。
この記事では、Azure Functions のリソース作成とデプロイを自動化する方法を紹介します。 関数で使用されるトリガーとバインドによっては、他のリソースをデプロイする必要がある場合もありますが、その内容はこの記事では触れていません。
必要なテンプレート コードは、関数アプリに必要なホスティング オプションによって異なります。 この記事では、次のホスティング オプションをサポートしています。
ホスティング オプション | デプロイの種類 | 詳細については、次を参照してください。 |
---|---|---|
Azure Functions 従量課金プラン | コードのみ | 従量課金プラン |
Azure Functions の Flex 従量課金プラン | コードのみ | Flex 従量課金プラン |
Azure Functions の Elastic Premium プラン | コード | コンテナー | Premium プラン |
Azure Functions 専用 (App Service) プラン | コード | コンテナー | 専用プラン |
Azure Container Apps | コンテナーのみ | Azure Functions の Container Apps ホスティング |
Azure Arc | コード | コンテナー | Azure Arc の App Service、Functions、および Logic Apps (プレビュー) |
重要
Flex 従量課金プランは現在、プレビュー段階です。
この記事を使用する際には、以下の考慮事項に留意してください。
ARM テンプレートを構造化する標準的な方法はありません。
Bicep デプロイは、複数の Bicep ファイルにモジュール化できます。
この記事は、Bicep ファイルの作成または Azure Resource Manager テンプレートの作成に関する基本的な理解があることを前提としています。
- 例は、特定のリソースの個々のセクションとして示されています。 完全な Bicep ファイルと ARM テンプレートの幅広い例については、これらの関数アプリのデプロイ例に関する記事を参照してください。
- 例は、特定のリソースの個々のセクションとして示されています。 完全な Bicep ファイルと ARM テンプレートの幅広い例については、これらの Flex 従量課金アプリのデプロイ例に関する記事を参照してください。
- 例は、特定のリソースの個々のセクションとして示されています。
必要なリソース
Azure Functions でホストされているデプロイには、次のリソースを作成または構成する必要があります。
リソース | 要件 | 構文とプロパティの参照 |
---|---|---|
ストレージ アカウント | 必須 | Microsoft.Storage/storageAccounts |
Application Insights コンポーネント | 推奨 | Microsoft.Insights/components* |
ホスティング プラン | 必須 | Microsoft.Web/serverfarms |
関数アプリ | 必須 | Microsoft.Web/sites |
Azure Functions でホストされているデプロイには、次のリソースを作成または構成する必要があります。
リソース | 要件 | 構文とプロパティの参照 |
---|---|---|
ストレージ アカウント | 必須 | Microsoft.Storage/storageAccounts |
Application Insights コンポーネント | 推奨 | Microsoft.Insights/components* |
関数アプリ | 必須 | Microsoft.Web/sites |
Azure Container Apps でホストされているデプロイは通常、次のリソースで構成されています。
リソース | 要件 | 構文とプロパティの参照 |
---|---|---|
ストレージ アカウント | 必須 | Microsoft.Storage/storageAccounts |
Application Insights コンポーネント | 推奨 | Microsoft.Insights/components* |
マネージド環境 | 必須 | Microsoft.App/managedEnvironments |
関数アプリ | 必須 | Microsoft.Web/sites |
Azure Arc でホストされているデプロイは通常、次のリソースで構成されています。
リソース | 要件 | 構文とプロパティの参照 |
---|---|---|
ストレージ アカウント | 必須 | Microsoft.Storage/storageAccounts |
Application Insights コンポーネント | 推奨 | Microsoft.Insights/components1 |
App Service Kubernetes 環境 | 必須 | Microsoft.ExtendedLocation/customLocations |
関数アプリ | 必須 | Microsoft.Web/sites |
*Application Insights インスタンスで使用できる Log Analytics ワークスペースがまだない場合は、このリソースも作成する必要があります。
1 つの Bicep ファイルまたは ARM テンプレートに複数のリソースをデプロイする場合、リソースの作成順序が重要です。 この要件は、リソース間の依存関係の結果です。 このような依存関係では、必ず dependsOn
要素を使用して依存リソースの依存関係を定義してください。 詳細については、「ARM テンプレートでのリソース デプロイ順序の定義」または「Bicep でのリソース依存関係」を参照してください。
前提条件
- 例は、既存のリソース グループのコンテキストで実行するように設計されています。
- Application Insights とストレージ ログの両方で、既存の Azure Log Analytics ワークスペースが必要です。 ワークスペースはサービス間で共有できます。経験則として、パフォーマンスを向上させるために、各地理的リージョンにワークスペースを作成する必要があります。 Log Analytics ワークスペースの作成方法の例については、「Log Analytics ワークスペースを作成する」を参照してください。 完全修飾ワークスペース リソース ID は、Azure portal のワークスペース ページの [設定]>[プロパティ]>[リソース ID] にあります。
- この記事では、Azure Container Apps でマネージド環境を既に作成していることを前提としています。 Container Apps でホストされる関数アプリを作成するには、マネージド環境の名前と ID の両方が必要です。
- この記事では、App Service 対応のカスタムの場所を Azure Arc 対応 Kubernetes クラスター上に既に作成していることを前提としています。 Azure Arc のカスタムの場所でホストされる関数アプリを作成するには、カスタムの場所 ID と Kubernetes 環境 ID の両方が必要です。
ストレージ アカウントの作成
すべての関数アプリに Azure ストレージ アカウントが必要です。 必要なのは BLOB、テーブル、キュー、およびファイルをサポートする汎用アカウントです。 詳細については、Azure Functions ストレージ アカウント要件に関するページをご覧ください。
重要
ストレージ アカウントは、アプリケーション コード自体を含む重要なアプリ データを格納するために使用されます。 他のアプリやユーザーからのアクセスをストレージ アカウントに制限する必要があります。
次の例のセクションでは、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
}
}
詳細な内容については、テンプレート リポジトリの完全な main.bicep ファイルを参照してください。
詳細な内容については、サンプル リポジトリにある完全な storage-account.bicep ファイルを参照してください。
このストレージ アカウントの接続文字列を AzureWebJobsStorage
アプリ設定として設定する必要があります。これは Functions で必要です。 この記事のテンプレートでは、作成したストレージ アカウントに基づいてこの接続文字列の値を作成します。これがベスト プラクティスです。 詳細については、アプリケーションの構成 に関する記事をご覧ください。
デプロイ コンテナー
Flex 従量課金プランで実行されているアプリへのデプロイには、デプロイ ソースとして Azure Blob Storage 内のコンテナーが必要です。 既定のストレージ アカウントを使用することも、別のストレージ アカウントを指定することもできます。 詳しくは、「展開の設定を構成する」を参照してください。
このデプロイ アカウントは、デプロイに使用される特定のコンテナーを含め、アプリを作成するときに既に構成されている必要があります。 デプロイの構成の詳細については、「デプロイ ソース」を参照してください。
この例は、ストレージ アカウントにコンテナーを作成する方法を示しています。
resource blobServices 'blobServices' = if (!empty(containers)) {
name: 'default'
properties: {
deleteRetentionPolicy: deleteRetentionPolicy
}
resource container 'containers' = [for container in containers: {
name: container.name
properties: {
publicAccess: contains(container, 'publicAccess') ? container.publicAccess : 'None'
}
}]
}
コンテキストに応じたスニペットについては、このデプロイ例を参照してください。
その他のデプロイ設定はアプリ自体で構成されます。
ストレージ ログを有効にする
ストレージ アカウントは重要な関数アプリ データに使用されるため、そのコンテンツが変更されているかアカウントを監視する必要があります。 ストレージ アカウントを監視するには、Azure Storage の Azure Monitor リソース ログを構成する必要があります。 この例のセクションでは、myLogAnalytics
という名前の Log Analytics ワークスペースがこれらのログの宛先として使用されています。
resource blobService 'Microsoft.Storage/storageAccounts/blobServices@2021-09-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 リソースに使用できます。 これらのログの操作方法などの詳細については、「Azure ストレージの監視」を参照してください。
Application Insights の作成
関数アプリの実行を監視するために、Application Insights を使用する必要があります。 Application Insights は、共有できる Azure Log Analytics ワークスペースを必要とするようになりました。 これらの例は、既存のワークスペースを使用していて、ワークスペースの完全修飾リソース ID があることを前提としています。 詳細については、Azure Log Analytics ワークスペースに関する記事を参照してください。
次の例のセクションでは、Application Insights リソースは、タイプが Microsoft.Insights/components
、サブタイプが web
で定義されます。
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 従量課金プラン、Premium プラン、または 専用 (App Service) プランでホストされるアプリでは、ホスティング プランを明示的に定義する必要があります。
Flex 従量課金は Linux ベースのホスティング プランで、従量課金の "使用した分だけ支払う" サーバーレス課金モデルに基づいています。 このプランの特徴は、プライベート ネットワーク、インスタンス メモリ サイズの選択のサポートと、マネージド ID のサポート向上です。
Flex 従量課金プランは、特殊なタイプの serverfarm
リソースです。 これは、tier
の値が FlexConsumption
の sku
プロパティで Name
プロパティ値に FC1
を使用することで指定できます。
次の例のセクションでは Flex 従量課金プランを作成します。
resource flexFuncPlan 'Microsoft.Web/serverfarms@2023-12-01' = {
name: planName
location: location
tags: tags
kind: 'functionapp'
sku: {
tier: 'FlexConsumption'
name: 'FC1'
}
properties: {
reserved: true
}
}
詳細な内容については、Flex 従量課金プランのサンプル リポジトリにある完全な function.bicep ファイルを参照してください。
Flex 従量課金プランは現在 Linux のみをサポートしているため、reserved
プロパティを true
に設定する必要もあります。
Premium プランでは、従量課金プランと同じスケーリングが提供されますが、専用リソースとその他の機能が含まれています。 詳細については、「Azure Functions の Premium プラン」を参照してください。
Premium プランは、特殊なタイプの serverfarm
リソースです。 これは、sku
プロパティで Name
プロパティの EP1
、EP2
、EP3
のいずれかの値を使用して指定できます。 Functions ホスティング プランを定義する方法は、関数アプリを Windows 上または Linux 上で実行する場合によって異なります。 次の例のセクションでは EP1
プランを作成します。
resource hostingPlan 'Microsoft.Web/serverfarms@2022-03-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 の専用 VM 上で実行されます。 詳細については、専用プランに関するページを参照してください。
Bicep ファイルおよび Azure Resource Manager テンプレートのサンプルについては、Azure App Service プランの関数アプリに関するページをご覧ください
Functions では、Dedicated プランは、serverfarm
リソースによって定義される通常の App Service プランです。 少なくとも name
個の値を指定する必要があります。 サポートされているプラン名の一覧については、専用プランで現在サポートされている値の一覧で az appservice plan create
の --sku
設定を参照してください。
ホスティング プランを定義する方法は、関数アプリを Windows 上または Linux 上で実行する場合によって異なります。
resource hostingPlanName 'Microsoft.Web/serverfarms@2022-03-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@2022-03-01' = {
name: hostingPlanName
location: location
sku: {
name: 'Y1'
tier: 'Dynamic'
size: 'Y1'
family: 'Y'
capacity: 0
}
properties: {
computeMode: 'Dynamic'
}
}
詳細な内容については、テンプレート リポジトリの完全な main.bicep ファイルを参照してください。
Kubernetes 環境
Azure Functions は、コード プロジェクトまたはコンテナー化された関数アプリとして Azure Arc 対応 Kubernetes にデプロイできます。
アプリを作成し、リソースを計画するには、Azure Arc 対応 Kubernetes クラスター用の App Service Kubernetes 環境 をあらかじめ作成しておく必要があります。 この記事の例では、デプロイ先のカスタムの場所 (customLocationId
) と App Service Kubernetes 環境 (kubeEnvironmentId
) のリソース ID があることを前提としています。これは、次の例の設定です。
param kubeEnvironmentId string
param customLocationId string
サイトとプランの両方で、extendedLocation
フィールドを使用してカスタムの場所を参照する必要があります。 次の抜粋した例で示すように、extendedLocation
は properties
の外側に位置し、kind
と location
のピアになります。
resource hostingPlan 'Microsoft.Web/serverfarms@2022-03-01' = {
...
{
extendedLocation: {
name: customLocationId
}
}
}
プラン リソースは Linux デプロイであるため、SKU
に Kubernetes (K1
) の値を使用し、kind
フィールドは linux,kubernetes
に、reserved
プロパティは true
にする必要があります。 また、extendedLocation
と kubeEnvironmentProfile.id
をそれぞれカスタムの場所 ID と Kubernetes 環境 ID に設定する必要があります。これらは、次の例のセクションのように見えます。
resource hostingPlan 'Microsoft.Web/serverfarms@2022-03-01' = {
name: hostingPlanName
location: location
kind: 'linux,kubernetes'
sku: {
name: 'K1'
tier: 'Kubernetes'
}
extendedLocation: {
name: customLocationId
}
properties: {
kubeEnvironmentProfile: {
id: kubeEnvironmentId
}
reserved: true
}
}
Function App の作成
関数アプリ リソースは、少なくとも functionapp
を含むタイプ Microsoft.Web/sites
とタイプ kind
のリソースによって定義されます。
関数アプリ リソースを定義する方法は、Linux 上または Windows 上でホストする場合によって異なります。
Windows 上で実行する場合に必要なアプリケーション設定の一覧については、「アプリケーションの構成」を参照してください。 Bicep ファイルおよび Azure Resource Manager テンプレートのサンプルについては、「従量課金プランの Windows でホストされる関数アプリ」テンプレートを参照してください。
Windows 上で実行する場合に必要なアプリケーション設定の一覧については、「アプリケーションの構成」を参照してください。
Flex 従量課金は、Bicep および ARM テンプレートのデプロイで使用される標準のアプリケーション設定とサイト構成プロパティの多くを置き換えます。 詳細については、アプリケーションの構成 に関する記事をご覧ください。
resource flexFuncApp 'Microsoft.Web/sites@2023-12-01' = {
name: appName
location: location
tags: tags
kind: 'functionapp,linux'
identity: {
type: 'SystemAssigned'
}
properties: {
serverFarmId: flexFuncPlan.id
siteConfig: {
appSettings: [
{
name: 'AzureWebJobsStorage__accountName'
value: storage.name
}
{
name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
value: appInsights.properties.ConnectionString
}
]
}
functionAppConfig: {
deployment: {
storage: {
type: 'blobContainer'
value: '${storage.properties.primaryEndpoints.blob}${deploymentStorageContainerName}'
authentication: {
type: 'SystemAssignedIdentity'
}
}
}
scaleAndConcurrency: {
maximumInstanceCount: maximumInstanceCount
instanceMemoryMB: instanceMemoryMB
}
runtime: {
name: functionAppRuntime
version: functionAppRuntimeVersion
}
}
}
}
詳細な内容については、Flex 従量課金プランのサンプル リポジトリにある完全な function.bicep ファイルを参照してください。
Note
従量課金プランをオプションで定義することを選択する場合は、アプリで serverFarmId
プロパティを設定して、それがプランのリソース ID を指すようにする必要があります。 同様に、そのプランを参照する dependsOn
設定が関数アプリに含まれていることを確認してください。 明示的にプランを定義していない場合は、ユーザー向けのプランが作成されます。
プランのリソース ID を参照するようにアプリの serverFarmId
プロパティを設定します。 同様に、そのプランを参照する dependsOn
設定が関数アプリに含まれていることを確認してください。
resource functionAppName_resource 'Microsoft.Web/sites@2022-03-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: '~14'
}
]
}
}
}
完全なエンドツーエンドの例については、この main.bicep ファイルを参照してください。
resource functionApp 'Microsoft.Web/sites@2022-03-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: '~14'
}
]
}
}
}
完全なエンドツーエンドの例については、この main.bicep ファイルを参照してください。
デプロイ ソース
Flex 従量課金プランでは、プロジェクト コードは、Blob Storage コンテナーに発行された ZIP 圧縮パッケージからデプロイされます。 詳細については、配置 を参照してください。 デプロイに使用される特定のストレージ アカウントとコンテナー、認証方法、資格情報は、サイトの properties
の functionAppConfig.deployment.storage
要素で設定されます。 コンテナーとアプリケーション設定は、アプリの作成時に存在している必要があります。 ストレージ コンテナーを作成する方法の例については、「デプロイ コンテナー」を参照してください。
この例は、システム割り当てマネージド ID を使用して、指定された Blob Storage コンテナーにアクセスします。これはデプロイ内の別の場所に作成されます。
deployment: {
storage: {
type: 'blobContainer'
value: '${storage.properties.primaryEndpoints.blob}${deploymentStorageContainerName}'
authentication: {
type: 'SystemAssignedIdentity'
}
}
}
マネージド ID を使用する場合は、次の例に示すように、関数アプリが ID を使用してストレージ アカウントにアクセスできるようにする必要もあります。
// Allow access from function app to storage account using a managed identity
resource storageRoleAssignment 'Microsoft.Authorization/roleAssignments@2020-04-01-preview' = {
name: guid(storage.id, storageRoleDefinitionId)
scope: storage
properties: {
roleDefinitionId: resourceId('Microsoft.Authorization/roleDefinitions', storageRoleDefinitionId)
principalId: flexFuncApp.identity.principalId
principalType: 'ServicePrincipal'
}
}
完全な参照用の例については、この Bicep ファイルを参照してください。
マネージド ID ではなく接続文字列を使用している場合は、代わりに authentication.type
を StorageAccountConnectionString
に設定し、authentication.storageAccountConnectionStringName
を、デプロイ ストレージ アカウントの接続文字列が含まれているアプリケーション設定の名前に設定する必要があります。
デプロイ ソース
Bicep ファイルまたは ARM テンプレートは、オプションで、zip 展開パッケージを使用した関数のコードのデプロイを定義することもできます。
Azure Resource Manager を使用して、アプリケーションを適切にデプロイするには、リソースが Azure でどのようにデプロイされているかを理解することが重要です。 ほとんどの例で、最上位レベルの構成は siteConfig
を使用して適用されます。 この構成は、情報を Functions ランタイムとデプロイ エンジンに提供するため、最上位レベルで設定することが重要です。 sourcecontrols/web
子リソースが適用される前に、最上位の情報が必要です。 これらの設定は、子レベルの config/appSettings
リソースで構成できますが、場合によっては、関数アプリを、config/appSettings
が適用される "前" にデプロイする必要があります。
zip 展開パッケージ
zip 展開は、関数アプリのコードをデプロイするために推奨される方法です。 既定では、zip 展開を使用する関数は展開パッケージ自体で実行されます。 展開パッケージの要件などの詳細については、Azure Functions 向け zip 展開を参照してください。 リソースのデプロイの自動化を使用する場合、Bicep テンプレートまたは ARM テンプレートで .zip 展開パッケージを参照できます。
テンプレートで zip 展開を使用するには、アプリの WEBSITE_RUN_FROM_PACKAGE
設定を 1
に設定し、/zipDeploy
リソース定義を含めます。
Linux の従量課金プランでは、このテンプレート例に示すように、WEBSITE_RUN_FROM_PACKAGE
設定で展開パッケージの URI を直接設定します。
次の例では、既存のアプリに 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@2021-02-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 でホストされる関数アプリ」を参照してください。
packageUri
は、Functions でアクセスできる場所である必要があります。 Shared Access Signature (SAS) を使用した Azure Blob Storage の使用を検討してください。 SAS の有効期限が切れると、Functions はデプロイのために共有にアクセスできなくなります。 SAS を再生成する場合は、WEBSITE_RUN_FROM_PACKAGE
設定を新しい URI 値で更新することを忘れないでください。WEBSITE_RUN_FROM_PACKAGE
を URI に設定する場合は、トリガーを手動で同期する必要があります。設定を追加または更新する場合は、常に
appSettings
コレクションに必要なアプリケーション設定をすべて設定してください。 明示的に設定されていない既存の設定は、更新によって削除されます。 詳細については、アプリケーションの構成 に関する記事をご覧ください。Functions はパッケージのデプロイの Web デプロイ (msdeploy) をサポートしていません。 代わりに、デプロイ パイプラインと自動化で zip 展開を使用する必要があります。 詳細については、「Azure Functions の zip デプロイ」を参照してください。
リモート ビルド
展開プロセスでは、使用または zip 展開する .zip ファイルにはすぐに実行できる状態のアプリが含まれるものと想定されています。 つまり、既定では、カスタマイズは実行されません。
アプリをリモートでリビルドする必要があるシナリオがあります。 このような例の 1 つは、Linux 固有のパッケージを Windows コンピューターで開発した Python または Node.js アプリに含める必要がある場合です。 この場合、zip 展開後にコードのリモート構築を実行するように Functions を構成できます。
リモート ビルドを要求する方法は、デプロイ先のオペレーティング システムによって異なります。
Linux コンテナー
コンテナー化された関数アプリを Azure Functions Premium プランまたは専用プランにデプロイする場合、次の手順が必要です。
linuxFxVersion
サイト設定にコンテナー イメージの識別子を設定します。- プライベート レジストリからコンテナーを取得する場合に必要な
DOCKER_REGISTRY_SERVER_*
設定を設定します。 WEBSITES_ENABLE_APP_SERVICE_STORAGE
アプリケーション設定をfalse
に設定します。
一部の設定が見つからない場合は、こちらの HTTP/500 エラーでアプリケーションのプロビジョニングが失敗する可能性があります。
Function app provisioning failed.
詳細については、アプリケーションの構成 に関する記事をご覧ください。
resource functionApp 'Microsoft.Web/sites@2022-03-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: '~14'
}
{
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 を設定します。- サイトと同時に
Microsoft.App/managedEnvironments
リソースを作成する場合、サイトのdependsOn
コレクションにリソース リンクを追加します。
プライベート コンテナー レジストリから既存の Container Apps 環境にデプロイされるコンテナー化関数アプリの定義は、次の例のようになります。
resource functionApp 'Microsoft.Web/sites@2022-03-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
]
}
Azure Arc に関数をデプロイする場合、関数アプリ リソースの kind
フィールドに設定する値は、デプロイのタイプによって異なります。
デプロイの種類 | kind フィールド値 |
---|---|
コードのみのデプロイ | functionapp,linux,kubernetes |
コンテナーのデプロイ | functionapp,linux,kubernetes,container |
ホスティング プラン リソースで行ったように、customLocationId
も設定する必要があります。
.NET 6 クイックスタート イメージを使用してコンテナー化された関数アプリの定義は、次の例のようになります。
resource functionApp 'Microsoft.Web/sites@2022-03-01' = {
name: functionAppName
kind: 'kubernetes,functionapp,linux,container'
location: location
extendedLocation: {
name: customLocationId
}
properties: {
serverFarmId: hostingPlanName
siteConfig: {
linuxFxVersion: 'DOCKER|mcr.microsoft.com/azure-functions/4-dotnet-isolated6.0-appservice-quickstart'
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
}
]
alwaysOn: true
}
}
dependsOn: [
storageAccount
hostingPlan
]
}
アプリケーションの構成
Flex 従量課金プランでは、次の 2 種類のプロパティを使用して Azure 内で関数アプリを構成します。
構成 | Microsoft.Web/sites プロパティ |
---|---|
アプリケーションの構成 | functionAppConfig |
アプリケーションの設定 | siteConfig.appSettings コレクション |
これらのアプリケーション構成は、functionAppConfig
に保持されます。
Behavior | functionAppConfig での設定 |
---|---|
常時使用可能なインスタンス | scaleAndConcurrency.alwaysReady |
デプロイ ソース | deployment |
インスタンス メモリ サイズ | scaleAndConcurrency.instanceMemoryMB |
HTTP トリガーのコンカレンシー | scaleAndConcurrency.triggers.http.perInstanceConcurrency |
言語ランタイム | runtime.name |
Language version (言語バージョン) | runtime.version |
最大インスタンス数 | scaleAndConcurrency.maximumInstanceCount |
Flex 従量課金プランは、次のアプリケーション設定もサポートしています。
- 接続文字列ベースの設定:
- マネージド ID ベースの設定:
Functions には、Azure で関数アプリを構成するための次のようなオプションがあります。
構成 | Microsoft.Web/sites プロパティ |
---|---|
サイトの設定 | siteConfig |
アプリケーションの設定 | siteConfig.appSettings コレクション |
siteConfig
プロパティには、次のサイト設定が必要です。
これらのアプリケーション設定は、特定のオペレーティング システムとホスティング オプションに必須 (または推奨) です。
次のアプリケーション設定は、コンテナーのデプロイに必要です。
次の設定は、プライベート コンテナー レジストリからデプロイする場合にのみ必要です。
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
にも設定します。
この記事の例で実行されているように、アプリケーション設定は常に、作成される
Microsoft.Web/sites
リソースのsiteConfig/appSettings
コレクションとして定義する必要があります。 この定義により、関数アプリの実行に必要な設定が初期起動時に利用できるようになります。テンプレートを使用してアプリケーション設定を追加または更新する場合は、既存のすべての設定を更新に含めるようにしてください。 基礎となる更新 REST API 呼び出しは
/config/appsettings
リソース全体を置き換えるため、これを行う必要があります。 既存の設定を削除すると、関数アプリは実行されません。 個々のアプリケーション設定をプログラムを使用して更新するには、代わりに Azure CLI、Azure PowerShell、Azure portal を使用してこれらを変更できます。 詳細については、アプリケーション設定の操作に関する記事を参照してください。
スロットのデプロイ
Functions を使用すると、異なるバージョンのコードを関数アプリ内の固有のエンドポイントにデプロイできます。 このオプションにより、運用環境で実行中の関数に影響を与えることなく、関数の更新の開発、検証、デプロイが簡略化されます。 デプロイ スロットは、Azure App Service の機能です。 使用できるスロットの数は、ホスティング プランによって異なります。 詳細については、「Azure Functions のデプロイ スロット」関数を参照してください。
スロット リソースは関数アプリ リソース (Microsoft.Web/sites
) と同じように定義しますが、代わりに Microsoft.Web/sites/slots
リソース識別子を使用します。 Premium プランに運用環境スロットとステージング スロットの両方を作成するデプロイの例 (Bicep と ARM のテンプレートの両方) については、「デプロイ スロットを使用した Azure Function App」を参照してください。
テンプレートを使用してスロットをスワップする方法については、「Resource Manager テンプレートで自動化する」を参照してください。
スロットのデプロイをを行う場合は、次の考慮事項に留意してください。
デプロイ スロットの定義で
WEBSITE_CONTENTSHARE
設定を明示的に設定しないでください。 この設定は、アプリがデプロイ スロットで作成されると自動的に生成されます。スロットを入れ替えると、いくつかのアプリケーション設定は "粘着性" とみなされ、入れ替えるコードではなくスロットに保持されます。 このような "スロット設定" は、テンプレートの特定のアプリケーション設定定義に
"slotSetting":true
を含めることで定義できます。 詳細については、設定の管理に関するページを参照してください。
セキュリティで保護された展開
仮想ネットワークと統合することで、1 つ以上のリソースがセキュリティ保護されたデプロイで関数アプリを作成できます。 関数アプリの仮想ネットワーク統合は、Microsoft.Web/sites/networkConfig
リソースで定義されます。 この統合は、参照される関数アプリと仮想ネットワーク リソースの両方に依存します。 お使いの関数アプリが、プライベート エンドポイントやルートなど、他のプライベート ネットワーク リソースに依存する場合もあります。 詳細については、「Azure Functions のネットワーク オプション」をご覧ください。
これらのプロジェクトは、ネットワーク アクセス制限などの仮想ネットワークで関数アプリをデプロイする方法に関する Bicep ベースの例を提供しています。
- 高スケールの HTTP によってトリガーされる関数は、仮想ネットワークによってセキュリティ保護されたイベント ハブに接続する: HTTP によってトリガーされる関数 (.NET 分離ワーカー モード) は、任意のソースからの呼び出しを受け入れ、仮想ネットワーク統合を使用して、仮想ネットワークで実行されているセキュリティで保護されたイベント ハブにそれらの HTTP 呼び出しの本文を送信します。
- 関数は、仮想ネットワークでセキュリティ保護された Service Bus キューによってトリガーされる: Python 関数は、仮想ネットワークでセキュリティ保護された Service Bus キューによってトリガーされます。 キューは、仮想ネットワーク内でプライベート エンドポイントを使用してアクセスされます。 仮想ネットワーク内の仮想マシンは、メッセージを送信するために使用されます。
セキュリティ保護されたストレージ アカウントを使用するデプロイを作成するとき、WEBSITE_CONTENTSHARE
設定を明示的に設定し、かつ、この設定で指定されたファイル共有リソースを作成する必要があります。 この例 (ARM テンプレート|Bicep ファイル) で示すように、必ず WEBSITE_CONTENTSHARE
の値を使用して Microsoft.Storage/storageAccounts/fileServices/shares
リソースを作成します。 また、サイト プロパティ vnetContentShareEnabled
を true に設定する必要があります。
Note
これらの設定が、セキュリティで保護されたストレージ アカウントを使用するデプロイに含まれていない場合は、デプロイの検証中に次のエラーが表示されます: Could not access storage account using provided connection string
。
これらのプロジェクトは、ネットワーク アクセス制限などの仮想ネットワークで関数アプリをデプロイする方法の Bicep と ARM の両方のテンプレートを例示しています。
制限付きシナリオ | 説明 |
---|---|
仮想ネットワーク統合を使用した関数アプリの作成 | 関数アプリは仮想ネットワーク内に作成され、そのネットワーク内のリソースにフル アクセスできます。 関数アプリの受信アクセスや送信アクセスは制限されません。 詳細については、仮想ネットワーク統合に関する記事を参照してください。 |
セキュリティで保護されたストレージ アカウントにアクセスする関数アプリの作成 | 作成した関数アプリは、セキュリティで保護されたストレージ アカウントを使用します。これは、プライベート エンドポイントを使用して Functions でアクセスします。 詳細については、「ストレージ アカウントを仮想ネットワークに制限する」を参照してください。 |
いずれもプライベート エンドポイントを使用する関数アプリとストレージ アカウントの作成 | 作成した関数アプリは、プライベート エンドポイントを使用することでのみアクセスでき、プライベート エンドポイントを使用してストレージ リソースにアクセスします。 詳細については、プライベート エンドポイントに関する記事を参照してください。 |
制限付きネットワーク設定
関数アプリにネットワーク制限がある場合にも、次のような設定が必要になる場合があります。
設定 | 値 | 説明 |
---|---|---|
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
プロパティを設定しない場合、リソースの作成時に関数によって新しいキーが自動的に生成されます。これは推奨されます。 アクセス キーの操作に関するセキュリティのベスト プラクティスなど、アクセス キーの詳細については、「Azure Functions でのアクセス キーの操作」を参照してください。
テンプレートを作成する
Bicep または ARM のテンプレートを持つ専門家は、シンプルなテキスト エディターを使用してデプロイを手動でコード化できます。 それ以外の人には、次のように開発プロセスを簡略化する方法があります。
Visual Studio Code: Bicep ファイルと ARM テンプレートの両方で作業するのに役立つ拡張機能を利用できます。 これらのツールを使用することで、コードが正しいかどうかを確認することができ、基本検証を行うことができます。
Azure portal: ポータルで関数アプリと関連リソースを作成する場合、最後の [確認と作成] 画面には、[オートメーション用のテンプレートをダウンロードする] リンクがあります。
このリンクには、ポータルで選択したオプションに基づいて生成された 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 ファイルおよびテンプレートをデプロイできます。
[Azure にデプロイ] ボタン
注意
この方法では、現在 Bicep ファイルのデプロイはサポートされていません。
<url-encoded-path-to-azuredeploy-json>
を、GitHub の azuredeploy.json
ファイルの生のパスのエンコードされた URL で置き換えます。
マークダウンを使用する例を次に示します。
[![Deploy to Azure](https://azuredeploy.net/deploybutton.png)](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 がインストールされている必要があります。 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 を開発および構成する方法について学習します。