Freigeben über

Erstellen eines Containers

Der Create Container Vorgang erstellt einen neuen Container unter dem angegebenen Konto. Wenn der Container mit demselben Namen bereits vorhanden ist, schlägt der Vorgang fehl.

Die Containerressource enthält Metadaten und Eigenschaften für diesen Container. Eine Liste der Blobs im Container ist nicht enthalten.

Anfrage

Sie können die Create Container Anforderung wie hier gezeigt erstellen. Wir empfehlen Ihnen, HTTPS zu verwenden. Der Name Ihres Containers darf nur Kleinbuchstaben enthalten und muss diesen Benennungsregeln entsprechen. Ersetzen Sie in der URL myaccount durch den Namen Ihres Speicherkontos.

Methode Anforderungs-URI HTTP-Version
PUT https://myaccount.blob.core.windows.net/mycontainer?restype=container HTTP/1.1

Serviceanforderung für emulierten Speicher

Wenn Sie eine Anforderung an den emulierten Speicherdienst senden, geben Sie den Hostnamen des Emulators und den Blob Storage-Port als 127.0.0.1:10000an, gefolgt vom Namen des emulierten Speicherkontos.

Methode Anforderungs-URI HTTP-Version
PUT http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container HTTP/1.1

Weitere Informationen finden Sie unter Verwenden des Azurite-Emulators für die lokale Azure Storage-Entwicklung.

URI-Parameter

Sie können die folgenden zusätzlichen Parameter für den Anforderungs-URI angeben.

Parameter Description
timeout Wahlfrei. Der timeout Parameter wird in Sekunden ausgedrückt. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blob Storage-Vorgänge.

Anforderungsheader

Die erforderlichen und optionalen Anforderungsheader werden in der folgenden Tabelle beschrieben:

Anforderungs-Kopfzeile Description
Authorization Erforderlich. Gibt das Autorisierungsschema, den Kontonamen und die Signatur an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
Date oder x-ms-date Erforderlich. Gibt die UTC-Zeit (Coordinated Universal Time) für die Anforderung an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
x-ms-version Erforderlich für alle autorisierten Anfragen. Gibt die Version des Vorgangs an, die für diese Anforderung verwendet werden soll. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure Storage-Dienste.
x-ms-meta-name:value Wahlfrei. Ein Name-Wert-Paar, das dem Container als Metadaten zugeordnet werden soll. Hinweis: Ab Version 2009-09-19 müssen Metadatennamen den Benennungsregeln für C#-Bezeichner entsprechen.
x-ms-blob-public-access Wahlfrei. Gibt an, ob auf Daten im Container öffentlich zugegriffen werden kann, und auf welcher Zugriffsebene Sie zugreifen können. Mögliche Werte sind:

- container: Gibt vollständigen öffentlichen Lesezugriff für Container- und Blobdaten an. Clients können Blobs innerhalb des Containers über eine anonyme Anforderung auflisten, aber sie können keine Container innerhalb des Speicherkontos auflisten.
- blob: Gibt öffentlichen Lesezugriff für Blobs an. Blobdaten in diesem Container können über eine anonyme Anforderung gelesen werden, Containerdaten sind jedoch nicht verfügbar. Clients können Blobs innerhalb des Containers nicht über eine anonyme Anforderung auflisten.

Wenn dieser Header nicht in der Anforderung enthalten ist, sind die Containerdaten für den Kontobesitzer privat.
x-ms-client-request-id Wahlfrei. Stellt einen vom Client generierten, undurchsichtigen Wert mit einer Zeichenbeschränkung von 1 Kibibyte (KiB) bereit, der in den Protokollen aufgezeichnet wird, wenn die Protokollierung konfiguriert wird. Es wird dringend empfohlen, diesen Header zu verwenden, um clientseitige Aktivitäten mit Anforderungen zu korrelieren, die der Server empfängt. Weitere Informationen finden Sie unter Überwachen von Azure Blob Storage.

Anforderungsheader (Verschlüsselungsbereiche)

Ab Version 2019-02-02 können Sie die folgenden Header in einer Anforderung angeben, um einen Standardverschlüsselungsbereich für einen Container festzulegen. Wenn Sie einen Verschlüsselungsbereich festlegen, wird er automatisch verwendet, um alle Blobs zu verschlüsseln, die in den Container hochgeladen werden.

Anforderungs-Kopfzeile Description
x-ms-default-encryption-scope Erforderlich. Der Verschlüsselungsbereich, der als Standard für den Container festgelegt werden soll.
x-ms-deny-encryption-scope-override Erforderlich. Werte sind true oder false. Durch Festlegen dieses Headers true wird sichergestellt, dass jedes Blob, das in diesen Container hochgeladen wird, den Standardverschlüsselungsbereich verwendet. Wenn dieser Header auf falseist, kann ein Client ein Blob mit einem anderen Verschlüsselungsbereich als dem Standardbereich hochladen.

Von Bedeutung

Wenn ein Container auf truefestgelegt wurdex-ms-deny-encryption-scope-override, sind Aktualisierungen von Blobs, die nicht über einen Verschlüsselungsbereich oder vom Kunden bereitgestellte Verschlüsselungsschlüssel verfügen, in diesem Container nicht zulässig. Diese Blobs bleiben lesbar, und Benutzer können Blobs aus dem Container in ein Blob ohne Außerkraftsetzungsrichtlinie für den Verschlüsselungsbereich verschieben, um Aktualisierungen durchzuführen.

Anfragekörper

Keiner.

Musteranforderung

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer?restype=container HTTP/1.1  
  
Request Headers:  
x-ms-version: 2011-08-18  
x-ms-date: Sun, 25 Sep 2011 22:50:32 GMT  
x-ms-meta-Name: StorageSample  
Authorization: SharedKey myaccount:Z5043vY9MesKNh0PNtksNc9nbXSSqGHueE00JdjidOQ=

Antwort

Die Antwort enthält einen HTTP-Statuscode und eine Reihe von Antwortheadern.

Statuscode

Ein erfolgreicher Vorgang gibt den Statuscode 201 (Erstellt) zurück.

Weitere Informationen zu Statuscodes finden Sie unter Status- und Fehlercodes.

Antwortkopfzeilen

Die Antwort für diesen Vorgang enthält die Header, die in der folgenden Tabelle beschrieben werden. Die Antwort kann auch zusätzliche standardmäßige HTTP-Header enthalten. Alle Standard-Header entsprechen der HTTP/1.1-Protokollspezifikation.

Antwortheader Description
ETag Das ETag für den Container. Wenn die Anforderungsversion 2011-08-18 oder höher ist, wird der ETag-Wert in Anführungszeichen gesetzt.
Last-Modified Gibt das Datum und die Uhrzeit zurück, zu der der Container zuletzt geändert wurde. Das Datumsformat folgt RFC 1123. Weitere Informationen finden Sie unter Darstellung von Datums-/Uhrzeitwerten in Kopfzeilen.

Jeder Vorgang, der den Container oder seine Eigenschaften oder Metadaten ändert, aktualisiert den Zeitpunkt der letzten Änderung. Vorgänge für Blobs wirken sich nicht auf den Zeitpunkt der letzten Änderung des Containers aus.
x-ms-request-id Identifiziert die Anforderung, die gestellt wurde, eindeutig. Sie können es verwenden, um Probleme mit der Anforderung zu beheben. Weitere Informationen finden Sie unter Problembehandlung bei API-Vorgängen
x-ms-version Gibt die Blob Storage-Version an, die zum Ausführen der Anforderung verwendet wird. Dieser Header wird für Anforderungen zurückgegeben, die für Version 2009-09-19 oder höher gestellt werden.
Date Der vom Dienst generierte UTC-Wert für Datum/Uhrzeit, der den Zeitpunkt angibt, zu dem die Antwort initiiert wurde.
x-ms-client-request-id Kann zur Fehlerbehebung von Anforderungen und entsprechenden Antworten verwendet werden. Der Wert dieses Headers entspricht dem Wert des Headers x-ms-client-request-id , wenn er in der Anforderung vorhanden ist und der Wert nicht mehr als 1024 sichtbare ASCII-Zeichen enthält. Wenn der x-ms-client-request-id Header in der Anforderung nicht vorhanden ist, ist der Header in der Antwort nicht vorhanden.

Antwortkörper

Keiner.

Beispielantwort

Response status:  
HTTP/1.1 201 Created  
  
Response headers:  
Transfer-Encoding: chunked  
Date: Sun, 25 Sep 2011 23:00:12 GMT  
ETag: “0x8CB14C3E29B7E82”  
Last-Modified: Sun, 25 Sep 2011 23:00:06 GMT  
x-ms-version: 2011-08-18  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Autorisierung

Eine Autorisierung ist erforderlich, wenn ein Datenzugriffsvorgang in Azure Storage aufgerufen wird. Sie können den Create Container Vorgang wie unten beschrieben autorisieren.

Von Bedeutung

Microsoft empfiehlt die Verwendung der Microsoft Entra ID mit verwalteten Identitäten, um Anforderungen an Azure Storage zu autorisieren. Microsoft Entra ID bietet im Vergleich zur Autorisierung mit gemeinsam verwendeten Schlüsseln überlegene Sicherheit und Benutzerfreundlichkeit.

Azure Storage unterstützt die Verwendung der Microsoft Entra-ID zum Autorisieren von Anforderungen an BLOB-Daten. Mit Microsoft Entra ID können Sie die rollenbasierte Zugriffssteuerung von Azure (Azure RBAC) verwenden, um einem Sicherheitsprinzipal Berechtigungen zu erteilen. Bei dem Sicherheitsprinzipal kann es sich um einen Benutzer, eine Gruppe, einen Anwendungsdienstprinzipal oder eine verwaltete Azure-Identität handeln. Der Sicherheitsprinzipal wird von Microsoft Entra ID authentifiziert, und gibt ein OAuth 2.0-Token zurück. Das Token kann dann verwendet werden, um eine Anforderung gegen den Blob-Dienst zu autorisieren.

Weitere Informationen zur Autorisierung mit Microsoft Entra ID finden Sie unter Autorisieren des Zugriffs auf Blobs mit Microsoft Entra ID.

Erlaubnisse

Im Folgenden sind die RBAC-Aktion aufgeführt, die erforderlich ist, damit ein Microsoft Entra-Benutzer, eine Gruppe, eine verwaltete Identität oder ein Dienstprinzipal den Create Container Vorgang aufrufen kann, sowie die integrierte Azure RBAC-Rolle mit den geringsten Berechtigungen, die diese Aktion umfasst:

Weitere Informationen zum Zuweisen von Rollen mithilfe von Azure RBAC finden Sie unter Zuweisen einer Azure-Rolle für den Zugriff auf Blobdaten.

Bemerkungen

Container werden sofort im Speicherkonto erstellt. Es ist nicht möglich, einen Container in einem anderen zu schachteln.

Optional können Sie einen Standard- oder Stammcontainer für Ihr Speicherkonto erstellen. Der Stammcontainer ermöglicht es, auf der obersten Ebene der Speicherkontohierarchie auf ein Blob zu verweisen, ohne auf den Containernamen zu verweisen.

Um den Stammcontainer zu Ihrem Speicherkonto hinzuzufügen, erstellen Sie einen Container mit dem Namen $root. Erstellen Sie die Anforderung wie folgt:

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/$root?restype=container HTTP/1.1  
  
Request Headers:  
x-ms-version: 2011-08-18  
x-ms-date: Sun, 25 Sep 2011 22:50:32 GMT  
x-ms-meta-Name: StorageSample  
Authorization: SharedKey myaccount:Z5043vY9MesKNh0PNtksNc9nbXSSqGHueE00JdjidOQ=

Sie können Metadaten für einen Container angeben, wenn Sie ihn erstellen, indem Sie einen oder mehrere Metadatenheader in die Anforderung einschließen. Das Format für den Metadaten-Header ist x-ms-meta-name:value.

Wenn beim Aufruf ein Container mit demselben Namen gelöscht Create Container wird, gibt der Server den Statuscode 409 (Konflikt) zurück und stellt zusätzliche Fehlerinformationen bereit, die darauf hinweisen, dass der Container gelöscht wird.

Abrechnung

Preisanforderungen können von Clients stammen, die Blob Storage-APIs verwenden, entweder direkt über die Blob Storage-REST-API oder aus einer Azure Storage-Clientbibliothek. Für diese Anfragen fallen Gebühren pro Transaktion an. Die Art der Transaktion wirkt sich darauf aus, wie das Konto belastet wird. Lesetransaktionen werden z. B. in einen anderen Abrechnungstyp abgerechnet als Schreibtransaktionen. In der folgenden Tabelle ist die Abrechnungskategorie für Anforderungen basierend auf Create Container dem Speicherkontotyp aufgeführt:

Operation Speicherkontotyp Kategorie der Abrechnung
Erstellen eines Containers Premium-Blockblob
Standard für allgemeinen Zwecke v2
Standard-Allzweck v1		 Auflisten und Erstellen von Containervorgängen

Weitere Informationen zu den Preisen für die angegebene Abrechnungskategorie finden Sie unter Azure Blob Storage – Preise.

Siehe auch

Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Blob Storage-Fehlercodes
Benennen und Verweisen auf Container, Blobs und Metadaten
Festlegen und Abrufen von Eigenschaften und Metadaten für Blobressourcen
Festlegen der Container-ACL

  • Last updated on