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

注意

Windows コードで App Service のローカル共有として Azure Storage をマウントする機能は現在プレビュー段階です。

このガイドでは、App Service で Azure Storage ファイルをネットワーク共有として Windows コードにマウントする方法について説明します。 Azure Files Shares および Premium ファイル共有のみがサポートされています。 カスタムマウント ストレージの利点は次のとおりです。

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

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

このガイドでは、App Service で Azure Storage ファイルをネットワーク共有として Windows コンテナーにマウントする方法について説明します。 Azure Files Shares および Premium ファイル共有のみがサポートされています。 カスタムマウント ストレージの利点は次のとおりです。

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

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

このガイドでは、App Service の組み込み Linux コンテナーまたはカスタム Linux コンテナーに、ネットワーク共有として Azure Storage をマウントする方法について説明します。 動画「ローカル共有として Azure Storage をマウントする方法」をご覧ください。 カスタムマウント ストレージの利点は次のとおりです。

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

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

前提条件

Note

Azure Storage は、App Service の既定以外のストレージです。別途請求され、App Service には含まれません。

制限事項

  • ストレージのファイアウォールは、プライベート エンドポイントサービス エンドポイントを介してのみサポートされます (VNET 統合が使用されている場合)。
  • App Service にデプロイされた Windows コード アプリの Azure ストレージ マウントを構成する場合、Azure BLOB はサポートされません。
  • マウントされたストレージへの FTP/FTPS アクセスはサポートされていません (Azure Storage Explorer を使用してください)。
  • カスタムマウント ストレージへの /mountsmounts/foo/bar/ および /mounts/foo.bar/ のマッピングはサポートされていません (カスタム ストレージを Web アプリにマウントする場合、/mounts/pathname のみ使用できます)。
  • デプロイ スロットの作成中に、ストレージのマウントを複製設定オプションと共に使用することはできません。
  • ストレージのマウントは、アプリをバックアップするときにバックアップされません。 必ずベスト プラクティスに従って Azure Storage アカウントをバックアップしてください。
  • ストレージのマウントは、ネイティブの Windows アプリ (コンテナー化されていない) ではサポートされていません。
  • Azure Blob はサポートされていません。
  • ストレージのファイアウォールは、プライベート エンドポイントサービス エンドポイントを介してのみサポートされます (VNET 統合が使用されている場合)。
  • マウントされたストレージへの FTP/FTPS アクセスはサポートされていません (Azure Storage Explorer を使用してください)。
  • カスタム マウント ストレージへの [C-Z]:\[C-Z]:\home//home のマッピングはサポートされていません。
  • デプロイ スロットの作成中に、ストレージのマウントを複製設定オプションと共に使用することはできません。
  • ストレージのマウントは、アプリをバックアップするときにバックアップされません。 必ずベスト プラクティスに従って Azure Storage アカウントをバックアップしてください。

注意

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

  • ストレージのファイアウォールは、サービス エンドポイントプライベート エンドポイントを介してのみサポートされます (VNET 統合が使用されている場合)。 現在、マウントされた Azure Storage アカウントがプライベート エンドポイントを使用している場合には、カスタム DNS サポートは使用できません。
  • カスタムマウント ストレージへの FTP/FTPS アクセスはサポートされていません (Azure Storage Explorer を使用してください)。
  • Azure CLI、Azure PowerShell、Azure SDK のサポートはプレビュー段階です。
  • カスタム マウント ストレージへの / または /home のマッピングはサポートされていません。
  • アプリの起動中にタイムアウトが発生する可能性があるため、カスタム ストレージのマウントを /tmp またはそのサブディレクトリにマップしないでください。
  • デプロイ スロットの作成中に、ストレージのマウントを複製設定オプションと共に使用することはできません。
  • ストレージのマウントは、アプリをバックアップするときにバックアップされません。 必ずベスト プラクティスに従って Azure Storage アカウントをバックアップしてください。

注意

VNET 統合を使う場合、次のポートを開いている必要があります。

  • Azure Files: 80 と 445。
  • Azure BLOB: 80 と 443。

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

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

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

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

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

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

    設定 説明
    名前 マウント構成の名前。 スペースは使用できません。
    [構成オプション] プライベート エンドポイントを使用していない場合は、 [基本] を選択します。 それ以外の場合は、 [詳細] を選択します。
    ストレージ アカウント Azure ストレージ アカウント。 Azure Files 共有が含まれている必要があります。
    共有名 マウントするファイル共有。
    [アクセス キー] ([詳細] のみ) ストレージ アカウントのアクセス キー
    [マウント パス] マウントするアプリ サービス内のディレクトリ。 サポートされるのは /mounts/pathname のみです。
    設定 説明
    名前 マウント構成の名前。 スペースは使用できません。
    [構成オプション] プライベート エンドポイントを使用していない場合は、 [基本] を選択します。 それ以外の場合は、 [詳細] を選択します。
    ストレージ アカウント Azure ストレージ アカウント。 Azure Files 共有が含まれている必要があります。
    共有名 マウントするファイル共有。
    [アクセス キー] ([詳細] のみ) ストレージ アカウントのアクセス キー
    [マウント パス] マウントするアプリ サービス内のディレクトリ。 ルート ディレクトリ ([C-Z]:\/) と home ディレクトリ ([C-Z]:\home/home) は使用しないでください。
    設定 説明
    名前 マウント構成の名前。 スペースは使用できません。
    [構成オプション] サービス エンドポイントまたはプライベート エンドポイントを使用していない場合は、 [基本] を選択します。 それ以外の場合は、 [詳細] を選択します。
    ストレージ アカウント 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 リージョンに配置します。 ただし、アプリと Azure Storage アカウントが同じ Azure リージョンにある場合、App Service IP アドレスからのアクセスを Azure Storage ファイアウォール構成で許可しても、それらの IP 制限が適用されないことに注意してください。

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

    1. key2 を再生成します。
    2. ストレージのマウント構成で、再生成された key2 を使用するアクセス キーを更新します。
    3. key1 を再生成します。
  • Azure Storage のアカウント、コンテナー、または共有を削除する場合は、可能性があるエラー シナリオを回避するために、対応するストレージのマウント構成をアプリから削除します。

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

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

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

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

  • アプリで Azure Storage プライベート エンドポイントを使用しているときは、ルートすべての設定を有効にする必要があります

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

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

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

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

    1. key2 を再生成します。
    2. ストレージのマウント構成で、再生成された key2 を使用するアクセス キーを更新します。
    3. key1 を再生成します。
  • Azure Storage のアカウント、コンテナー、または共有を削除する場合は、可能性があるエラー シナリオを回避するために、対応するストレージのマウント構成をアプリから削除します。

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

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

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

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

  • アプリで Azure Storage プライベート エンドポイントを使用しているときは、ルートすべての設定を有効にする必要があります

    注意

    この App Service Environment V3 では、[ルートすべて] 設定は既定で無効になり、明示的に有効にする必要があります。

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

  • カスタム コンテナーのマウント ディレクトリは空である必要があります。 このパスに格納されている内容は、Azure Storage がマウントされると削除されます (たとえば、/home の下のディレクトリを指定した場合)。 既存アプリのファイルを移行する場合は、始める前に、アプリとその内容をバックアップしてください。

  • アプリのパフォーマンス ボトルネックが発生する可能性があるため、ストレージの /home へのマウントは推奨されません。

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

    1. key2 を再生成します。
    2. ストレージのマウント構成で、再生成された key2 を使用するアクセス キーを更新します。
    3. key1 を再生成します。
  • Azure Storage のアカウント、コンテナー、または共有を削除する場合は、可能性があるエラー シナリオを回避するために、対応するストレージのマウント構成をアプリから削除します。

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

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

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

  • アプリで Azure Storage プライベート エンドポイントを使用しているときは、ルートすべての設定を有効にする必要があります

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

次の手順