Azure Container Appsでストレージマウントを使用する

コンテナーアプリは、さまざまな種類のストレージにアクセスできます。必要に応じて、1 つのアプリで複数の種類のストレージを利用できます。

注

デプロイの失敗を防ぐために、ボリューム名には特殊文字を使用しないでください。たとえば、credentials.json という名前のボリュームは特殊文字 (.) が含まれているため、デプロイは失敗します。

ストレージの種類	説明	永続化	使用例
コンテナースコープストレージ	実行中のコンテナーで使用できるエフェメラルストレージ	データはコンテナーがシャットダウンするまで使用できます	ローカルアプリキャッシュを作成する。
レプリカスコープのストレージ	同じレプリカ内のコンテナー間でファイルを共有するためのエフェメラルストレージ	データはレプリカがシャットダウンするまで使用できます	サイドカーコンテナーで処理されるログファイルを書き込むメインアプリコンテナー。
Azure Files	永続的なストレージ	データはAzure Filesに保持されます	ファイル共有にファイルを書き込んで、他のシステムからデータにアクセスできるようにする。

注

Azure Container Appsでは、Azure NetApp FilesまたはAzure Blob Storageからのファイル共有のマウントはサポートされていません。

エフェメラルストレージ

コンテナーアプリは、エフェメラルストレージとの間で一時データを読み書きできます。エフェメラルストレージのスコープは、コンテナーまたはレプリカに設定できます。各レプリカで使用できるコンテナースコープおよびレプリカスコープのストレージの合計量は、レプリカに割り当てられた vCPU の合計数によって異なります。

vCPU 数	エフェメラルストレージの合計
0.25 以下	1 GiB
0.5 以下	2 GiB
1 以下	4 GiB
1 より大	8 GiB

コンテナースコープのストレージ

コンテナーは、独自のファイルシステムに書き込むことができます。

コンテナーファイルシステムのストレージには、次の特性があります。

ストレージは一時的なものであり、コンテナーがシャットダウンまたは再起動されると消えます。
現在のコンテナーで実行されているプロセスのみが、このストレージに書き込まれたファイルを表示できます。

レプリカスコープのストレージ

Kubernetes の EmptyDir (空のディレクトリ) と同等の一時的な一時ボリュームをマウントできます。このストレージは単一のレプリカにスコープされます。 EmptyDir ボリュームを使って、同じレプリカ内のコンテナー間でデータを共有します。

レプリカスコープのストレージには、次の特性があります。

ファイルはレプリカの有効期間中保持されます。
- レプリカ内のコンテナーが再起動された場合、ボリューム内のファイルはそのまま残されます。
レプリカ内のすべての init コンテナーまたはアプリコンテナーが、同じボリュームをマウントできます。
1 つのコンテナーで、複数の EmptyDir ボリュームをマウントできます。

レプリカスコープのストレージを構成するには、最初にリビジョンで EmptyDir ボリュームを定義します。次に、リビジョン内の 1 つ以上のコンテナーでボリュームマウントを定義します。

前提条件

要件	Instructions
Azure アカウント	アカウントをお持ちでない場合は、無料でアカウントを作成してください。
Azure Container Apps 環境	コンテナーアプリ環境を作成します。

構成

Azure CLIを使用してレプリカスコープストレージを構成する場合は、YAML 定義を使用してコンテナーアプリを作成または更新する必要があります。

レプリカスコープストレージを使用するように既存のコンテナーアプリを更新するには、 app.yaml という名前の YAML ファイルにアプリの仕様をエクスポートします。
```
az containerapp show -n <APP_NAME> -g <RESOURCE_GROUP_NAME> -o yaml > app.yaml
```
コンテナーアプリの仕様に次の変更を加えます。
- コンテナーアプリ定義の volumes セクションに template 配列を追加して、ボリュームを定義します。既に volumes 配列がある場合は、新しいボリュームを配列に追加します。
  - name はボリュームの識別子です。
  - EmptyDir を storageType として使用します。
- ボリュームをマウントするテンプレート内のコンテナーごとに、コンテナー定義の volumeMounts 配列でボリュームマウントを定義します。
  - volumeName は、volumes 配列で定義されている名前です。
  - mountPath は、ボリュームをマウントするコンテナー内のパスです。
```
properties:
  managedEnvironmentId: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP_NAME>/providers/Microsoft.App/managedEnvironments/<ENVIRONMENT_NAME>
  configuration:
    activeRevisionsMode: Single
  template:
    containers:
    - image: <IMAGE_NAME1>
      name: my-container-1
      volumeMounts:
      - mountPath: /myempty
        volumeName: myempty
    - image: <IMAGE_NAME_2>
      name: my-container-2
      volumeMounts:
      - mountPath: /myempty
        volumeName: myempty
    volumes:
    - name: myempty
      storageType: EmptyDir
```

YAML ファイルを使用してコンテナーアプリを更新します。

az containerapp update --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> \
    --yaml app.yaml

完全な例については、YAML の仕様を参照してください。

レプリカスコープのボリュームを作成し、コンテナーでそれをマウントするには、ARM テンプレートでコンテナーアプリリソースを次のように変更します。

コンテナーアプリ定義の volumes セクションに template 配列を追加して、ボリュームを定義します。既に volumes 配列がある場合は、新しいボリュームを配列に追加します。
- name はボリュームの識別子です。
- EmptyDir を storageType として使用します。
ボリュームをマウントするテンプレート内のコンテナーごとに、コンテナー定義の volumeMounts 配列でボリュームマウントを定義します。
- volumeName は、volumes 配列で定義されている名前です。
- mountPath は、ボリュームをマウントするコンテナー内のパスです。

ARM テンプレートスニペットの例:

{
  "apiVersion": "2022-03-01",
  "type": "Microsoft.App/containerApps",
  "name": "[parameters('containerappName')]",
  "location": "[parameters('location')]",
  "properties": {

    ...

    "template": {
      "revisionSuffix": "myrevision",
      "containers": [
        {
          "name": "main",
          "image": "[parameters('container_image')]",
          "resources": {
            "cpu": 0.5,
            "memory": "1Gi"
          },
          "volumeMounts": [
            {
              "mountPath": "/myempty",
              "volumeName": "myempty"
            }
          ]
        },
        {
          "name": "sidecar",
          "image": "[parameters('sidecar_image')]",
          "resources": {
            "cpu": 0.5,
            "memory": "1Gi"
          },
          "volumeMounts": [
            {
              "mountPath": "/myempty",
              "volumeName": "myempty"
            }
          ]
        }
      ],
      "scale": {
        "minReplicas": 1,
        "maxReplicas": 3
      },
      "volumes": [
        {
          "name": "myempty",
          "storageType": "EmptyDir"
        }
      ]
    }
  }
}

完全な例については、 ARM テンプレート API の仕様を参照してください。

レプリカスコープボリュームを作成してコンテナーにマウントするには、Azure ポータルを使用して、コンテナーアプリの新しいリビジョンをデプロイします。

Azure ポータルで、コンテナーアプリに移動します。
左側のメニューで [ リビジョン管理 ] を選択します。
[ 新しいリビジョンの作成] を選択します。
ボリュームをマウントするコンテナーを選びます。
[ コンテナーの編集 ] コンテキストウィンドウで、[ ボリュームマウント ] タブを選択します。
[ エフェメラルストレージ ] セクションで、次の情報を含む新しいボリュームを作成します。
- ボリューム名: エフェメラルボリュームの名前。
- マウントパス: ボリュームをマウントするコンテナー内の絶対パス。
[ 保存] を 選択して変更を保存し、コンテキストウィンドウを終了します。
[ 作成] を選択して新しいリビジョンを作成します。

Azure Files ボリューム

Azure Files からコンテナー内のボリュームとしてファイル共有をマウントできます。

Important

Azure Container Appsはストレージアカウント(リソースタイプ)内で作成されるMicrosoft.Storage/storageAccounts/fileServices/sharesなAzureファイル共有のみをサポートしています。コンテナアプリは新しい Microsoft.FileShares トップレベルリソースタイプをサポートしていません。 Microsoft.FileSharesリソースをマウントしようとすると、操作は失敗します。サポートファイル共有を作成するには、「クラシックなAzureファイル共有を作成する」をご覧ください。

Azure Filesストレージには、次の特性があります。

マウント場所の下に書き込まれたファイルは、ファイル共有に永続化されます。
共有内のファイルは、マウントの場所から使用できます。
複数のコンテナーで同じファイル共有をマウントできます。これには、別のレプリカ、リビジョン、またはコンテナーアプリにあるものも含まれます。
共有をマウントするすべてのコンテナーは、他のコンテナーまたはメソッドによって書き込まれたファイルにアクセスできます。
1 つのコンテナーに複数のAzure Files ボリュームをマウントできます。

Azure Filesでは、SMB (サーバーメッセージブロック) プロトコルと NFS (ネットワークファイルシステム) プロトコルの両方がサポートされます。どちらのプロトコルを使用しても、Azure Files共有をマウントできます。環境で定義するファイル共有は、ストレージアカウントのファイル共有に使うものと同じプロトコルで構成する必要があります。

新しいSMBファイルのマウントには、ストレージアカウントキーの代わりに マネージドID認証(プレビュー) を使いましょう。コンテナアプリは、Azure Files への認証に、個々のコンテナアプリではなく、Container Apps environment に割り当てられたシステム割り当てまたはユーザー割り当てのマネージド ID を使用します。このモードにより、ストレージアカウントキーの取得、保存、またはローテーションを行う必要がなくなります。ストレージ定義でマネージドID認証を明示的に選択する必要があります。既存のストレージアカウントキーマウントは引き続きサポートされています。

マネージドID認証はSMB共有にのみ適用されます。 NFS共有はネットワークベースのアクセス制御を使用し、SMB認証設定は使いません。

コンテナ内でAzure Filesストレージを有効にするには、環境とコンテナアプリを以下のように設定してください:

Container Apps 環境でストレージの定義を作成します。
NFS を使っている場合は、環境をカスタム VNet で構成し、VNet からのアクセスを許可するようにストレージアカウントを構成する必要があります。詳細については、「Azure Files の NFS ファイル共有」を参照してください。
NFSを使っている場合、ストレージアカウントは暗号化されたNFS接続を必要としないはずです。コンテナアプリはNFSファイル共有のトランスミッション暗号化をサポートしていません。ストレージアカウントの 「Require Encryption in Transit for NFS」 設定が有効であるか、その設定が設定されておらず「 Secure Transferが必要 」が有効の場合、マウントは mount.nfs: access denied by server while mountingなどのエラーで失敗します。詳細については、「 NFS Azure ファイル共有の転送中の暗号化」を参照してください。
カスタム VNet を使って環境が構成されている場合は、サブネットに関連付けられたネットワークセキュリティグループ (NSG) でポート 445 と 2049 を許可する必要があります。
リビジョンで種類 AzureFile (SMB) または NfsAzureFile (NFS) のボリュームを定義します。
リビジョン内の 1 つ以上のコンテナーでボリュームマウントを定義します。
使用Azure Filesストレージアカウントには、コンテナーアプリの仮想ネットワークからアクセスできる必要があります。詳細については、「仮想ネットワークからのアクセスを許可する」を参照してください。

前提条件

要件	Instructions
Azure アカウント	アカウントをお持ちでない場合は、無料でアカウントを作成してください。
Azure Storage アカウント	クラシックなAzureファイル共有でストレージアカウントを作成しましょう。
Azure Container Apps 環境	コンテナーアプリ環境を作成します。
SMB認証のためのマネージドアイデンティティ	環境のシステム割り当てマネージド ID を有効にするか、ユーザー割り当てマネージド ID を環境に割り当てます。「環境 ID の管理」を参照してください。
SMB マネージド ID 認証のためのストレージアカウント設定	ストレージアカウントでSMB(`SMBOAuth`)のマネージド ID を有効にしてください。また、SMB のセキュリティ設定では、Kerberos 認証が許可されている必要があります。
Azure RBAC for SMB managed identity authentication	ストレージアカウントの範囲で、選択した環境 ID にストレージファイルデータ SMB MI 管理者ロールを割り当てます。「マネージドアイデンティティに組み込みのRBAC役割を割り当てる」を参照してください。役割を割り当てるには、その範囲で `Microsoft.Authorization/roleAssignments/write` 権限が必要です。共有をマウントする前に、ロールの割り当てが反映されるまでしばらく待ちます。

構成

Azure CLIを使用してAzure Files ボリュームをマウントするようにコンテナーアプリを構成する場合は、YAML 定義を使用してコンテナーアプリを作成または更新する必要があります。

最新のAzure CLIをインストールし、Container Apps拡張を更新してください:

az extension add --name containerapp --upgrade

SMB ファイル共有のマウントに関する詳細なチュートリアルについては、「 Azure Container Apps にAzure Filesストレージマウントを作成する」を参照してください。

Container Apps 環境にストレージの定義を追加します。
- SMB
- NFS
管理型ID認証(推奨)

環境のシステム割り当てマネージドIDを使用するには、まず以下を有効にしてください:
```
az containerapp env identity assign --name my-env --resource-group my-group \
    --system-assigned
```
ストレージアカウントで ID に「Storage File Data SMB MI Admin」ロールを付与し、前提条件に記載されているとおりに SMB 用マネージド ID を有効にします。次にストレージの定義を作成します:
```
az containerapp env storage set --name my-env --resource-group my-group \
    --storage-name mystorage \
    --storage-type AzureFile \
    --azure-file-account-name <STORAGE_ACCOUNT_NAME> \
    --azure-file-identity system \
    --azure-file-share-name <STORAGE_SHARE_NAME> \
    --access-mode ReadWrite
```
<STORAGE_ACCOUNT_NAME>と<STORAGE_SHARE_NAME>をストレージアカウント名とファイル共有名に置き換えてください。 systemの値は、環境のシステムに割り当てられた管理型アイデンティティを選択します。

代わりにユーザー割り当ての管理 ID を使用するには、それを環境に割り当ててください:
```
az containerapp env identity assign --name my-env --resource-group my-group \
    --user-assigned <MANAGED_IDENTITY_RESOURCE_ID>
```
そのIDにストレージアカウントで同じ役割を付与します。ストレージコマンドでは、--azure-file-identity systemを--azure-file-identity <MANAGED_IDENTITY_RESOURCE_ID>に置き換え、クライアントIDやプリンシパルIDではなく、アイデンティティの完全なAzureリソースIDを使用します。

--azure-file-identityを--azure-file-account-keyや--azure-file-key-vault-secret-urlと組み合わせないでください。これらの認証モードは相互に排他的です。

ストレージアカウントキー認証(代替)

管理型ID認証が使えない場合は、ストレージアカウントキーを代わりに使うことができます:
```
az containerapp env storage set --name my-env --resource-group my-group \
    --storage-name mystorage \
    --storage-type AzureFile \
    --azure-file-account-name <STORAGE_ACCOUNT_NAME> \
    --azure-file-account-key <STORAGE_ACCOUNT_KEY> \
    --azure-file-share-name <STORAGE_SHARE_NAME> \
    --access-mode ReadWrite
```
<STORAGE_ACCOUNT_NAME> と <STORAGE_ACCOUNT_KEY> を、ストレージアカウントの名前とキーに置き換えます。 <STORAGE_SHARE_NAME> を、ストレージアカウント内のファイル共有の名前に置き換えます。

--access-mode の有効な値は、ReadWrite と ReadOnly です。
```
az containerapp env storage set --name my-env --resource-group my-group \
    --storage-name mystorage \
    --storage-type NfsAzureFile \
    --server <NFS_SERVER> \
    --azure-file-share-name <STORAGE_SHARE_NAME> \
    --access-mode ReadWrite
```
<NFS_SERVER> を <STORAGE_ACCOUNT_NAME>.file.core.windows.net 形式の NFS サーバーアドレスに置き換えます。たとえば、ストレージアカウント名が mystorageaccount の場合、NFS サーバーアドレスは mystorageaccount.file.core.windows.net です。

<STORAGE_SHARE_NAME> を、/<STORAGE_ACCOUNT_NAME>/<STORAGE_SHARE_NAME> 形式のファイル共有の名前に置き換えます。たとえば、ストレージアカウント名が mystorageaccount であり、ファイル共有名が myshare の場合、共有名は /mystorageaccount/myshare です。

--access-mode の有効な値は、ReadWrite と ReadOnly です。

注

NFS Azure Filesをマウントするには、カスタム VNet で Container Apps 環境を使用する必要があります。 VNet からのアクセスを許可するようにストレージアカウントを構成する必要があります。
既存のコンテナーアプリを更新してファイル共有をマウントするには、 app.yaml という名前の YAML ファイルにアプリの仕様をエクスポートします。
```
az containerapp show -n <APP_NAME> -g <RESOURCE_GROUP_NAME> -o yaml > app.yaml
```
コンテナーアプリの仕様に次の変更を加えます。
- コンテナーアプリ定義の volumes セクションに template 配列を追加して、ボリュームを定義します。既に volumes 配列がある場合は、新しいボリュームを配列に追加します。
  - name はボリュームの識別子です。
  - storageType の場合、SMB には AzureFile、NFS には NfsAzureFile を使います。この値は、環境で定義したストレージの種類と一致する必要があります。
  - storageName では、環境内で定義したストレージの名前を使用します。
  - mountOptionsは、マウントオプションのコンマ区切りの文字列です。詳細については、Azure Files で mountOptions 設定を使用するを参照してください。
  - secrets リストは、ボリュームにマウントするシークレットのリストです。詳細については、ボリュームにシークレットをマウントする方法を参照してください。
- ストレージAzure Filesマウントするテンプレート内のコンテナーごとに、コンテナー定義の volumeMounts 配列にボリュームマウントを定義します。
  - volumeName は、volumes 配列で定義されている名前です。
  - mountPath は、ボリュームをマウントするコンテナー内のパスです。
  - subPathは、マウントするボリューム内のパスです。この値を指定しない場合は、ボリュームルートがマウントされます。詳細については、サブパスを参照してください。
- SMB
- NFS
```
properties:
  managedEnvironmentId: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP_NAME>/providers/Microsoft.App/managedEnvironments/<ENVIRONMENT_NAME>
  configuration:
  template:
    containers:
    - image: <IMAGE_NAME>
      name: my-container
      volumeMounts:
      - volumeName: azure-files-volume
        mountPath: /my-files
        subPath: my-sub-path
    volumes:
    - name: azure-files-volume
      storageType: AzureFile
      storageName: mystorage
```
```
properties:
  managedEnvironmentId: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP_NAME>/providers/Microsoft.App/managedEnvironments/<ENVIRONMENT_NAME>
  configuration:
  template:
    containers:
    - image: <IMAGE_NAME>
      name: my-container
      volumeMounts:
      - volumeName: azure-files-volume
        mountPath: /my-files
        subPath: my-sub-path
    volumes:
    - name: azure-files-volume
      storageType: NfsAzureFile
      storageName: mystorage
```

YAML ファイルを使用してコンテナーアプリを更新します。

az containerapp update --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> \
    --yaml app.yaml

完全な例については、YAML の仕様を参照してください。

次の ARM テンプレートスニペットは、コンテナーアプリ環境にAzure Files共有を追加し、コンテナーアプリで使用する方法を示しています。 SMBマネージドID認証の場合、環境上でアイデンティティを有効化または割り当てし、ストレージアカウントの前提条件を満たしてからストレージ定義を展開してください。

storages 子リソースを Container Apps 環境に追加します。
- SMB
- NFS
管理型ID認証(推奨)

まず、Microsoft.App/managedEnvironmentsリソースではなく、Microsoft.App/containerAppsリソース上で管理されたアイデンティティを有効にしてください。環境のシステム割り当てアイデンティティを有効にするには、以下のトップレベル identity プロパティを環境リソースに追加してください:
```
{
  "identity": {
    "type": "SystemAssigned"
  }
}
```
このフラグメントを既存の環境リソースにマージし、他の構成はそのままにします。 2026-03-02-previewなど管理型IDをサポートする環境APIバージョンを使用してください。リソーススキーマについては、Microsoft.App/managedEnvironments を参照してください。

前提条件に記載されているとおり、ストレージアカウントで SMB 用マネージド ID (SMBOAuth) を有効化し、環境 ID にストレージアカウントスコープで Storage File Data SMB MI Admin のロールを割り当てます。

次に、ストレージリソースにはAPIバージョン 2026-03-02-preview を使いましょう。 properties.azureFile.identity を system に設定して、環境のシステム割り当て ID を選択します:
```
{
  "type": "Microsoft.App/managedEnvironments/storages",
  "apiVersion": "2026-03-02-preview",
  "name": "[concat(parameters('environment_name'), '/myazurefiles')]",
  "properties": {
    "azureFile": {
      "accountName": "[parameters('storage_account_name')]",
      "identity": "system",
      "shareName": "[parameters('storage_share_name')]",
      "accessMode": "ReadWrite"
    }
  }
}
```
代わりにユーザー割り当てのマネージドIDを使用するには、環境の最上位 identity プロパティに追加してください:
```
{
  "identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "[parameters('managed_identity_resource_id')]": {}
    }
  }
}
```
managed_identity_resource_idパラメータを、アイデンティティの完全なAzureリソースIDを含むstringとして定義します。ストレージリソースでproperties.azureFile.identityを[parameters('managed_identity_resource_id')]ではなくsystemに設定してください。そのIDにストレージアカウントで同じ役割を付与します。

環境に既に割り当てられたアイデンティティは保持してください。両方のアイデンティティタイプを有効にした場合、環境のSystemAssigned,UserAssignedにidentity.typeを使い、そのuserAssignedIdentitiesエントリを保持します。

マネージド ID 認証を使う際に accountKey や accountKeyVaultProperties は含めないでください。ストレージリソーススキーマについては、Microsoft.App/managedEnvironments/storages を参照してください。

ストレージアカウントキー認証(代替)

ストレージアカウントキーを使う場合は、 accountKey を設定して identityを省略してください。 storage_account_keyテンプレートパラメータをsecureStringとして定義します。
```
{
  "type": "Microsoft.App/managedEnvironments/storages",
  "apiVersion": "2022-03-01",
  "name": "[concat(parameters('environment_name'), '/myazurefiles')]",
  "properties": {
    "azureFile": {
      "accountName": "[parameters('storage_account_name')]",
      "accountKey": "[parameters('storage_account_key')]",
      "shareName": "[parameters('storage_share_name')]",
      "accessMode": "ReadWrite"
    }
  }
}
```
これらのストレージスニペットは、環境やファイル共有がすでに存在することを前提としています。同じテンプレートにデプロイする場合は、環境とファイル共有リソースをストレージリソースの dependsOn 配列に追加してください。マネージド ID による認証の場合、そのテンプレート内でロール割り当てを作成する場合は、ロール割り当てへの依存関係も追加してください。デプロイメント依存性があっても、ロール割り当ての伝播遅延は解消されません。
```
{
  "type": "Microsoft.App/managedEnvironments",
  "apiVersion": "2023-05-01",
  "name": "[parameters('environment_name')]",
  "location": "[parameters('location')]",
  "properties": {
    "daprAIInstrumentationKey": "[parameters('dapr_ai_instrumentation_key')]",
    "appLogsConfiguration": {
      "destination": "log-analytics",
      "logAnalyticsConfiguration": {
        "customerId": "[parameters('log_analytics_customer_id')]",
        "sharedKey": "[parameters('log_analytics_shared_key')]"
      }
    },
    "workloadProfiles": [
      {
        "name": "Consumption",
        "workloadProfileType": "Consumption"
      }
    ],
    "vnetConfiguration": {
      "infrastructureSubnetId": "[parameters('custom_vnet_subnet_id')]",
      "internal": false
    }
  },
  "resources": [
    {
      "type": "storages",
      "name": "myazurefiles",
      "apiVersion": "2023-11-02-preview",
      "dependsOn": [
        "[resourceId('Microsoft.App/managedEnvironments', parameters('environment_name'))]"
      ],
      "properties": {
        "nfsAzureFile": {
          "server": "[concat(parameters('storage_account_name'), '.file.core.windows.net')]",
          "shareName": "[concat('/', parameters('storage_account_name'), '/', parameters('storage_share_name'))]",
          "accessMode": "ReadWrite"
        }
      }
    }
  ]
}
```
注

NFS Azure Filesをマウントするには、カスタム VNet で Container Apps 環境を使用する必要があります。 VNet からのアクセスを許可するようにストレージアカウントを構成する必要があります。
コンテナーアプリリソースを更新して、ボリュームとボリュームマウントを追加します。

SMB認証は環境のストレージ定義で設定されます。管理IDおよびストレージアカウントキー認証において、アプリレベルのボリューム構成は同じです。ストレージリソースとコンテナアプリを同じテンプレートにデプロイする場合は、ストレージリソースをコンテナアプリの dependsOn 配列に追加してください。
- SMB
- NFS
```
{
  "apiVersion": "2023-05-01",
  "type": "Microsoft.App/containerApps",
  "name": "[parameters('containerappName')]",
  "location": "[parameters('location')]",
  "properties": {

    ...

    "template": {
      "revisionSuffix": "myrevision",
      "containers": [
        {
          "name": "main",
          "image": "[parameters('container_image')]",
          "resources": {
            "cpu": 0.5,
            "memory": "1Gi"
          },
          "volumeMounts": [
            {
              "mountPath": "/myfiles",
              "volumeName": "azure-files-volume",
              "subPath": "my-sub-path"
            }
          ]
        }
      ],
      "scale": {
        "minReplicas": 1,
        "maxReplicas": 3
      },
      "volumes": [
        {
          "name": "azure-files-volume",
          "storageType": "AzureFile",
          "storageName": "myazurefiles"
        }
      ]
    }
  }
}
```
```
{
  "apiVersion": "2023-11-02-preview",
  "type": "Microsoft.App/containerApps",
  "name": "[parameters('containerappName')]",
  "location": "[parameters('location')]",
  "properties": {

    ...

    "template": {
      "revisionSuffix": "myrevision",
      "containers": [
        {
          "name": "main",
          "image": "[parameters('container_image')]",
          "resources": {
            "cpu": 0.5,
            "memory": "1Gi"
          },
          "volumeMounts": [
            {
              "mountPath": "/myfiles",
              "volumeName": "azure-files-volume",
              "subPath": "my-sub-path"
            }
          ]
        }
      ],
      "scale": {
        "minReplicas": 1,
        "maxReplicas": 3
      },
      "volumes": [
        {
          "name": "azure-files-volume",
          "storageType": "NfsAzureFile",
          "storageName": "myazurefiles"
        }
      ]
    }
  }
}
```
- コンテナーアプリ定義の volumes セクションに template 配列を追加して、ボリュームを定義します。既に volumes 配列がある場合は、新しいボリュームを配列に追加します。
  - name はボリュームの識別子です。
  - storageType の場合、SMB には AzureFile、NFS には NfsAzureFile を使います。この値は、環境で定義したストレージの種類と一致する必要があります。
  - storageName では、環境内で定義したストレージの名前を使用します。
  - mountOptionsは、マウントオプションのコンマ区切りの文字列です。詳細については、Azure Files で mountOptions 設定を使用するを参照してください。
  - secrets リストは、ボリュームにマウントするシークレットのリストです。詳細については、ボリュームにシークレットをマウントする方法を参照してください。
- ストレージAzure Filesマウントするテンプレート内のコンテナーごとに、コンテナー定義の volumeMounts 配列にボリュームマウントを定義します。
  - volumeName は、volumes 配列で定義されている名前です。
  - mountPath は、ボリュームをマウントするコンテナー内のパスです。
  - subPath (省略可能) は、マウントするボリューム内のパスです。指定しない場合は、ボリュームルートがマウントされます。詳細については、サブパスを参照してください。

完全な例については、 ARM テンプレート API の仕様を参照してください。

Azure ポータルでAzure Filesストレージのボリュームマウントを構成するには、Container Apps 環境にファイル共有を追加し、新しいリビジョンを作成してコンテナーアプリにボリュームマウントを追加します。新しいSMBマウントの場合は、管理型アイデンティティ認証を選択してください。

Azure ポータルで、Container Apps 環境に移動します。
SMBのマネージド ID 認証を行うには、設定>ID を選択し、システム割り当て ID を有効にするか、ユーザー割り当て ID を環境に追加してください。共有を追加する前に、Azure Filesの前提条件で説明されているストレージアカウント設定と役割割り当てを完了してください。
ナビゲーションウィンドウの [設定] で、[ ボリュームマウント] を選択します。
追加を選択します。
ファイル共有で使用されるプロトコルに応じて、 サーバーメッセージブロック (SMB) または ネットワークファイルシステム (NFS) を選択します。
[ファイル共有の追加] コンテキストペインで、次の情報を入力します。
- SMB
- NFS
- 名前:環境のストレージ定義の名称です。
- ストレージアカウント名: ファイル共有を含むストレージアカウントの名前。
- 認証:マネージド IDを選択します(推奨)。
- アイデンティティ: 管理 ID の一覧から、環境のシステム割り当て ID または環境に割り当てられたユーザー割り当て ID を選択します。ストレージアカウントに Storage File Data SMB MI Admin の役割を持つIDを選択してください。
- ファイル共有名:SMBファイル共有の名前です。
- アクセスモード: ファイル共有のアクセスモード。有効な値は 、読み取り/書き込み および 読み取り専用です。
代わりにストレージアカウントキー認証を使うには、ストレージアカウントキー を認証で選択し、ストレージアカウントのアクセスキーを入力します。ストレージ定義のために1つの認証方法を選択します。
- 名前: ファイル共有の名前。
- サーバー: ファイル共有を含むサーバーの名前。このサーバー名は、 <STORAGE_ACCOUNT_NAME>.file.core.windows.netの形式に従います。
- ファイル共有名: ファイル共有の名前。この名前は、 /<STORAGE_ACCOUNT_NAME>/<FILE_SHARE_NAME>形式に従います。
- アクセスモード: ファイル共有のアクセスモード。有効な値は 、読み取り/書き込み および 読み取り専用です。
[ 追加] を選択してコンテキストウィンドウを終了します。
[ 保存] を 選択して変更をコミットします。
コンテナーアプリに移動します。
ナビゲーションウィンドウの [ アプリケーション] で、[ リビジョンとレプリカ] を選択します。
[ 新しいリビジョンの作成] を選択します。
[ 新しいリビジョンの作成と展開 ] ページで、[ボリューム] タブを選択します。
追加を選択します。
[ ボリュームの追加 ] コンテキストウィンドウで、次の値を設定します。
- ボリュームの種類: Azure ファイルボリューム。
- 名前: ボリューム名を入力します。
- ファイル共有名: 前に作成したファイル共有を選択します。
- マウントオプション: 必要に応じて、マウントオプションのコンマ区切りの文字列を入力します。詳細については、Azure Files で mountOptions 設定を使用するを参照してください。
[ 追加] を選択してコンテキストウィンドウを終了します。
「 新しいリビジョンを作成してデプロイ 」ページで「 コンテナ 」タブを選択します。
ボリュームをマウントするコンテナーを選びます。
[ コンテナーの編集 ] コンテキストウィンドウで、[ ボリュームマウント ] タブを選択します。
[ ボリューム名] で、前に作成したボリュームを選択します。
[ マウントパス] に、ボリュームをマウントするコンテナーの絶対パスを入力します。
サブパス (省略可能) に、マウントするボリューム内のパスを入力します。この値を指定しない場合は、ボリュームルートがマウントされます。詳細については、サブパスを参照してください。
[ 保存] を 選択して変更を保存し、コンテキストウィンドウを終了します。
[ 作成] を選択して新しいリビジョンを作成します。

サブパス

Azure Filesからファイル共有をマウントする場合は、マウントパスとサブパスの両方を指定できます。

マウントパス: ボリュームをマウントするコンテナー内のパス。
サブパス: マウントするボリューム内のパス。

サブパスは省略可能です。サブパスを指定しない場合は、ボリュームルートがマウントされます。

サブパスは、ボリュームルートからの相対パスです。 /でサブパスを開始しないでください。 /で始まるサブパスを指定すると、コンテナーアプリが起動しない可能性があります。たとえば、 my-volume-folder は有効なサブパスですが、 /my-volume-folder は有効ではありません。

サブパスは、ボリューム内のフォルダーまたはファイルを参照できます。

サブパスがフォルダーを参照している場合、マウントパスはコンテナー内の空のフォルダーを参照する必要があります。
サブパスがファイルを参照している場合、マウントパスはコンテナーにまだ存在しないファイルを参照する必要があります。

たとえば、サブパスが my-volume-folder/my-volume-file.txtされ、マウントパスが /my-container-folder/my-container-file.txtされるとします。フォルダー /my-container-folder はコンテナーに既に存在している必要がありますが、ファイル my-container-file.txtはまだ含まれません。

システムは、末尾にスラッシュがあるサブパスを無視します。

フィードバック

このページはお役に立ちましたか?

最終更新: 2026-10-22

Azure Container Appsでストレージ マウントを使用する

エフェメラル ストレージ

コンテナー スコープのストレージ

レプリカ スコープのストレージ

前提条件

構成

Azure Files ボリューム

前提条件

構成

サブパス

関連コンテンツ

フィードバック

その他のリソース

Azure Container Appsでストレージマウントを使用する

エフェメラルストレージ

コンテナースコープのストレージ

レプリカスコープのストレージ