Partager via

Create Container

  • Article

L'opération Create Container crée un nouveau conteneur sous le compte spécifié. Si un conteneur portant le même nom existe déjà, l'opération échoue.

La ressource de conteneur inclut les métadonnées et les propriétés pour ce conteneur. Il n’inclut pas de liste des objets blob dans le conteneur.

Requête

Vous pouvez construire la Create Container requête comme indiqué ici. Nous vous recommandons d’utiliser HTTPS. Le nom de votre conteneur ne peut inclure que des caractères minuscules et doit suivre ces règles de nommage. Dans l’URL, remplacez myaccount par le nom de votre compte de stockage.

Méthode URI de demande Version HTTP
PUT https://myaccount.blob.core.windows.net/mycontainer?restype=container HTTP/1.1

Demande de service de stockage émulée

Lorsque vous effectuez une requête auprès du service de stockage émulé, spécifiez le nom d’hôte de l’émulateur et le port Stockage Blob comme 127.0.0.1:10000, suivi du nom du compte de stockage émulé.

Méthode URI de demande Version HTTP
PUT http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container HTTP/1.1

Pour plus d’informations, consultez Utiliser l’émulateur Azurite à des fins de développement local pour Stockage Azure.

Paramètres URI

Vous pouvez spécifier les paramètres supplémentaires suivants sur l’URI de requête.

Paramètre Description
timeout facultatif. Le paramètre timeout est exprimé en secondes. Pour plus d’informations, consultez Définir des délais d’attente pour les opérations de stockage Blob.

En-têtes de requête

Les en-têtes de requête obligatoires et facultatifs sont décrits dans le tableau suivant :

En-tête de requête Description
Authorization Obligatoire. Spécifie le schéma d’autorisation, le nom du compte et la signature. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure.
Date ou x-ms-date Obligatoire. Spécifie l'heure UTC (temps universel coordonné) pour la demande. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure.
x-ms-version Obligatoire pour toutes les demandes autorisées. Spécifie la version de l'opération à utiliser pour cette demande. Pour plus d'informations, consultez la page Contrôle de version pour les services de Stockage Microsoft Azure.
x-ms-meta-name:value facultatif. Une paire nom-valeur à associer au conteneur en tant que métadonnées. Remarque : À partir de la version 2009-09-19, les noms de métadonnées doivent respecter les règles de nommage des identificateurs C#.
x-ms-blob-public-access facultatif. Spécifie si les données du conteneur sont accessibles publiquement et le niveau d’accès. Les valeurs possibles incluent :

- container: spécifie l’accès en lecture public complet pour les données de conteneur et d’objets blob. Les clients peuvent énumérer des objets blob dans le conteneur via une demande anonyme, mais ils ne peuvent pas énumérer les conteneurs dans le compte de stockage.
- blob: Spécifie l’accès en lecture public pour les objets blob. Les données d’objets blob dans ce conteneur peuvent être lues via une demande anonyme, mais les données de conteneur ne sont pas disponibles. Les clients ne peuvent pas énumérer d’objets blob dans le conteneur via une demande anonyme.

Si cet en-tête n’est pas inclus dans la demande, les données de conteneur sont privées pour le propriétaire du compte.
x-ms-client-request-id facultatif. Fournit une valeur opaque générée par le client avec une limite de caractères de 1 kibioctet (Kio) enregistrée dans les journaux lors de la configuration de la journalisation. Nous vous recommandons vivement d’utiliser cet en-tête pour mettre en corrélation les activités côté client avec les demandes reçues par le serveur. Pour plus d’informations, consultez Surveiller Stockage Blob Azure.

En-têtes de requête (étendues de chiffrement)

À partir de la version 2019-02-02, vous pouvez spécifier les en-têtes suivants sur une demande de définition d’une étendue de chiffrement par défaut sur un conteneur. Si vous définissez une étendue de chiffrement, elle est automatiquement utilisée pour chiffrer tous les objets blob chargés dans le conteneur.

En-tête de requête Description
x-ms-default-encryption-scope Obligatoire. Étendue de chiffrement à définir comme valeur par défaut sur le conteneur.
x-ms-deny-encryption-scope-override Obligatoire. Valeurs possibles : true ou false. La définition de true cet en-tête sur garantit que chaque objet blob chargé dans ce conteneur utilise l’étendue de chiffrement par défaut. Lorsque cet en-tête est false, un client peut charger un objet blob avec une étendue de chiffrement autre que l’étendue par défaut.

Corps de la demande

Aucun.

Exemple de requête

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=

response

La réponse inclut un code d'état HTTP et un ensemble d'en-têtes de réponse.

Code d’état

Une opération réussie renvoie le code d'état 201 (Créé).

Pour plus d’informations sur les codes status, consultez État et codes d’erreur.

En-têtes de réponse

La réponse à cette opération inclut les en-têtes décrits dans le tableau suivant. La réponse peut également inclure des en-têtes HTTP standard supplémentaires. Tous les en-têtes standard sont conformes à la spécification du protocole HTTP/1.1.

En-tête de réponse Description
ETag L'ETag du conteneur. Si la version de la demande est 2011-08-18 ou version ultérieure, la valeur ETag est placée entre guillemets.
Last-Modified Retourne la date et l’heure de la dernière modification du conteneur. Le format de date est conforme à la RFC 1123. Pour plus d’informations, consultez Représentation des valeurs de date/heure dans les en-têtes.

N'importe quelle opération qui modifie le conteneur ou ses propriétés ou métadonnées met à jour l'heure de la dernière modification. Les opérations sur les objets blob n'affectent pas l'heure de la dernière modification du conteneur.
x-ms-request-id Identifie de manière unique la demande qui a été effectuée. Vous pouvez l’utiliser pour résoudre les problèmes liés à la demande. Pour plus d’informations, consultez Résoudre les problèmes liés aux opérations d’API
x-ms-version Indique la version du stockage Blob utilisée pour exécuter la demande. Cet en-tête est retourné pour les demandes effectuées sur la version 2009-09-19 ou ultérieure.
Date Valeur de date/heure UTC générée par le service, qui indique l’heure à laquelle la réponse a été lancée.
x-ms-client-request-id Peut être utilisé pour résoudre les demandes et les réponses correspondantes. La valeur de cet en-tête est égale à la valeur de l’en-tête x-ms-client-request-id s’il est présent dans la demande et que la valeur ne contient pas plus de 1 024 caractères ASCII visibles. Si l’en-tête x-ms-client-request-id n’est pas présent dans la demande, l’en-tête n’est pas présent dans la réponse.

Response body

Aucun.

Exemple de réponse

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

Autorisation

Une autorisation est requise lors de l’appel d’une opération d’accès aux données dans Stockage Azure. Vous pouvez autoriser l’opération Create Container comme décrit ci-dessous.

Important

Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour autoriser les demandes à Stockage Azure. Microsoft Entra ID offre une sécurité et une facilité d’utilisation supérieures par rapport à l’autorisation de clé partagée.

Stockage Azure prend en charge l’utilisation de Microsoft Entra ID pour autoriser les demandes de données blob. Avec Microsoft Entra ID, vous pouvez utiliser le contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour accorder des autorisations à un principal de sécurité. Le principal de sécurité peut être un utilisateur, un groupe, un principal de service d’application ou une identité managée Azure. Le principal de sécurité est authentifié par Microsoft Entra ID pour retourner un jeton OAuth 2.0. Le jeton peut ensuite être utilisé pour autoriser une requête auprès du service BLOB.

Pour en savoir plus sur l’autorisation à l’aide de Microsoft Entra ID, consultez Autoriser l’accès aux objets blob à l’aide de Microsoft Entra ID.

Autorisations

Vous trouverez ci-dessous l’action RBAC nécessaire pour qu’un utilisateur, un groupe, une identité managée ou un principal de service Microsoft Entra appelle l’opérationCreate Container, ainsi que le rôle RBAC Azure intégré le moins privilégié qui inclut cette action :

Pour en savoir plus sur l’attribution de rôles à l’aide d’Azure RBAC, consultez Attribuer un rôle Azure pour l’accès aux données d’objets blob.

Remarques

Les conteneurs sont créés immédiatement dans le compte de stockage. Il n’est pas possible d’imbriquer un conteneur dans un autre.

Vous pouvez éventuellement créer un conteneur racine ou par défaut pour votre compte de stockage. Le conteneur racine permet de référencer un objet blob à partir du niveau supérieur de la hiérarchie de compte de stockage, sans référencer le nom de conteneur.

Pour ajouter le conteneur racine à votre compte de stockage, créez un conteneur appelé $root. Construisez la demande comme suit :

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=

Vous pouvez spécifier des métadonnées pour un conteneur lorsque vous le créez en incluant un ou plusieurs en-têtes de métadonnées sur la demande. Le format de l'en-tête de métadonnées est x-ms-meta-name:value.

Si un conteneur du même nom est supprimé lorsqu’il Create Container est appelé, le serveur retourne status code 409 (Conflit) et fournit des informations d’erreur supplémentaires indiquant que le conteneur est en cours de suppression.

Facturation

Les demandes de tarification peuvent provenir de clients qui utilisent des API Stockage Blob, soit directement via l’API REST Stockage Blob, soit à partir d’une bibliothèque cliente stockage Azure. Ces demandes cumulent des frais par transaction. Le type de transaction affecte la façon dont le compte est facturé. Par exemple, les transactions de lecture sont comptabilisées dans une catégorie de facturation différente de celle des transactions en écriture. Le tableau suivant montre la catégorie de facturation pour Create Container les demandes en fonction du type de compte de stockage :

Opération Type de compte de stockage Catégorie de facturation
Create Container Objet blob de blocs Premium
Usage général v2 Standard
Usage général v1 standard		 Répertorier et Create opérations de conteneur

Pour en savoir plus sur la tarification de la catégorie de facturation spécifiée, consultez Stockage Blob Azure Tarification.

Voir aussi

Autoriser les demandes à Stockage Azure
Codes d’état et d’erreur
Codes d’erreur Stockage Blob
Conteneurs de noms et de référence, objets blob et métadonnées
Définir et récupérer des propriétés et des métadonnées pour les ressources d’objets blob
Set Container ACL