App Service でローカル共有として Azure Storage をマウントする

  • [アーティクル]

Azure Storage は、最新のデータ ストレージ シナリオ用の Microsoft のクラウド ストレージ ソリューションです。 Azure Storage は、クラウド内のさまざまなデータ オブジェクトに対して、可用性が高く、スケーラビリティ、持続性、安全性に優れたストレージを提供します。 このガイドでは、App Service で Azure Storage ファイルをネットワーク共有として Windows コード (コンテナー以外) にマウントする方法について説明します。 Azure Files Shares および Premium ファイル共有のみがサポートされています。 Azure Storage は、App Service の既定外のストレージであり、個別に課金されます。 ARM テンプレートで Azure Storage を構成することもできます。

カスタムマウント ストレージの利点は次のとおりです。

  • App Service アプリの永続ストレージを構成し、ストレージを個別に管理します。
  • 動画や画像などの静的なコンテンツが App Service アプリですぐに利用できるようになります。
  • Azure ファイル共有に対して、アプリケーション ログ ファイルを書き込むか、古いアプリケーション ログをアーカイブします。
  • 複数のアプリ間または他の Azure サービスとの間でコンテンツを共有します。

Windows コードでは、次の機能がサポートされています。

  • キー コンテナー、プライベート エンドポイント、サービス エンドポイントを使用したストレージ アカウントへのセキュリティで保護されたアクセス (VNET 統合を使用する場合)。
  • Azure Files (読み取り/書き込み)。
  • アプリあたり最大 5 つのマウント ポイント。
  • "/mounts/<path-name>" を使用して Azure Storage ファイル共有をマウントします。

Azure Storage をアプリにマウントするには、次の 3 つのオプションがあります。

マウント オプション 使用方法
基本 Azure portal を使用してストレージをマウントする場合は、このオプションを選択します。 ストレージ アカウントでサービス エンドポイント、プライベート エンドポイント、または Azure Key Vault を使用していない限り、基本オプションを使用できます。 この場合は、ポータルによって自動的にアクセス キーが取得および保存されます。
Access Key Azure CLI を使用してストレージをマウントする予定の場合は、ユーザーがアクセス キーを取得する必要があります。 ストレージ アカウントでサービス エンドポイント、プライベート エンドポイント、または Azure Key Vault を使用していない場合は、このオプションを選択します。
Key Vault また、Azure CLI を使用してストレージをマウントする予定の場合 (アクセス キーが必要) も、このオプションを使用します。 Azure Key Vault を使用してアクセス キーを安全に保存および取得する場合は、このオプションを選択します。 Azure Key Vault には、Azure App Service などの他の Azure サービスを監視、管理、統合する機能により、アプリケーション シークレットを一元的かつ安全に保存する利点があります。

前提条件

制限事項

  • ストレージのファイアウォールは、プライベート エンドポイントとサービス エンドポイントを介してのみサポートされます (VNET 統合が使用されている場合)。
  • App Service にデプロイされた Windows コード アプリの Azure ストレージ マウントを構成する場合、Azure BLOB はサポートされていません。
  • マウントされたストレージへの FTP/FTPS アクセスはサポートされていません (Azure Storage Explorer を使用してください)。
  • カスタムマウント ストレージへの /mounts、mounts/foo/bar、/、/mounts/foo.bar/ のマッピングはサポートされていません (カスタム ストレージの Web アプリへのマウントには、/mounts/pathname のみを使用できます。)
  • ストレージ マウントはバックアップに含まれません。 必ずベスト プラクティスに従って Azure Storage アカウントをバックアップしてください。
  • アプリで VNET 統合を使用すると、マウントされたドライブは、VNET からの IP アドレスではなく RFC1918 IP アドレスを使用します。

マウントの準備

ポータルによってアクセス キーが取得および保存されるため、追加の手順は必要ありません。

ストレージを Windows コードにマウントする

  1. Azure portal でアプリに移動します。

  2. 左側のナビゲーションで、[構成]>[Path Mappings]\(パス マッピング\)>[新しい Azure Storage マウント] をクリックします。

  3. 次の表に従って、ストレージのマウントを構成します。 完了したら、 [OK] をクリックします。

    設定 内容
    名前 マウント構成の名前。 スペースは使用できません。
    構成オプション ストレージ アカウントでプライベート エンドポイントまたは Azure Key Vault を使用していない場合は、[基本] を選択します。 それ以外の場合は、 [詳細] を選択します。
    ストレージ アカウント Azure ストレージ アカウント。 Azure Files 共有が含まれている必要があります。
    共有名 マウントするファイル共有。
    ストレージ アクセス Azure Key Vault の場合は、[キー コンテナーの参照] を選択します。 それ以外の場合は、[Manual input](手動入力) を選択します。
    アクセス キー (詳細のみ) ストレージ アカウントのアクセス キー。
    マウント パス マウントするアプリ サービス内のディレクトリ。 サポートされるのは /mounts/pathname のみです。
    アプリケーションの設定 Azure Key Vault シークレットで構成されているアプリ設定を選択します。
    デプロイ スロットの設定 オンにすると、ストレージ マウント設定がデプロイ スロットにも適用されます。

Note

ストレージのマウントを追加、編集、または削除すると、アプリが再起動されます。

ベスト プラクティス

  • Azure Storage マウントは、静的コンテンツを提供する仮想ディレクトリとして構成できます。 仮想ディレクトリを構成するには、左側のナビゲーションで [構成]>[パスのマッピング]>[新しい仮想アプリケーションまたはディレクトリ] をクリックします。 [物理パス] を、Azure Storage マウントで定義されている マウント パス に設定します。

  • 待機時間の問題を回避するには、アプリと Azure Storage アカウントを同じリージョンに配置します。 アプリと Azure Storage アカウントが同じリージョンにある場合に App Service IP アドレスからのアクセスを Azure Storage ファイアウォール構成で許可しても、それらの IP 制限は適用されません。

  • Azure Storage アカウントでは、アプリでストレージのマウントに使用されるアクセス キーの再生成を行わないようにしてください。 ストレージ アカウントには、2 つの異なるキーが含まれています。 Azure App Services によって Azure Storage アカウント キーが格納されます。 キーの再生成中にストレージのマウントをアプリで引き続き使用できるようにするには、段階的なアプローチを使用します。 たとえば、key1 を使用して、アプリでストレージのマウントを構成したとします。

    1. key2 を再生成します。
    2. ストレージのマウント構成で、再生成された key2 を使用するアクセス キーを更新します。
    3. key1 を再生成します。

  • Azure Storage のアカウント、コンテナー、または共有を削除する場合は、可能性があるエラー シナリオを回避するために、対応するストレージのマウント構成をアプリから削除します。

  • マウントされた Azure Storage アカウントは、Standard または Premium パフォーマンス レベルのいずれかになります。 アプリの容量とスループットの要件に基づいて、ストレージ アカウントに適したパフォーマンス レベルを選択します。 「ファイルのスケーラビリティおよびパフォーマンス目標」をご覧ください。

  • アプリが複数のインスタンスにスケーリングされる場合、マウントされている同じ Azure Storage アカウントにすべてのインスタンスが接続します。 パフォーマンス ボトルネックとスループットの問題を回避するには、ストレージ アカウントに対して適切なパフォーマンス レベルを選択します。

  • ローカル データベース (SQLite など) に対して、またはファイル ハンドルやロックに依存するその他のアプリケーションやコンポーネントに対してストレージ マウントを使用することはお勧めしません。

  • ストレージ アカウントがアプリにマウントされている時にストレージ フェールオーバーを開始した場合、アプリが再起動されるか、ストレージ マウントが削除されて再追加されるまで、マウントは接続されません。

  • VNET 統合を使用する場合は、アプリ設定で WEBSITE_CONTENTOVERVNET が 1 に設定されていて、次のポートが開いていることを確認してください。

    • Azure Files: 80 と 445

  • マウントされた Azure Storage アカウントは、Standard または Premium パフォーマンス レベルのいずれかになります。 アプリの容量とスループットの要件に基づいて、ストレージ アカウントに適したパフォーマンス レベルを選択します。 「ファイルのスケーラビリティおよびパフォーマンス目標」を参照してください

次のステップ

Azure Storage は、最新のデータ ストレージ シナリオ用の Microsoft のクラウド ストレージ ソリューションです。 Azure Storage は、クラウド内のさまざまなデータ オブジェクトに対して、可用性が高く、スケーラビリティ、持続性、安全性に優れたストレージを提供します。 このガイドでは、App Service で Azure Storage ファイルをネットワーク共有として Windows コンテナーにマウントする方法について説明します。 Azure Files Shares および Premium ファイル共有のみがサポートされています。 Azure Storage は、App Service の既定外のストレージであり、個別に課金されます。 ARM テンプレートで Azure Storage を構成することもできます。

カスタムマウント ストレージの利点は次のとおりです。

  • App Service アプリの永続ストレージを構成し、ストレージを個別に管理します。
  • 動画や画像などの静的なコンテンツが App Service アプリですぐに利用できるようになります。
  • Azure ファイル共有に対して、アプリケーション ログ ファイルを書き込むか、古いアプリケーション ログをアーカイブします。
  • 複数のアプリ間または他の Azure サービスとの間でコンテンツを共有します。
  • Isolated (App Service 環境 v3) を含む、Windows コンテナーの Azure Storage をマウントします。

Windows コンテナーでは、次の機能がサポートされています。

Azure Storage をアプリにマウントするには、次の 3 つのオプションがあります。

マウント オプション 使用方法
基本 Azure portal を使用してストレージをマウントする場合は、このオプションを選択します。 ストレージ アカウントでサービス エンドポイント、プライベート エンドポイント、または Azure Key Vault を使用していない限り、基本オプションを使用できます。 この場合は、ポータルによって自動的にアクセス キーが取得および保存されます。
Access Key Azure CLI を使用してストレージをマウントする予定の場合は、ユーザーがアクセス キーを取得する必要があります。 ストレージ アカウントでサービス エンドポイント、プライベート エンドポイント、または Azure Key Vault を使用していない場合は、このオプションを選択します。
Key Vault また、Azure CLI を使用してストレージをマウントする予定の場合 (アクセス キーが必要) も、このオプションを使用します。 Azure Key Vault を使用してアクセス キーを安全に保存および取得する場合は、このオプションを選択します。 Azure Key Vault には、Azure App Service などの他の Azure サービスを監視、管理、統合する機能により、アプリケーション シークレットを一元的かつ安全に保存する利点があります。

前提条件

制限事項

  • Azure BLOB はサポートされていません。
  • ストレージのファイアウォールは、プライベート エンドポイントとサービス エンドポイントを介してのみサポートされます (VNET 統合が使用されている場合)。
  • マウントされたストレージへの FTP/FTPS アクセスはサポートされていません (Azure Storage Explorer を使用してください)。
  • カスタム マウント ストレージへの [C-Z]:\、[C-Z]:\home、/、/home のマッピングはサポートされていません。
  • アプリをバックアップする際に、ストレージ マウントはバックアップされません。 必ずベスト プラクティスに従って Azure Storage アカウントをバックアップしてください。
  • アプリで VNET 統合を使用すると、マウントされたドライブは、VNET からの IP アドレスではなく RFC1918 IP アドレスを使用します。

マウントの準備

ポータルによってアクセス キーが取得および保存されるため、追加の手順は必要ありません。

ストレージを Windows コンテナーにマウントする

  1. Azure portal でアプリに移動します。

  2. 左側のナビゲーションで、[構成]>[Path Mappings]\(パス マッピング\)>[新しい Azure Storage マウント] をクリックします。

  3. 次の表に従って、ストレージのマウントを構成します。 完了したら、 [OK] をクリックします。

    設定 内容
    名前 マウント構成の名前。 スペースは使用できません。
    構成オプション [Basic] を選択します
    ストレージ アカウント Azure ストレージ アカウント。 Azure Files 共有が含まれている必要があります。
    共有名 マウントするファイル共有。
    マウント パス マウントするアプリ サービス内のディレクトリ。 ルート ディレクトリ ([C-Z]:\ や /) または home ディレクトリ ([C-Z]:\home や /home) はサポートされていないため使用しないでください。
    デプロイ スロットの設定 オンにすると、ストレージ マウント設定がデプロイ スロットにも適用されます。

Note

ストレージのマウントを追加、編集、または削除すると、アプリが再起動されます。

ベスト プラクティス

  • 待機時間の問題を回避するには、アプリと Azure Storage アカウントを同じリージョンに配置します。 アプリと Azure Storage アカウントが同じリージョンにある場合に App Service IP アドレスからのアクセスを Azure Storage ファイアウォール構成で許可しても、それらの IP 制限は適用されません。

  • Azure Storage アカウントでは、アプリでストレージのマウントに使用されるアクセス キーの再生成を行わないようにしてください。 ストレージ アカウントには、2 つの異なるキーが含まれています。 Azure App Services によって Azure Storage アカウント キーが格納されます。 キーの再生成中にストレージのマウントをアプリで引き続き使用できるようにするには、段階的なアプローチを使用します。 たとえば、key1 を使用して、アプリでストレージのマウントを構成したとします。

    1. key2 を再生成します。
    2. ストレージのマウント構成で、再生成された key2 を使用するアクセス キーを更新します。
    3. key1 を再生成します。

  • Azure Storage のアカウント、コンテナー、または共有を削除する場合は、可能性があるエラー シナリオを回避するために、対応するストレージのマウント構成をアプリから削除します。

  • マウントされた Azure Storage アカウントは、Standard または Premium パフォーマンス レベルのいずれかになります。 アプリの容量とスループットの要件に基づいて、ストレージ アカウントに適したパフォーマンス レベルを選択します。 「ファイルのスケーラビリティおよびパフォーマンス目標」をご覧ください。

  • アプリが複数のインスタンスにスケーリングされる場合、マウントされている同じ Azure Storage アカウントにすべてのインスタンスが接続します。 パフォーマンス ボトルネックとスループットの問題を回避するには、ストレージ アカウントに対して適切なパフォーマンス レベルを選択します。

  • ローカル データベース (SQLite など) に対して、またはファイル ハンドルやロックに依存するその他のアプリケーションやコンポーネントに対してストレージ マウントを使用することはお勧めしません。

  • Azure Files を VNET 統合で使う場合、ポート 80 と 445 が開いていることを確認します。

  • ストレージ アカウントがアプリにマウントされている時にストレージ フェールオーバーを開始した場合、アプリが再起動されるか、ストレージ マウントが削除されて再追加されるまで、マウントは接続されません。

次の手順

Note

App Service on Linux に対して NFS がサポートされるようになりました。

このガイドでは、App Service の組み込み Linux コンテナーまたはカスタム Linux コンテナーに、ネットワーク共有として Azure Storage をマウントする方法について説明します。 Azure Storage は、最新のデータ ストレージ シナリオ用の Microsoft のクラウド ストレージ ソリューションです。 Azure Storage は、クラウド内のさまざまなデータ オブジェクトに対して、可用性が高く、スケーラビリティ、持続性、安全性に優れたストレージを提供します。 Azure Storage は、App Service の既定外のストレージであり、個別に課金されます。 ARM テンプレートで Azure Storage を構成することもできます。

メリット

カスタムマウント ストレージの利点は次のとおりです。

  • App Service アプリの永続ストレージを構成し、ストレージを個別に管理します。
  • 動画や画像などの静的なコンテンツが App Service アプリですぐに利用できるようになります。
  • Azure ファイル共有に対して、アプリケーション ログ ファイルを書き込むか、古いアプリケーション ログをアーカイブします。
  • 複数のアプリ間または他の Azure サービスとの間でコンテンツを共有します。
  • Azure Files NFS と Azure Files SMB がサポートされます。
  • Azure BLOB (読み取り専用) がサポートされます。
  • アプリあたり最大 5 つのマウント ポイントがサポートされます。

制限事項

カスタム マウント ストレージの制限事項は次のとおりです。

  • ストレージのファイアウォールは、サービス エンドポイントとプライベート エンドポイントを介してのみサポートされます (VNET 統合が使用されている場合)。
  • カスタムマウント ストレージへの FTP/FTPS アクセスはサポートされていません (Azure Storage Explorer を使用してください)。
  • ストレージ アカウントの共有アクセス キーが、サポートされる唯一の認証手段です。Entra ID と RBAC ロールはサポートされません。
  • Azure CLI、Azure PowerShell、Azure SDK のサポートはプレビュー段階です。
  • カスタムマウント ストレージへの / または /home のマッピングはサポートされていません。
  • アプリの起動中のタイムアウトの原因となる可能性があるため、ストレージ マウントを /tmp またはそのサブディレクトリにマップしないでください。
  • Azure Storage は Docker Compose のシナリオではサポートされていません。
  • ストレージ マウントはバックアップに含まれません。 必ずベスト プラクティスに従って Azure Storage アカウントをバックアップしてください。
  • NFS がサポートされるのは、App Service on Linux に対してのみです。 NFS は、Windows コードと Windows コンテナーに対してはサポートされません。 Web アプリとストレージ アカウントは、NFS 用の同じ VNET で構成する必要があります。 ファイル共有に使用されるストレージ アカウントには、アカウントの種類として "Premium" パフォーマンス レベルと "Filestorage" を指定する必要があります。 NFS プロトコルを使用するときは、Azure Key Vault が適用されません。
  • アプリで VNET 統合を使用すると、マウントされたドライブは、VNET からの IP アドレスではなく RFC1918 IP アドレスを使用します。

マウント オプション

まず、ストレージをアプリにマウントする必要があります。 Azure Storage の 3 つのマウント オプションを次に示します。

マウント オプション 使用方法
基本 Azure portal を使用してストレージをマウントする場合は、このオプションを選択します。 ストレージ アカウントでサービス エンドポイント、プライベート エンドポイント、または Azure Key Vault を使用していない限り、基本オプションを使用できます。 この場合は、ポータルによって自動的にアクセス キーが取得および保存されます。
Access Key Azure CLI を使用してストレージをマウントする予定の場合は、ユーザーがアクセス キーを取得する必要があります。 ストレージ アカウントでサービス エンドポイント、プライベート エンドポイント、または Azure Key Vault を使用していない場合は、このオプションを選択します。
Key Vault また、Azure CLI を使用してストレージをマウントする予定の場合 (アクセス キーが必要) も、このオプションを使用します。 Azure Key Vault を使用してアクセス キーを安全に保存および取得する場合は、このオプションを選択します。 Azure Key Vault には、Azure App Service などの他の Azure サービスを監視、管理、統合する機能により、アプリケーション シークレットを一元的かつ安全に保存する利点があります。

前提条件

マウントの準備

ポータルによってアクセス キーが取得および保存されるため、追加の手順は必要ありません。

ストレージを Linux コンテナーにマウントする

ストレージをマウントする方法は、使用するストレージ アクセス オプションと、ポータルまたは Azure CLI のどちらを使用するかによって異なります。

  1. Azure portal でアプリに移動します。

  2. 左側のナビゲーションで、[構成]>[Path Mappings]\(パス マッピング\)>[新しい Azure Storage マウント] をクリックします。

  3. 次の表に従って、ストレージのマウントを構成します。 完了したら、 [OK] をクリックします。

    設定 内容
    名前 マウント構成の名前。 スペースは使用できません。
    構成オプション [Basic] を選択します。 ストレージ アカウントでサービス エンドポイント、プライベート エンドポイント、または Azure Key Vault を使用していない場合。 それ以外の場合は、 [詳細] を選択します。
    ストレージ アカウント Azure ストレージ アカウント。
    ストレージの種類 マウントするストレージに基づいて種類を選択します。 Azure BLOB では、読み取り専用アクセスのみがサポートされています。
    ストレージ コンテナーまたは 共有名 マウントするファイル共有または BLOB コンテナー。
    マウント パス Azure Storage にマウントする、Linux コンテナー内のディレクトリ。 / も /home も使用しないでください。
    デプロイ スロットの設定 オンにすると、ストレージ マウント設定がデプロイ スロットにも適用されます。

Note

ストレージのマウントを追加、編集、または削除すると、アプリが再起動されます。

マウントされたストレージを検証する

Azure Storage がアプリに対して正常にマウントされたことを検証するには、次のようにします。

  1. コンテナーに対して SSH セッションを開きます。

  2. SSH ターミナルで、次のコマンドを実行します。

    df –h

  3. ストレージ共有がマウントされているかどうか確認します。 存在しない場合、ストレージ共有のマウントに問題があります。

  4. 次のコマンドを使用して、ストレージのマウントの待機時間または一般的な到達可能性を確認します。

    tcpping Storageaccount.file.core.windows.net

ベスト プラクティス

パフォーマンス

  • 待機時間の問題を回避するには、アプリと Azure Storage アカウントを同じリージョンに配置します。 アプリと Azure Storage アカウントが同じリージョンにある場合に App Service IP アドレスからのアクセスを Azure Storage ファイアウォール構成で許可しても、それらの IP 制限は適用されません。

  • マウントされた Azure Storage アカウントは、Standard または Premium パフォーマンス レベルのいずれかになります。 アプリの容量とスループットの要件に基づいて、ストレージ アカウントに適したパフォーマンス レベルを選択します。 ストレージの種類 (ファイルと BLOB) に対応するスケーラビリティとパフォーマンスの目標を確認してください。

  • アプリが複数のインスタンスにスケーリングされる場合、マウントされている同じ Azure Storage アカウントにすべてのインスタンスが接続します。 パフォーマンス ボトルネックとスループットの問題を回避するには、ストレージ アカウントに対して適切なパフォーマンス レベルを選択します。

セキュリティ

  • Azure Storage アカウントでは、アプリでストレージのマウントに使用されるアクセス キーの再生成を行わないようにしてください。 ストレージ アカウントには、2 つの異なるキーが含まれています。 Azure App Services によって Azure Storage アカウント キーが格納されます。 キーの再生成中にストレージのマウントをアプリで引き続き使用できるようにするには、段階的なアプローチを使用します。 たとえば、key1 を使用して、アプリでストレージのマウントを構成したとします。
    1. key2 を再生成します。
    2. ストレージのマウント構成で、再生成された key2 を使用するアクセス キーを更新します。
    3. key1 を再生成します。

トラブルシューティング

  • カスタム コンテナーのマウント ディレクトリは空である必要があります。 このパスに格納されている内容は、Azure Storage がマウントされると削除されます (たとえば、/home の下のディレクトリを指定した場合)。 既存アプリのファイルを移行する場合は、始める前に、アプリとその内容をバックアップしてください。
  • Azure Storage のアカウント、コンテナー、または共有を削除する場合は、可能性があるエラー シナリオを回避するために、対応するストレージのマウント構成をアプリから削除します。
  • ローカル データベース (SQLite など) に対して、またはファイル ハンドルやロックに依存するその他のアプリケーションやコンポーネントに対してストレージ マウントを使用することはお勧めしません。
  • VNET 統合を使うときは、次のポートが開いていることを確認してください。Azure Files: 80 と 445。 Azure BLOB: 80 と 443。
  • ストレージ アカウントがアプリにマウントされている時にストレージ フェールオーバーを開始すると、アプリが再起動されるか、ストレージ マウントが削除されて再追加されるまで、マウントが接続されません。

次のステップ