Azure Storage は、最新のデータ ストレージ シナリオ用の Microsoft のクラウド ストレージ ソリューションです。 Azure Storage は、クラウド内のデータ オブジェクトに対して、可用性が高く、スケーラビリティ、持続性、安全性に優れたストレージを提供します。 このガイドでは、Azure App Service で Azure Storage ファイルをネットワーク共有として Windows コード (コンテナー以外) にマウントする方法について説明します。
Azure Storage では、App Service の Azure Files 共有および Premium ファイル共有がサポートされています。 Azure Storage は、App Service の既定のストレージではありません。 個別に課金されます。 ARM テンプレートで Azure Storage を構成することもできます。
カスタムマウント ストレージの利点は次のとおりです。
- App Service アプリの永続ストレージを構成し、ストレージを個別に管理します。
- 動画や画像などの静的なコンテンツが App Service アプリですぐに利用できるようになります。
- Azure Files 共有に対して、アプリケーション ログ ファイルを書き込むか、古いアプリケーション ログをアーカイブします。
- 複数のアプリ間または他の Azure サービスとの間でコンテンツを共有します。
Windows コードでは、次の機能がサポートされています。
- キー コンテナー、プライベート エンドポイント、サービス エンドポイントを使用したストレージ アカウントへのセキュリティで保護されたアクセス (仮想ネットワーク統合を使用する場合)。
- Azure Files (読み取り/書き込み)。
- アプリあたり最大 5 つのマウント ポイント。
- /mounts/<path-name> を使用した Azure Storage ファイル共有のマウント。
Azure Storage をアプリにマウントするには、次の 3 つのオプションがあります。
| マウント オプション | 使用法 |
|---|---|
| 基本 | Azure portal を使用してストレージをマウントする場合は、このオプションを選択します。 ストレージ アカウントでサービス エンドポイント、プライベート エンドポイント、または Azure Key Vault を使用しない限り、基本オプションを使用できます。 この場合は、ポータルによって自動的にアクセス キーが取得および保存されます。 |
| アクセス キー | Azure CLI を使用してストレージをマウントする予定の場合は、ユーザーがアクセス キーを取得する必要があります。 ストレージ アカウントでサービス エンドポイント、プライベート エンドポイント、または Azure Key Vault を使用しない場合は、このオプションを選択します。 |
| Key Vault | また、Azure CLI を使用してストレージをマウントする予定の場合 (アクセス キーが必要) も、このオプションを使用します。 Azure Key Vault を使用してアクセス キーを安全に保存および取得する場合は、このオプションを選択します。 Azure Key Vault には、Azure App Service などの他の Azure サービスを監視、管理、統合する機能により、アプリケーション シークレットを一元的かつ安全に保存する利点があります。 |
前提条件
制限事項
- ストレージ ファイアウォールは、仮想ネットワーク統合を使用する場合、プライベート エンドポイントおよびサービス エンドポイントを介してのみサポートされます。
- App Service にデプロイされた Windows コード アプリの Azure ストレージ マウントを構成する場合、Azure BLOB はサポートされていません。
- マウントされたストレージへの FTP/FTPS アクセスはサポートされていません。 Azure Storage Explorer を使用します。
- /mounts、mounts/name1/name2、/および /mounts/name.ext/ からカスタムマウント ストレージへのマッピングはサポートされていません。 カスタム ストレージを Web アプリにマウントするには、/mounts/pathname のみを使用できます。
- ストレージ マウントはバックアップに含まれません。 必ずベスト プラクティスに従って Azure Storage アカウントをバックアップしてください。
- アプリでの仮想ネットワーク統合では、マウントされたドライブは仮想ネットワークからの IP アドレスではなく、RFC1918 IP アドレスを使用します。
マウントの準備
ストレージを Windows コードにマウントする
Azure portal でアプリに移動します。
左側のナビゲーションから、[設定]>[構成] を選択します。 [パスのマッピング]、[新しい Azure Storage マウント] の順に選択します。
次の表に従って、ストレージのマウントを構成します。 完了したら、OKを選択します。
設定 説明 名前 マウント構成の名前。 スペースは使用できません。 構成オプション ストレージ アカウントでプライベート エンドポイントまたは Azure Key Vault を使用しない場合は、[基本] を選択します。 それ以外の場合は、[詳細] を選択します。 ストレージ アカウント Azure Storage アカウント。 Azure Files 共有が含まれている必要があります。 共有名 マウントするファイル共有。 ストレージ アクセス Azure Key Vault の場合は、[キー コンテナーの参照] を選択します。 それ以外の場合は、[Manual input]\(手動入力\) を選択します。 アクセス キー ([詳細] のみ) ストレージ アカウントのアクセス キー。 マウント パス マウントするアプリ サービス内のディレクトリ。 /mounts/pathname のみがサポートされています。 アプリケーションの設定 Azure Key Vault シークレットを使用してアプリ設定を選択します。 デプロイ スロットの設定 選択すると、ストレージ マウント設定もデプロイ スロットに適用されます。
注意
ストレージ マウントを追加、編集、または削除すると、アプリが再起動します。
ベスト プラクティス
Azure Storage マウントは、静的コンテンツを提供する仮想ディレクトリとして構成できます。 仮想ディレクトリを構成するには、左側のナビゲーションで [設定]>[構成] を選択します。 次に、[パスのマッピング]、[新しい仮想アプリケーションまたはディレクトリ] の順に選択します。 [物理パス] を、Azure Storage マウントで定義されている [マウント パス] に設定します。
待機時間の問題を回避するには、アプリと Azure Storage アカウントを同じリージョンに配置します。 アプリと Azure Storage アカウントが同じリージョンにある場合に App Service IP アドレスからのアクセスを Azure Storage ファイアウォール構成で許可しても、それらの IP 制限は適用されません。
Azure Storage アカウントでは、アプリでストレージのマウントに使用されるアクセス キーの再生成を行わないようにしてください。 ストレージ アカウントには、2 つのキーが含まれています。 Azure App Services によって Azure Storage アカウント キーが格納されます。 キーの再生成中にストレージのマウントをアプリで引き続き使用できるようにするには、段階的なアプローチを使用します。 たとえば、key1 を使用して、アプリでストレージのマウントを構成したとします。
- key2 を再生成します。
- ストレージのマウント構成で、再生成された key2 を使用するアクセス キーを更新します。
- key1 を再生成します。
Azure Storage のアカウント、コンテナー、または共有を削除する場合は、可能性があるエラー シナリオを回避するために、対応するストレージのマウント構成をアプリから削除します。
マウントされた Azure Storage アカウントは、Standard または Premium パフォーマンス レベルのいずれかになります。 アプリの容量とスループットの要件に基づいて、ストレージ アカウントに適したパフォーマンス レベルを選択します。 「ファイルのスケーラビリティおよびパフォーマンス目標」をご覧ください。
アプリが複数のインスタンスにスケーリングされる場合、マウントされている同じ Azure Storage アカウントにすべてのインスタンスが接続します。 パフォーマンス ボトルネックとスループットの問題を回避するには、ストレージ アカウントに対して適切なパフォーマンス レベルを選択します。
ローカル データベース (SQLite など) や、ファイル ハンドルやロックに依存するその他のアプリケーションやコンポーネントに対しては、ストレージのマウントの使用をお勧めしません。
ストレージ アカウントがアプリにマウントされている時にストレージ フェールオーバーを開始すると、アプリが再起動されるか、ストレージ マウントが削除されて再追加されるまで、マウントが接続されません。
仮想ネットワーク統合を使用する場合は、アプリ設定で、
WEBSITE_CONTENTOVERVNETが1に設定され、次のポートが開かれていることを確認します: Azure Files: 80 および 445。マウントされた Azure Storage アカウントは、Standard または Premium パフォーマンス レベルのいずれかになります。 アプリの容量とスループットの要件に基づいて、ストレージ アカウントに適したパフォーマンス レベルを選択します。 Files のスケーラビリティとパフォーマンス目標に関する説明をご覧ください。
次のステップ
Azure Storage は、最新のデータ ストレージ シナリオ用の Microsoft のクラウド ストレージ ソリューションです。 Azure Storage は、クラウド内のデータ オブジェクトに対して、可用性が高く、スケーラビリティ、持続性、安全性に優れたストレージを提供します。 このガイドでは、App Service で Azure Storage ファイルをネットワーク共有として Windows コンテナーにマウントする方法について説明します。
Azure Storage では、Azure Files 共有および Premium Files 共有がサポートされます。 Azure Storage は、App Service の既定のストレージではありません。 個別に課金されます。 ARM テンプレートで Azure Storage を構成することもできます。
カスタムマウント ストレージの利点は次のとおりです。
- App Service アプリの永続ストレージを構成し、ストレージを個別に管理します。
- 動画や画像などの静的なコンテンツが App Service アプリですぐに利用できるようになります。
- Azure ファイル共有に対して、アプリケーション ログ ファイルを書き込むか、古いアプリケーション ログをアーカイブします。
- 複数のアプリ間または他の Azure サービスとの間でコンテンツを共有します。
- Windows コンテナーに、Isolated を含む Azure Storage をマウントします。 詳細については、App Service environment v3 の記事を参照してください。
Windows コンテナーでは、次の機能がサポートされています。
- 仮想ネットワーク統合を使用する場合の、キー コンテナー、プライベート エンドポイント、サービス エンドポイントを使用したストレージ アカウントへのセキュリティで保護されたアクセス。
- Azure Files (読み取り/書き込み)。
- アプリあたり最大 5 つのマウント ポイント。
- ドライブ文字の割り当て (C: から Z:)。
Azure Storage をアプリにマウントするには、次の 3 つのオプションがあります。
| マウント オプション | 使用法 |
|---|---|
| 基本 | Azure portal を使用してストレージをマウントする場合は、このオプションを選択します。 ストレージ アカウントでサービス エンドポイント、プライベート エンドポイント、または Azure Key Vault を使用しない限り、基本オプションを使用できます。 この場合は、ポータルによって自動的にアクセス キーが取得および保存されます。 |
| アクセス キー | Azure CLI を使用してストレージをマウントする予定の場合は、ユーザーがアクセス キーを取得する必要があります。 ストレージ アカウントでサービス エンドポイント、プライベート エンドポイント、または Azure Key Vault を使用しない場合は、このオプションを選択します。 |
| Key Vault | また、Azure CLI を使用してストレージをマウントする予定の場合 (アクセス キーが必要) も、このオプションを使用します。 Azure Key Vault を使用してアクセス キーを安全に保存および取得する場合は、このオプションを選択します。 Azure Key Vault には、Azure App Service などの他の Azure サービスを監視、管理、統合する機能により、アプリケーション シークレットを一元的かつ安全に保存する利点があります。 |
前提条件
制限事項
- Azure BLOB はサポートされていません。
- ストレージ ファイアウォールは、仮想ネットワーク統合を使用する場合、プライベート エンドポイントおよびサービス エンドポイントを介してのみサポートされます。
- マウントされたストレージへの FTP/FTPS アクセスはサポートされていません (Azure Storage Explorer を使用してください)。
- [C-Z]:\、[C-Z]:\home、/、および /home のカスタムマウント ストレージへのマッピングはサポートされていません。
- アプリをバックアップする際に、ストレージ マウントはバックアップされません。 必ずベスト プラクティスに従って Azure Storage アカウントをバックアップしてください。
- アプリでの仮想ネットワーク統合では、マウントされたドライブは仮想ネットワークからの IP アドレスではなく、RFC1918 IP アドレスを使用します。
マウントの準備
ストレージを Windows コンテナーにマウントする
Azure portal でアプリに移動します。
左側のナビゲーションから、[設定]>[構成] を選択します。 [パスのマッピング]、[新しい Azure Storage マウント] の順に選択します。
次の表に従って、ストレージのマウントを構成します。 完了したら、OKを選択します。
設定 説明 名前 マウント構成の名前。 スペースは使用できません。 構成オプション [基本] を選択します ストレージ アカウント Azure Storage アカウント。 Azure Files 共有が含まれている必要があります。 共有名 マウントするファイル共有。 マウント パス マウントする Windows コンテナー内のディレクトリ。 ルート ディレクトリ ([C-Z]:*または /) または home ディレクトリ ([C-Z]:\home* または /home) は使用しないでください。 デプロイ スロットの設定 選択すると、ストレージ マウント設定もデプロイ スロットに適用されます。
注意
ストレージ マウントを追加、編集、または削除すると、アプリが再起動します。
ベスト プラクティス
待機時間の問題を回避するには、アプリと Azure Storage アカウントを同じリージョンに配置します。 アプリと Azure Storage アカウントが同じリージョンにある場合に App Service IP アドレスからのアクセスを Azure Storage ファイアウォール構成で許可しても、それらの IP 制限は適用されません。
Azure Storage アカウントでは、アプリでストレージのマウントに使用されるアクセス キーの再生成を行わないようにしてください。 ストレージ アカウントには、2 つのキーが含まれています。 Azure App Services によって Azure Storage アカウント キーが格納されます。 キーの再生成中にストレージのマウントをアプリで引き続き使用できるようにするには、段階的なアプローチを使用します。 たとえば、key1 を使用して、アプリでストレージのマウントを構成したとします。
- key2 を再生成します。
- ストレージのマウント構成で、再生成された key2 を使用するアクセス キーを更新します。
- key1 を再生成します。
Azure Storage のアカウント、コンテナー、または共有を削除する場合は、可能性があるエラー シナリオを回避するために、対応するストレージのマウント構成をアプリから削除します。
マウントされた Azure Storage アカウントは、Standard または Premium パフォーマンス レベルのいずれかになります。 アプリの容量とスループットの要件に基づいて、ストレージ アカウントに適したパフォーマンス レベルを選択します。 「ファイルのスケーラビリティおよびパフォーマンス目標」をご覧ください。
アプリが複数のインスタンスにスケーリングされる場合、マウントされている同じ Azure Storage アカウントにすべてのインスタンスが接続します。 パフォーマンス ボトルネックとスループットの問題を回避するには、ストレージ アカウントに対して適切なパフォーマンス レベルを選択します。
ローカル データベース (SQLite など) や、ファイル ハンドルやロックに依存するその他のアプリケーションやコンポーネントに対しては、ストレージのマウントの使用をお勧めしません。
仮想ネットワーク統合で Azure Files を使用する場合は、ポート 80 と 445 が開かれていることを確認します。
ストレージ アカウントがアプリにマウントされている時にストレージ フェールオーバーを開始すると、アプリが再起動されるか、ストレージ マウントが削除されて再追加されるまで、マウントが接続されません。
次のステップ
注意
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 つのマウント ポイントをサポートします。
カスタムマウント ストレージの制限事項は次のとおりです。
- ストレージ ファイアウォールは、仮想ネットワーク統合を使用する場合、サービス エンドポイントおよびプライベート エンドポイントを介してのみサポートされます。
- カスタムマウント ストレージへの 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 用の同じ仮想ネットワーク上に構成する必要があります。 ファイル共有に使用されるストレージ アカウントには、アカウントの種類として "Premium" パフォーマンス レベルと "File storage" を指定する必要があります。 NFS プロトコルを使用する場合、Azure Key Vault は適用されません。
- アプリでの仮想ネットワーク統合では、マウントされたドライブは仮想ネットワークからの IP アドレスではなく、RFC1918 IP アドレスを使用します。
マウント オプション
ストレージをアプリにマウントする必要があります。 Azure Storage の 3 つのマウント オプションを次に示します。
| マウント オプション | 使用法 |
|---|---|
| 基本 | Azure portal を使用してストレージをマウントするには、このオプションを選択します。 ストレージ アカウントでサービス エンドポイント、プライベート エンドポイント、または Azure Key Vault を使用しない限り、基本オプションを使用できます。 この場合は、ポータルによって自動的にアクセス キーが取得および保存されます。 |
| アクセス キー | Azure CLI を使用してストレージをマウントする予定の場合は、ユーザーがアクセス キーを取得する必要があります。 ストレージ アカウントでサービス エンドポイント、プライベート エンドポイント、または Azure Key Vault を使用しない場合は、このオプションを選択します。 |
| Key Vault | また、Azure CLI を使用してストレージをマウントする予定の場合 (アクセス キーが必要) も、このオプションを使用します。 Azure Key Vault を使用してアクセス キーを安全に格納および取得する場合は、このオプションを選択します。 Azure Key Vault には、Azure App Service などの他の Azure サービスを監視、管理、統合する機能により、アプリケーション シークレットを一元的かつ安全に保存する利点があります。 |
前提条件
マウントの準備
ストレージを Linux コンテナーにマウントする
ストレージをマウントする方法は、使用するストレージ アクセス オプションと、ポータルまたは Azure CLI のどちらを使用するかによって異なります。
Azure portal でアプリに移動します。
左側のナビゲーションから、[設定]>[構成] を選択します。 [パスのマッピング]、[新しい Azure Storage マウント] の順に選択します。
次の表に従って、ストレージのマウントを構成します。 完了したら、OKを選択します。
設定 説明 名前 マウント構成の名前。 スペースは使用できません。 構成オプション ストレージ アカウントでサービス エンドポイント、プライベート エンドポイント、または Azure Key Vault を使用しない場合は、[基本] を選択します。 それ以外の場合は、[詳細] を選択します。 ストレージ アカウント Azure Storage アカウント。 ストレージの種類 マウントするストレージに基づいて種類を選択します。 Azure BLOB では、読み取り専用アクセスのみがサポートされています。 [ストレージ コンテナー] または [共有名] マウントするファイル共有または BLOB コンテナー。 マウント パス Azure Storage にマウントする、Linux コンテナー内のディレクトリ。 / や /home は使用しないでください。 デプロイ スロットの設定 オンにすると、ストレージ マウント設定がデプロイ スロットにも適用されます。
注意
ストレージ マウントを追加、編集、または削除すると、アプリが再起動します。
マウントされたストレージを検証する
Azure Storage がアプリに対して正常にマウントされたことを検証するには、次のようにします。
コンテナーに対して SSH セッションを開きます。
SSH ターミナルで、次のコマンドを実行します。
df –hストレージ共有がマウントされているかどうか確認します。 存在しない場合、ストレージ共有のマウントに問題があります。
次のコマンドを使用して、ストレージのマウントの待機時間または一般的な到達可能性を確認します。
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 を使用して、アプリでストレージのマウントを構成したとします。
- key2 を再生成します。
- ストレージのマウント構成で、再生成された key2 を使用するアクセス キーを更新します。
- key1 を再生成します。
構成
- ファイルをすばやく変更、追加、または削除するための変更が想定されるリアルタイム ファイル システムを使用する必要がある場合は、ストレージをマウントするときにストレージの種類として Azure Files を使用します。 ファイルが静的であり、ファイルが変更されるとは思わない場合は、Azure BLOB を使用します。
トラブルシューティング
- カスタム コンテナーのマウント ディレクトリは空である必要があります。 たとえば、/home でディレクトリを指定すると、このパスに格納されているコンテンツは Azure Storage のマウント時に削除されます。 既存アプリのファイルを移行する場合は、始める前に、アプリとその内容をバックアップしてください。
- Azure Storage のアカウント、コンテナー、または共有を削除する場合は、可能性があるエラー シナリオを回避するために、対応するストレージのマウント構成をアプリから削除します。
- ローカル データベース (SQLite など) や、ファイル ハンドルやロックに依存するその他のアプリケーションやコンポーネントに対しては、ストレージのマウントの使用をお勧めしません。
- 仮想ネットワーク統合を使うときは、次のポートが開いていることを確認してください。Azure Files: 80 と 445。 Azure BLOB: 80 と 443。
- ストレージ アカウントがアプリにマウントされている時にストレージ フェールオーバーを開始すると、アプリが再起動されるか、ストレージ マウントが削除されて再追加されるまで、マウントが接続されません。