次の方法で共有

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 (プレビュー)

この記事を使用する際には、以下の考慮事項に留意してください。

  • 例は、特定のリソースの個々のセクションとして示されています。 完全な 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 の両方が必要です。

ストレージ アカウントの作成

すべての関数アプリに 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 ファイルを参照してください。

デプロイ ソース

linuxFxVersion サイト設定を使用すると、特定の Linux コンテナーが作成時にアプリにデプロイされることを要求できます。 プライベート リポジトリ内のイメージにアクセスするには、さらに設定が必要です。 詳細については、アプリケーションの構成 に関する記事をご覧ください。

重要

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

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

Bicep ファイルまたは ARM テンプレートは、オプションで、次のメソッドを含む関数のコードのデプロイを定義することもできます。

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 展開リソースを含める場合は、次の点に注意してください。

  • 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 を構成できます。

リモート ビルドを要求する方法は、デプロイ先のオペレーティング システムによって異なります。

アプリが Windows にデプロイされると、言語固有のコマンド (C# アプリの場合は dotnet restore、Node.js アプリの場合は npm install など) が実行されます。

継続的インテグレーションで取得するものと同じビルド プロセスを有効にするには、アプリケーションの設定に SCM_DO_BUILD_DURING_DEPLOYMENT=true を追加し、WEBSITE_RUN_FROM_PACKAGE を完全に削除します。

Linux コンテナー

コンテナー化された関数アプリを Azure Functions Premium プランまたは専用プランにデプロイする場合、次の手順が必要です。

一部の設定が見つからない場合は、こちらの 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 従量課金プランは、次のアプリケーション設定もサポートしています。

Functions には、Azure で関数アプリを構成するための次のようなオプションがあります。

構成 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 にも設定します。

  • この記事の例で実行されているように、アプリケーション設定は常に、作成される 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 ベースの例を提供しています。

セキュリティ保護されたストレージ アカウントを使用するデプロイを作成するとき、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: ポータルで関数アプリと関連リソースを作成する場合、最後の [確認と作成] 画面には、[オートメーション用のテンプレートをダウンロードする] リンクがあります。

    Azure portal の Azure Functions 作成プロセスからテンプレート リンクをダウンロードします。

    このリンクには、ポータルで選択したオプションに基づいて生成された 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 を開発および構成する方法について学習します。