Verwenden Sie Speichereinbindungen in Azure Container Apps

Eine Container-App hat Zugriff auf verschiedene Typen von Speicher. Eine einzelne App kann bei Bedarf mehr als einen Typ von Speicher nutzen.

Hinweis

Vermeiden Sie die Verwendung von Sonderzeichen in Volumenamen, um Bereitstellungsfehler zu vermeiden. Ein Volume mit dem Namen credentials.json enthält z. B. ein Sonderzeichen (.), das zu einem Bereitstellungsfehler führt.

Speichertyp BESCHREIBUNG Persistenz Verwendungsbeispiel
Containerbezogener Speicher Flüchtiger Speicher, der für einen ausgeführten Container verfügbar ist Daten sind verfügbar, bis der Container heruntergefahren wird. Schreiben in einen lokalen App-Cache.
Replikatbezogener Speicher Flüchtiger Speicher für die Freigabe von Dateien zwischen Containern im selben Replikat Daten sind verfügbar, bis das Replikat heruntergefahren wird. App-Hauptcontainer, der Protokolldateien schreibt, die von einem Sidecarcontainer verarbeitet werden.
Azure Files Permanenter Speicher Daten werden auf Azure Files beibehalten. Schreiben von Dateien in eine Dateifreigabe, um Daten für andere Systeme zugänglich zu machen.

Hinweis

Azure Container Apps unterstützt nicht das Mounten von Dateifreigaben von Azure NetApp Files oder Azure Blob Storage.

Kurzlebiger Speicher

Eine Container-App kann temporäre Daten im flüchtigen Speicher lesen und schreiben. Flüchtiger Speicher kann auf einen Container oder ein Replikat festgelegt werden. Die Gesamtmenge des für jedes Replikat verfügbaren containerbezogenen und replikatbezogenen Speichers hängt von der Gesamtanzahl der dem Replikat zugeordneten virtuellen CPUs ab.

vCPUs (virtuelle CPUs) Gesamter flüchtiger Speicher
0,25 oder weniger 1 GiB
0,5 oder weniger 2 GiB
1 oder weniger 4 GiB
Mehr als 1 8 GiB

Containerbezogener Speicher

Ein Container kann in sein eigenes Dateisystem schreiben.

Der Containerdateisystem-Speicher weist die folgenden Merkmale auf:

  • Der Speicher ist temporär und verschwindet, wenn der Container heruntergefahren oder neu gestartet wird.
  • Nur Prozesse, die im aktuellen Container ausgeführt werden, können Dateien sehen, die in diesen Speicher geschrieben wurden.

Replikatbezogener Speicher

Sie können ein ephemeres, temporäres Volume bereitstellen, das "EmptyDir" (leeres Verzeichnis) in Kubernetes entspricht. Dieser Speicher ist auf ein einzelnes Replikat begrenzt. Verwenden Sie ein EmptyDir-Volume, um Daten zwischen Containern im selben Replikat freizugeben.

Replikatbezogener Speicher weist die folgenden Merkmale auf:

  • Dateien bleiben für die Lebensdauer des Replikats erhalten.
    • Wenn ein Container in einem Replikat neu gestartet wird, bleiben die Dateien im Volume erhalten.
  • Alle Start- oder App-Container im Replikat können dasselbe Volume einbinden.
  • Ein Container kann mehrere EmptyDir-Volumes einbinden.

Um replikatbezogenen Speicher zu konfigurieren, definieren Sie zunächst ein EmptyDir-Volume in der Revision. Definieren Sie dann eine Volumeeinbindung in einem oder mehreren Containern in der Revision.

Voraussetzungen

Anforderung Instructions
Azure Konto Wenn Sie kein Konto besitzen, erstellen Sie kostenlos ein Konto.
Azure Container Apps Umgebung Erstellen Sie eine Container-Apps-Umgebung.

Konfiguration

Wenn Sie replikatbezogenen Speicher mithilfe des Azure CLI konfigurieren, müssen Sie eine YAML-Definition verwenden, um Ihre Container-App zu erstellen oder zu aktualisieren.

  1. Um eine vorhandene Container-Anwendung für die Verwendung des Replikat-bezogenen Speichers zu aktualisieren, exportieren Sie die Spezifikation Ihrer App in eine YAML-Datei namens app.yaml.

    az containerapp show -n <APP_NAME> -g <RESOURCE_GROUP_NAME> -o yaml > app.yaml

  2. Nehmen Sie die folgenden Änderungen an der Spezifikation Ihrer Container-App vor.

    • Fügen Sie dem Abschnitt volumes Ihrer Container-App-Definition ein template-Array hinzu, und definieren Sie ein Volume. Wenn Sie bereits über ein volumes-Array verfügen, fügen Sie dem Array ein neues Volume hinzu.
      • name ist ein Bezeichner für das Volume.
      • Verwenden Sie EmptyDir als storageType.
    • Definieren Sie für jeden Container in der Vorlage, für den Sie das Volume einbinden möchten, eine Volumeeinbindung im volumeMounts-Array der Containerdefinition.
      • volumeName ist der Name, der im volumes-Array definiert ist.
      • mountPath ist der Pfad im Container zum Einbinden des Volumes.
    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

  3. Aktualisieren Sie Ihre Container-App mithilfe der YAML-Datei.

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

Ein vollständiges Beispiel finden Sie in der YAML-Spezifikation.

Wenn Sie ein replikatbezogenes Volume erstellen und in einen Container einbinden möchten, nehmen Sie die folgenden Änderungen an der Container-App-Ressource in einer ARM-Vorlage vor:

  • Fügen Sie dem Abschnitt volumes Ihrer Container-App-Definition ein template-Array hinzu, und definieren Sie ein Volume. Wenn Sie bereits über ein volumes-Array verfügen, fügen Sie dem Array ein neues Volume hinzu.
    • name ist ein Bezeichner für das Volume.
    • Verwenden Sie EmptyDir als storageType.
  • Definieren Sie für jeden Container in der Vorlage, für den Sie das Volume einbinden möchten, eine Volumeeinbindung im volumeMounts-Array der Containerdefinition.
    • volumeName ist der Name, der im volumes-Array definiert ist.
    • mountPath ist der Pfad im Container zum Einbinden des Volumes.

ARM-Beispielvorlagenausschnitt:

{
  "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"
        }
      ]
    }
  }
}

Ein vollständiges Beispiel finden Sie in der ARM-Vorlagen-API-Spezifikation .

Um ein Volume mit Replikaten zu erstellen und es in einem Container zu mounten, stellen Sie über das Azure-Portal eine neue Revision Ihrer Container App bereit.

  1. Wechseln Sie im Azure-Portal zu Ihrer Container-App.

  2. Wählen Sie im linken Menü die Revisionsverwaltung aus.

  3. Wählen Sie " Neue Überarbeitung erstellen" aus.

  4. Wählen Sie den Container aus, in den Sie das Volume einbinden möchten.

  5. Wählen Sie im Bereich "Containerkontext bearbeiten " die Registerkarte " Volume mounts " aus.

  6. Erstellen Sie unter dem Abschnitt "Ephemeral Storage " ein neues Volume mit den folgenden Informationen:

    • Volumename: Ein Name für das kurzlebige Volume.
    • Bereitstellungspfad: Der absolute Pfad im Container zum Einbinden des Volumes

  7. Wählen Sie "Speichern" aus, um Änderungen zu speichern und den Kontextbereich zu beenden.

  8. Wählen Sie "Erstellen" aus, um die neue Überarbeitung zu erstellen.

Azure Files Volume

Sie können eine Dateifreigabe aus Azure Files als Volume in einen Container einbinden.

Important

Azure Container Apps unterstützt nur klassische Azure-Dateifreigaben, die innerhalb eines Speicherkontos (dem RessourcentypMicrosoft.Storage/storageAccounts/fileServices/shares) erstellt werden. Container Apps unterstützt den neueren Microsoft.FileShares Top-Level-Ressourcentyp nicht. Wenn du versuchst, eine Ressource Microsoft.FileShares zu mounten, schlägt die Operation fehl. Um eine unterstützte Dateifreigabe zu erstellen, siehe Eine klassische Azure-Dateifreigabe erstellen.

Azure Files Speicher weist die folgenden Merkmale auf:

  • Dateien, die unter den Einbindungsspeicherort geschrieben werden, bleiben in der Dateifreigabe erhalten.
  • Dateien in der Freigabe sind über den Einbindungsspeicherort verfügbar.
  • Mehrere Container können dieselbe Dateifreigabe einbinden, einschließlich solcher, die sich in einem anderen Replikat, einer anderen Revision oder einer anderen Container-App befinden.
  • Alle Container, die die Freigabe einbinden, können auf Dateien zugreifen, die von einem anderen Container oder einer anderen Methode geschrieben wurden.
  • Mehrere Azure Files Volume können in einem einzelnen Container bereitgestellt werden.

Azure Files unterstützt sowohl SMB-Protokolle (Server Message Block) als auch NFS (Network File System). Sie können einen Azure Files Share unter Verwendung eines der beiden Protokolle einbinden. Die Dateifreigabe, die Sie in der Umgebung definieren, muss mit demselben Protokoll konfiguriert werden, das von der Dateifreigabe im Speicherkonto verwendet wird.

Für neue SMB-Dateimounts verwenden Sie eine verwaltete Identitätsauthentifizierung (Vorschau) anstelle von Speicherkontoschlüsseln. Container Apps verwendet eine system- oder benutzerzugewiesene verwaltete Identität, die der Container Apps-Umgebung zugewiesen ist, nicht der einzelnen Container-App, um sich auf Azure Files zu authentifizieren. Dieser Modus macht es überflüssig, einen Speicherkontoschlüssel abzurufen, zu speichern oder zu rotieren. Sie müssen in der Speicherdefinition ausdrücklich die Authentifizierung einer verwalteten Identität auswählen; bestehende Schlüsselmounts für Speicherkonten bleiben weiterhin unterstützt.

Die Authentifizierung mit verwalteter Identität gilt nur für SMB-Freigaben. NFS-Shares verwenden netzwerkbasierte Zugriffskontrollen und verwenden keine SMB-Authentifizierungseinstellungen.

Um Azure Files-Speicher in Ihrem Container zu aktivieren, richten Sie Ihre Umgebung und Container-App wie folgt ein:

  • Erstellen Sie eine Speicherdefinition in der Container Apps-Umgebung.
  • Wenn Sie NFS verwenden, muss Ihre Umgebung mit einem benutzerdefinierten VNet konfiguriert werden, und das Speicherkonto muss so konfiguriert sein, dass der Zugriff über das VNet zulässig ist. Weitere Informationen finden Sie unter NFS-Dateifreigaben in Azure Files .
  • Wenn Sie NFS verwenden, darf das Speicherkonto keine verschlüsselten NFS-Verbindungen benötigen. Container-Apps unterstützen keine Verschlüsselung während der Übertragung für NFS-Dateifreigaben. Wenn die Einstellung „Require Encryption in Transit for NFS“ des Speicherkontos aktiviert ist oder wenn diese Einstellung nicht konfiguriert ist und „Secure transfer required“ aktiviert ist, schlägt der Bereitstellungsvorgang mit einem Fehler wie mount.nfs: access denied by server while mounting fehl. Weitere Informationen finden Sie unter Verschlüsselung während der Übertragung für NFS-Azure-Dateifreigaben.
  • Wenn Ihre Umgebung mit einem benutzerdefinierten VNet konfiguriert ist, müssen Sie die Ports 445 und 2049 in der Netzwerksicherheitsgruppe (NSG) zulassen, die dem Subnetz zugeordnet ist.
  • Definieren Sie ein Volume vom Typ AzureFile (SMB) oder NfsAzureFile (NFS) in einer Revision.
  • Definieren Sie eine Volumeeinbindung in einem oder mehreren Containern in der Revision.
  • Auf das verwendete Azure Files Speicherkonto muss über das virtuelle Netzwerk Ihrer Container-App zugegriffen werden kann. Weitere Informationen finden Sie unter Gewähren des Zugriffs von einem virtuellen Netzwerk.

Voraussetzungen

Anforderung Instructions
Azure Konto Wenn Sie kein Konto besitzen, erstellen Sie kostenlos ein Konto.
Azure Storage Konto Erstelle ein Speicherkonto mit einer klassischen Azure-Dateifreigabe.
Azure Container Apps Umgebung Erstellen Sie eine Container-Apps-Umgebung.
Verwaltete Identität für SMB-Authentifizierung Aktivieren Sie die systemzugewiesene verwaltete Identität der Umgebung oder weisen Sie der Umgebung eine benutzerzugewiesene verwaltete Identität zu. Siehe Umgebungsidentitäten verwalten.
Speicherkonto-Einstellungen für SMB-verwaltete Identitätsauthentifizierung Aktivieren Sie „Verwaltete Identität für SMB“ (SMBOAuth) für das Speicherkonto. Seine SMB-Sicherheitseinstellungen müssen ebenfalls Kerberos-Authentifizierung ermöglichen.
Azure RBAC für SMB verwaltete Identitätsauthentifizierung Weisen Sie der ausgewählten Umgebungsidentität die Rolle Storage File Data SMB MI Admin im Speicherkontoumfang zu. Siehe Weisen Sie der verwalteten Identität eine integrierte RBAC-Rolle zu. Um Rollen zuzuweisen, benötigen Sie die Berechtigung Microsoft.Authorization/roleAssignments/write für diesen Bereich. Planen Sie Zeit ein, damit die Rollenzuweisungen verteilt werden können, bevor Sie die Freigabe einbinden.

Konfiguration

Wenn Sie eine Container-App so konfigurieren, dass ein Azure Files Volume mithilfe von Azure CLI bereitgestellt wird, müssen Sie eine YAML-Definition verwenden, um Ihre Container-App zu erstellen oder zu aktualisieren.

Installieren Sie die neueste Azure CLI und aktualisieren Sie die Container Apps-Erweiterung:

az extension add --name containerapp --upgrade

Eine Schritt-für-Schritt-Anleitung zum Mounten einer SMB-Dateifreigabe finden Sie unter Erstellen Sie einen Azure Files Storage Mount in Azure Container Apps.

  1. Fügen Sie eine Speicherdefinition zu Ihrer Container Apps-Umgebung hinzu.

    Authentifizierung mit verwalteter Identität (empfohlen)

    Um die systemzugewiesene verwaltete Identität der Umgebung zu verwenden, aktivieren Sie sie zunächst:

    az containerapp env identity assign --name my-env --resource-group my-group \
    --system-assigned

    Verleihen Sie der Identität die Rolle Storage File Data SMB MI Admin auf Ihrem Speicherkonto und aktivieren Sie Managed Identity for SMB wie in den Voraussetzungen beschrieben. Erstellen Sie dann die Speicherdefinition:

    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

    Ersetzen Sie <STORAGE_SHARE_NAME> und <STORAGE_ACCOUNT_NAME> durch die Namen Ihres Speicherkontos und Ihrer Dateifreigabe. Mit dem Wert system wird die systemzugewiesene verwaltete Identität der Umgebung ausgewählt.

    Um stattdessen eine benutzerseitig zugewiesene verwaltete Identität zu verwenden, weisen Sie sie der Umgebung zu:

    az containerapp env identity assign --name my-env --resource-group my-group \
    --user-assigned <MANAGED_IDENTITY_RESOURCE_ID>

    Gib dieser Identität die gleiche Rolle für das Speicherkonto. Im Speicherbefehl ersetzen Sie --azure-file-identity system durch --azure-file-identity <MANAGED_IDENTITY_RESOURCE_ID>, wobei die vollständige Azure-Ressourcen-ID der Identität verwendet wird, nicht deren Client-ID oder Prinzipal-ID.

    Kombinieren Sie nicht --azure-file-identity mit --azure-file-account-key oder --azure-file-key-vault-secret-url. Diese Authentifizierungsmodi schließen sich gegenseitig aus.

    Speicherkonto-Schlüssel-Authentifizierung (Alternative)

    Wenn Sie keine verwaltete Identitätsauthentifizierung verwenden können, können Sie stattdessen einen Speicherkontoschlüssel verwenden:

    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

    Ersetzen Sie <STORAGE_ACCOUNT_NAME> und <STORAGE_ACCOUNT_KEY> durch den Namen und Schlüssel Ihres Speicherkontos. Ersetzen Sie <STORAGE_SHARE_NAME> durch den Namen der Dateifreigabe im Speicherkonto.

    Gültige Werte für --access-mode sind ReadWrite und ReadOnly.

  2. Um eine vorhandene Container-App zum Bereitstellen einer Dateifreigabe zu aktualisieren, exportieren Sie die Spezifikation Ihrer App in eine YAML-Datei mit dem Namen "app.yaml".

    az containerapp show -n <APP_NAME> -g <RESOURCE_GROUP_NAME> -o yaml > app.yaml

  3. Nehmen Sie die folgenden Änderungen an der Spezifikation Ihrer Container-App vor.

    • Fügen Sie dem Abschnitt volumes Ihrer Container-App-Definition ein template-Array hinzu, und definieren Sie ein Volume. Wenn Sie bereits über ein volumes-Array verfügen, fügen Sie dem Array ein neues Volume hinzu.
      • name ist ein Bezeichner für das Volume.
      • Verwenden Sie storageType (SMB) oder AzureFile (NFS) für NfsAzureFile. Dieser Wert muss mit dem Speichertyp übereinstimmen, den Sie in der Umgebung definiert haben.
      • Verwenden Sie für storageName den Namen des Speichers, den Sie in der Umgebung definiert haben.
      • Die mountOptions ist eine durch Trennzeichen getrennte Zeichenfolge von Bereitstellungsoptionen. Weitere Informationen finden Sie unter Verwenden von mountOptions-Einstellungen in Azure Files.
      • Die secrets Liste ist eine Liste der geheimen Schlüssel, die im Volume bereitgestellt werden sollen. Weitere Informationen finden Sie unter Mounten von Secrets in einem Volume.
    • Definieren Sie für jeden Container in der Vorlage, für den Sie Azure Files-Speicher einbinden wollen, eine Volume-Einhängung im volumeMounts-Array der Containerdefinition.
      • volumeName ist der Name, der im volumes-Array definiert ist.
      • mountPath ist der Pfad im Container zum Einbinden des Volumes.
      • Die subPath ist der Pfad im Volume, das bereitgestellt werden soll. Wenn Sie diesen Wert nicht angeben, wird das Stammverzeichnis des Volumes gemountet. Weitere Informationen finden Sie unter Unterpfad.
    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

  4. Aktualisieren Sie Ihre Container-App mithilfe der YAML-Datei.

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

Ein vollständiges Beispiel finden Sie in der YAML-Spezifikation.

Die folgenden ARM-Vorlagenausschnitte veranschaulichen, wie Sie einer Container-Apps-Umgebung eine Azure Files-Freigabe hinzufügen und in einer Container-App verwenden. Für die SMB-verwaltete Identitätsauthentifizierung aktivieren oder weisen Sie die Identität für die Umgebung zu und erfüllen Sie die Voraussetzungen für das Speicherkonto, bevor Sie die Speicherdefinition bereitstellen.

  1. Fügen Sie der Container Apps-Umgebung eine untergeordnete storages-Ressource hinzu.

    Authentifizierung mit verwalteter Identität (empfohlen)

    Erstens: Aktiviere eine verwaltete Identität auf der Ressource Microsoft.App/managedEnvironments , nicht auf der Ressource Microsoft.App/containerApps . Um die systemzugewiesene Identität der Umgebung zu aktivieren, fügen Sie Ihrer Umgebungsressource die folgende Eigenschaft auf oberster Ebene identity hinzu:

    {
  "identity": {
    "type": "SystemAssigned"
  }
}

    Füge dieses Fragment in deine bestehende Umgebungsressource ein und behalte seine andere Konfiguration bei. Verwenden Sie eine Umgebungs-API-Version, die verwaltete Identitäten unterstützt, wie zum Beispiel 2026-03-02-preview. Für das Ressourcenschema siehe Microsoft.App/managedEnvironments.

    Aktivieren Sie Managed Identity für SMB (SMBOAuth) auf dem Speicherkonto und weisen Sie der Umgebungsidentität die Rolle Storage File Data SMB MI Admin im Speicherkonto-Umfang zu, wie in den Voraussetzungen beschrieben.

    Dann verwenden Sie die API-Version 2026-03-02-preview für die Speicherressource. Legen Sie properties.azureFile.identity auf system fest, um die systemzugewiesene Identität der Umgebung auszuwählen:

    {
  "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"
    }
  }
}

    Um stattdessen eine vom Benutzer zugewiesene verwaltete Identität zu verwenden, fügen Sie sie der obersten Ebenen-Eigenschaft identity der Umgebung hinzu:

    {
  "identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "[parameters('managed_identity_resource_id')]": {}
    }
  }
}

    Definieren Sie den Parameter managed_identity_resource_id als string, der die vollständige Azure-Ressourcen-ID der Identität enthält. Setzen Sie in der Speicherressource properties.azureFile.identity auf [parameters('managed_identity_resource_id')] statt auf system. Gib dieser Identität die gleiche Rolle auf dem Speicherkonto.

    Bewahren Sie alle Identitäten, die bereits der Umgebung zugewiesen sind. Wenn du beide Identitätstypen aktivierst, nutze SystemAssigned,UserAssigned für das identity.type der Umgebung und behalte deren userAssignedIdentities-Einträge bei.

    Verwenden Sie bei der Authentifizierung mit verwalteter Identität nicht accountKey oder accountKeyVaultProperties. Informationen zum Speicherressourcenschema finden Sie unter Microsoft.App/managedEnvironments/storages.

    Speicherkonto-Schlüssel-Authentifizierung (Alternative)

    Um stattdessen einen Speicherkontoschlüssel zu verwenden, setze accountKey und lass identity weg. Definiere den Vorlagenparameter storage_account_key als 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"
    }
  }
}

    Diese Speicherschnipsel gehen davon aus, dass die Umgebung und die Dateifreigabe bereits existieren. Wenn du sie in derselben Vorlage bereitstellst, füge die Umgebungs- und Dateifreigabe-Ressourcen dem dependsOn-Array der Speicherressource hinzu. Für die Authentifizierung mit verwalteter Identität solltest du auch eine Abhängigkeit von der Rollenzuweisung hinzufügen, wenn du sie in dieser Vorlage erstellst. Eine Deployment-Abhängigkeit beseitigt keine Verzögerungen bei der Rollenzuweisung.

  2. Aktualisieren Sie die Container-App-Ressource, um ein Volume und eine Volumeeinbindung hinzuzufügen.

    Die SMB-Authentifizierung ist in der Speicherdefinition der Umgebung konfiguriert. Die Volume-Konfiguration auf App-Ebene ist für die Authentifizierung mit verwalteter Identität und Speicherkonto-Schlüssel gleich. Wenn Sie die Speicherressource und die Container-App in derselben Vorlage bereitstellen, fügen Sie die Speicherressource dem dependsOn-Array der Container-App hinzu.

    {
  "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"
        }
      ]
    }
  }
}
    • Fügen Sie dem Abschnitt volumes Ihrer Container-App-Definition ein template-Array hinzu, und definieren Sie ein Volume. Wenn Sie bereits über ein volumes-Array verfügen, fügen Sie dem Array ein neues Volume hinzu.
      • name ist ein Bezeichner für das Volume.
      • Verwenden Sie storageType (SMB) oder AzureFile (NFS) für NfsAzureFile. Dieser Wert muss mit dem Speichertyp übereinstimmen, den Sie in der Umgebung definiert haben.
      • Verwenden Sie für storageName den Namen des Speichers, den Sie in der Umgebung definiert haben.
      • Die mountOptions ist eine durch Trennzeichen getrennte Zeichenfolge von Bereitstellungsoptionen. Weitere Informationen finden Sie unter Verwenden von mountOptions-Einstellungen in Azure Files.
      • Die secrets Liste ist eine Liste der geheimen Schlüssel, die im Volume bereitgestellt werden sollen. Weitere Informationen finden Sie unter Mounten von Secrets in einem Volume.
    • Definieren Sie für jeden Container in der Vorlage, für den Sie Azure Files-Speicher einbinden wollen, eine Volume-Einhängung im volumeMounts-Array der Containerdefinition.
      • volumeName ist der Name, der im volumes-Array definiert ist.
      • mountPath ist der Pfad im Container zum Einbinden des Volumes.
      • Der subPath (optional) ist der Pfad im Volume, das bereitgestellt werden soll. Wenn Sie ihn nicht angeben, wird das Stammverzeichnis des Volumes gemountet. Weitere Informationen finden Sie unter Unterpfad.

Ein vollständiges Beispiel finden Sie in der ARM-Vorlagen-API-Spezifikation .

Um eine Volumeeinbindung für den Azure Files-Speicher im Azure-Portal zu konfigurieren, fügen Sie Ihrer Container Apps-Umgebung eine Dateifreigabe hinzu. Fügen Sie dann ihrer Container-App eine Volumeeinbindung hinzu, indem Sie eine neue Revision erstellen. Für neue SMB-Mounts wählen Sie die Authentifizierung der verwalteten Identität aus.

  1. Navigieren Sie im Azure-Portal zu Ihrer Container-Apps-Umgebung.

  2. Für die SMB-Authentifizierung mit verwalteter Identität wählen Sie Einstellungen>Identität und aktivieren Sie eine systemzugewiesene Identität oder fügen Sie der Umgebung eine benutzerzugewiesene Identität hinzu. Erfülle die in den Azure Files-Voraussetzungen beschriebenen Speicherkonto-Einstellungen und die Rollenzuweisung, bevor du die Freigabe hinzufügst.

  3. Wählen Sie im Navigationsbereich unter "Einstellungen" die Option "Volume mounts" aus.

  4. Wählen Sie "Hinzufügen" aus.

  5. Wählen Sie Server Message Block (SMB) oder Network File System (NFS) aus, je nach dem von Ihrer Dateifreigabe verwendeten Protokoll.

  6. Geben Sie im Kontextbereich " Dateifreigabe hinzufügen " die folgenden Informationen ein:

    • Name: Ein Name für die Speicherdefinition der Umgebung.
    • Name des Speicherkontos: Der Name des Speicherkontos, das die Dateifreigabe enthält.
    • Authentifizierung: Wählen Sie Verwaltete Identität (empfohlen).
    • Identität: Wählen Sie die systemzugewiesene Identität der Umgebung oder eine der Umgebung aus der Liste verwalteter Identitäten zugewiesene benutzerzugewiesene Identität aus. Wählen Sie die Identität aus, die die Rolle Storage File Data SMB MI Admin auf dem Speicherkonto hat.
    • Dateifreigabename: Der Name der SMB-Dateifreigabe.
    • Access-Modus: Der Zugriffsmodus für die Dateifreigabe. Gültige Werte sind "Lese-/Schreibzugriff " und "Schreibgeschützt".

    Um stattdessen die Authentifizierung des Speicherkontoschlüssels zu verwenden, wählen Sie unter Authentifizierung den Speicherkontoschlüssel und geben Sie den Zugangsschlüssel des Speicherkontos ein. Wählen Sie eine Authentifizierungsmethode für die Speicherdefinition.

  7. Wählen Sie "Hinzufügen" aus, um den Kontextbereich zu beenden.

  8. Wählen Sie "Speichern" aus, um die Änderungen zu übernehmen.

  9. Wechseln Sie zu Ihrer Container-App.

  10. Wählen Sie im Navigationsbereich unter "Anwendung" die Option "Überarbeitungen" und "Replikate" aus.

  11. Wählen Sie " Neue Überarbeitung erstellen" aus.

  12. Wählen Sie auf der Seite " Neue Überarbeitung erstellen und bereitstellen " die Registerkarte "Volumes " aus.

  13. Wählen Sie "Hinzufügen" aus.

  14. Legen Sie im Kontextbereich 'Volume hinzufügen' die folgenden Werte fest.

    • Volumetyp: Azure-Dateivolume.
    • Name: Geben Sie einen Volumenamen ein.
    • Dateifreigabename: Wählen Sie die zuvor erstellte Dateifreigabe aus.
    • Bereitstellungsoptionen: Geben Sie optional eine durch Trennzeichen getrennte Zeichenfolge der Bereitstellungsoptionen ein. Weitere Informationen finden Sie unter Verwenden von mountOptions-Einstellungen in Azure Files.

  15. Wählen Sie "Hinzufügen" aus, um den Kontextbereich zu beenden.

  16. Wählen Sie auf der Seite „Neue Revision erstellen und bereitstellen“ die Registerkarte Container aus.

  17. Wählen Sie den Container aus, in den Sie das Volume einbinden möchten.

  18. Wählen Sie im Bereich "Containerkontext bearbeiten " die Registerkarte " Volume mounts " aus.

  19. Wählen Sie unter "Volumename" das Volume aus, das Sie zuvor erstellt haben.

  20. Geben Sie unter Bereitstellungspfad den absoluten Pfad im Container zum Einbinden des Volumes ein.

  21. Geben Sie im Unterpfad (optional)den Pfad in das Volume ein, das bereitgestellt werden soll. Wenn Sie diesen Wert nicht angeben, wird das Stammverzeichnis des Volumes gemountet. Weitere Informationen finden Sie unter Unterpfad.

  22. Wählen Sie "Speichern" aus, um Änderungen zu speichern und den Kontextbereich zu beenden.

  23. Wählen Sie "Erstellen" aus, um die neue Überarbeitung zu erstellen.

Unterpfad

Wenn Sie eine Dateifreigabe von Azure Files mounten, können Sie sowohl einen Einhängepfad als auch einen Unterpfad angeben.

  • Einbindungspfad: Der Pfad im Container, an dem Sie das Volume einbinden möchten.
  • Unterpfad: Der Pfad im Volume, das Sie bereitstellen möchten.

Der Unterpfad ist optional. Wenn Sie keinen Unterpfad angeben, wird das Stammverzeichnis des Volumes gemountet.

Der Unterpfad ist ein relativer Pfad aus dem Volumestamm. Starten Sie den Unterpfad nicht mit /. Wenn Sie einen Unterpfad angeben, der mit /beginnt, wird die Container-App möglicherweise nicht gestartet. Zum Beispiel ist my-volume-folder ein gültiger Unterpfad, aber /my-volume-folder nicht.

Der Unterpfad kann entweder auf einen Ordner oder eine Datei im Volume verweisen.

  • Wenn sich der Unterpfad auf einen Ordner bezieht, sollte der Bereitstellungspfad auf einen leeren Ordner im Container verweisen.

  • Wenn sich der Unterpfad auf eine Datei bezieht, sollte der Bereitstellungspfad auf eine Datei verweisen, die noch nicht im Container vorhanden ist.

    Angenommen, der Unterpfad ist my-volume-folder/my-volume-file.txt, und der Montagepfad ist /my-container-folder/my-container-file.txt. Der Ordner /my-container-folder sollte bereits im Container vorhanden sein, aber die Datei my-container-file.txtnoch nicht enthalten.

Das System ignoriert alle Schrägstriche am Ende des Unterpfades.

Verwandte Inhalte

  • Zuletzt aktualisiert um