API REST COSMOS DB POUR PostgreSQL

Azure Cosmos DB pour Postgres est une base de données SQL distribuée native du cloud entièrement gérée pour les applications transactionnelles.

Les API REST (Resource Provider Representational State Transfer) vous permettent de gérer vos ressources Azure Cosmos DB par programmation. Les principales catégories prises en charge sont les suivantes :

  • Déployer, gérer ou promouvoir un cluster.
  • Gérer les configurations de nœud coordinateur \ Worker.
  • Gérer les règles de pare-feu.
  • Gérez les connexions de points de terminaison privés et les ressources de liaison privée.
  • Gérer les rôles.

Autorisation

Pour réussir, tous les appels REST Azure Resource Manager ont besoin d’un jeton d’autorisation valide dans l’en-tête de la demande. Pour plus d’informations sur l’obtention de ce jeton d’autorisation, consultez Créer la demande : Acquérir un jeton d’accès .

Comment faire des appels d’API REST

Il existe plusieurs façons d’effectuer des appels d’API REST pour n’importe quel service Azure, y compris Azure Cosmos DB pour PostgreSQL. Vous pouvez utiliser Postman comme l’outil polyvalent le plus universel pour les appels d’API REST. Vous pouvez également utiliser curl pour d’autres scénarios, y compris des scripts sans assistance tels que ceux utilisés dans l’automatisation DevOps. Vous pouvez également utiliser « az rest » comme moyen simple d’effectuer des appels d’API REST à partir d’Azure CLI.

Espaces réservés et valeurs

Les informations suivantes sont communes à toutes les tâches que vous pouvez effectuer à l’aide de ces API REST :

  • Remplacez-la {api-version} par la dernière version d’API disponible , telle que 2022-11-08.
  • Remplacez-le {subscriptionId} par votre identificateur d’abonnement dans l’URI. Cette valeur est un GUID unique à votre abonnement, par exemple 6B29FC40-CA47-1067-B31D-00DD010662DA. Recherchez l’ID d’abonnement à l’aide du panneau Abonnements au portail Azure.
  • Remplacez par {resourceGroupName} le groupe de ressources. Pour plus d’informations, consultez Utilisation de groupes de ressources pour gérer vos ressources Azure.
  • Remplacez-le {clusterName} par le nom de votre cluster Azure Cosmos DB pour PostgreSQL. Utilisez le nom abrégé, par exemple mydemocluster.
  • Définissez l’en-tête Content-Type sur application/json.
  • Définissez l’en-tête Authorization sur un jeton web JSON que vous obtenez à partir d’Azure Active Directory. Pour plus d’informations, consultez la section Autorisation.

Valeurs

Utilisez la référence suivante pour déterminer les valeurs prises en charge pour divers appels d’API REST pour les clusters et les nœuds Azure Cosmos DB pour PostgreSQL.

Création et mise à jour du cluster

  • properties.postgresqlVersion : version majeure de PostgreSQL sur tous les nœuds de votre cluster. Spécifiez une version majeure de PostgreSQL prise en charge. Par exemple, « 15 ». Consultez la liste des versions de Postgres prises en charge. Le cluster est créé avec la dernière version mineure de PostgreSQL et la dernière version correspondante de Citus disponible dans la région sélectionnée.
  • properties.citusVersion : version de l’extension Citus installée sur tous les nœuds de votre cluster. Par exemple, « 11.3 ». Voir la version Citus actuellement prise en charge.
    • Cette propriété est facultative pour un nouveau provisionnement de cluster. Si cette propriété est omise, la dernière version de Citus prise en charge pour la version majeure de PostgreSQL spécifiée est installée.
    • Le cas principal de cette propriété est la mise à niveau de la version de Citus telle que 11.0 vers 11.3. Lorsqu’une version mise à jour de Citus est publiée pour la version majeure de PostgreSQL sur votre cluster, vous pouvez utiliser l’appel d’API de mise à jour de cluster pour mettre à niveau uniquement la version de Citus vers la dernière version prise en charge pour la version majeure actuelle de PostgreSQL.
  • properties.administratorLoginPassword : Mot de passe pour le rôle 'citus' sur tous les nœuds de votre cluster. Le mot de passe doit répondre aux exigences suivantes
    • Longueur : Au moins 8 caractères et au maximum 128 caractères
    • Complexité : Doit contenir des caractères de chacune des catégories suivantes :
      • Lettres majuscules de l’alphabet anglais
      • Lettres minuscules de l’alphabet
      • Nombres (0-9)
      • Caractères non alphanumériques ( !, $, #, %, etc.)
    • Nom du rôle dans le mot de passe : ne peut pas contenir tout ou partie du nom du rôle. Une partie d’un nom de rôle est définie par au moins trois caractères alphanumériques consécutifs
  • properties.coordinatorServerEdition : type de calcul dans le coordinateur d’un cluster à nœud unique ou à plusieurs nœuds. Utilisez les valeurs suivantes pour le calcul à nœud unique et à plusieurs nœuds pris en charge
    • Nœud unique
      • Extensible, 1 vCore : ExtensibleMémoire optimisée
      • Burstable, 2 vCores : ExtensibleGeneralPurpose
      • Non extensible, tous les vCores pris en charge : GeneralPurpose
    • Multi-nœuds
      • Non extensible, tous les vCores pris en charge : GeneralPurpose
  • properties.coordinatorVCores : nombre de vCores de calcul dans le coordinateur d’un cluster à nœud unique ou à plusieurs nœuds. Voir les valeurs prises en charge sur cette page.
  • properties.coordinatorStorageQuotaInMb : taille de stockage en Mio sur un seul nœud ou sur le coordinateur dans un cluster à plusieurs nœuds. Consultez Tailles de stockage prises en charge pour les configurations à nœud unique et à plusieurs nœuds. Par exemple, pour spécifier 128 Gio de stockage, utilisez la valeur « 131072 » (128 Gio * 1024 = 131072 Mio).
  • properties.nodeServerEdition : type de calcul dans les nœuds de travail. Seule la valeur « MemoryOptimized » est prise en charge.
  • properties.nodeVCores : nombre de vCores de calcul dans chaque nœud de travail d’un cluster à plusieurs nœuds. Voir les valeurs prises en charge sur cette page.
  • properties.nodeStorageQuotaInMb : taille de stockage en Mio sur un nœud de travail dans un cluster à plusieurs nœuds. Consultez les tailles de stockage prises en charge et les configurations à plusieurs nœuds. Par exemple, pour spécifier 2 Tio de stockage, utilisez la valeur « 2097152 » (2 Tio * 1024 = 2048 Gio * 1024 = 2097152 Mio).
  • properties.coordinatorEnablePublicIpAccess : lorsqu’elle est définie sur « False », cette propriété désactive l’accès public au coordinateur de cluster.
  • properties.nodeEnablePublicIpAccess : la valeur par défaut de cette propriété est « false », ce qui désactive l’accès public direct aux nœuds de travail. Pour activer l’accès direct facultatif aux nœuds de travail dans les clusters à plusieurs nœuds, vous devez définir cette propriété sur « True » et créer des règles de pare-feu pour ces adresses IP publiques. Toutes les règles de pare-feu s’appliquent au coordinateur et à tous les nœuds de travail.

Création d’une règle de pare-feu

  • properties.startIpAddress et properties.endIpAddress
    • Pour créer une règle de pare-feu pour une seule adresse IP publique, spécifiez cette adresse IP comme valeur pour startIpAddress et endIpAddress.
    • Pour autoriser les connexions à partir de n’importe quelle adresse IP gérée par Azure, spécifiez « 0.0.0.0 » pour les valeurs startIpAddress et endIpAddress. Notez que cette règle de pare-feu autorise les connexions à partir des abonnements Azure d’autres clients.

Création de rôle

  • properties.password : mot de passe pour le rôle Postgres à créer sur tous les nœuds de votre cluster. Le mot de passe doit répondre aux exigences suivantes
    • Longueur : Au moins 8 caractères et au maximum 128 caractères
    • Complexité : Doit contenir des caractères de chacune des catégories suivantes :
      • Lettres majuscules de l’alphabet anglais
      • Lettres minuscules de l’alphabet
      • Nombres (0-9)
      • Caractères non alphanumériques ( !, $, #, %, etc.)
    • Nom du rôle dans le mot de passe : ne peut pas contenir tout ou partie du nom du rôle. Une partie d’un nom de rôle est définie par au moins trois caractères alphanumériques consécutifs
  • Last updated on