API dans le cloud (CAPI)
L’API dans le cloud (CAPI) vous permet d’intégrer Mise en service et gouvernance du cloud des fournisseurs dans le cloud à l’aide d’API REST.
Composants CAPI
L’intégration avec les fournisseurs dans le cloud s’effectue par le biais d’appels REST, tels que PUT, GET, POST et DELETE. CAPI fournit le cadre de travail pour vous permettre d’intégrer une API REST de fournisseurs dans le cloud afin que votre instance puisse communiquer avec le fournisseur dans le cloud pour gérer les ressources dans le cloud.
Consultez la section Browse APIs by product pour en savoir plus.
- Fournisseurs
Les fournisseurs dans le cloud sont les clouds auxquels vous pouvez vous connecter. Par défaut, Mise en service et gouvernance du cloud inclut les fournisseurs les plus couramment utilisés, tels qu’AWS, Azure et VMware. Chaque fournisseur propose de nombreux produits, chacun fournissant des types de ressources. Chaque type de ressource est mappé à un seul type de CI. Par exemple, le AWS provider inclut le AWS Elastic Compute Cloud produit, qui inclut le type de AWS::EC2::Instance ressource. Ce type de ressource est l’une des ressources dans le cloud les plus courantes que vous puissiez créer. Elle est directement mappée au type de CI de l’instance d’ordinateur virtuel [cmdb_ci_vm_instance], où les ordinateurs virtuels sont enregistrés dans la CMDB.
- Interfaces
Les interfaces définissent le cadre de travail dont le système a besoin pour structurer les appels REST attendus par les API du fournisseur dans le cloud. Les interfaces définissent les opérations, également appelées méthodes, et les paramètres requis par chaque méthode.
Les interfaces sont réutilisables. Si vous étendez CAPI pour inclure de nouveaux produits et API, vous pouvez utiliser des interfaces existantes pour effectuer les mêmes appels REST.
- API
Les API CAPI sont le composant central de CAPI qui relie un produit et une interface. Les API incluent le code réel que le système exécute.
Chaque API CAPI comprend les composants suivants :- Les mappeurs de méthode CAPI fournissent les méthodes mappées aux opérations définies dans l’interface. À partir des mappeurs de méthode CAPI, vous créez des Serveur MID includes de script en JavaScript pour indiquer au fournisseur de cloud exactement ce qu’il doit faire. C’est via les includes de script que la connexion au fournisseur de cloud se produit.Remarque :Si vous créez des API CAPI personnalisées, le système fournit un include de script vide que vous pouvez personnaliser. Vous pouvez également modifier les includes de script existants sur les mappeurs de méthode si nécessaire. Toutefois, la plupart des API par défaut fournies avec l’application n’utilisent pas d’includes Mise en service et gouvernance du cloud de script modifiables. Les connexions sont codées en dur en Java. Vous pouvez toujours utiliser ces API dans les nouveaux blocs de ressources que vous créez, mais vous ne pouvez pas modifier les API.
- Les remplacements de configuration d’API contiennent l’identité, telle qu’une clé, et les informations d’identification, telles que la clé secrète, et d’autres paramètres importants requis par le fournisseur dans le cloud. Ces paramètres aident le fournisseur dans le cloud à effectuer les opérations dans la liste connexe Mappeurs de méthode CAPI. Des remplacements de configuration d’API sont nécessaires car, lorsque le système appelle l’API du fournisseur dans le cloud via REST, les données d’identification ne sont pas incluses. Les blocs de ressources utilisent les paramètres et les valeurs que vous définissez dans les remplacements de configuration d’API pour interroger le magasin d’informations d’identification. Lorsque votre API s’exécute, les attributs sont mis à la disposition de tous les appels de méthode dans vos includes de script.
Les remplacements ne sont inclus dans le champ d’application que pour cette API. Les remplacements ne remplacent rien dans les autres API.
Étant donné que vous pouvez définir plusieurs versions d’une API CAPI avec de légères variations, vous pouvez étendre (sans remplacer) une API existante tout en conservant les fonctionnalités souhaitées.
- Les mappeurs de méthode CAPI fournissent les méthodes mappées aux opérations définies dans l’interface. À partir des mappeurs de méthode CAPI, vous créez des Serveur MID includes de script en JavaScript pour indiquer au fournisseur de cloud exactement ce qu’il doit faire. C’est via les includes de script que la connexion au fournisseur de cloud se produit.
Dans cet exemple, le Microsoft.Compute produit est contenu dans le Azure fournisseur. Azure utilise le produit pour les Microsoft.Compute machines virtuelles. Dans votre instance, le Microsoft.Compute produit est mappé au Microsoft.Compute/virtualMachines type de ressource, qui est associé au Virtual Machine Instance type de CI dans la CMDB.
L’interface Compute contient des définitions pour des méthodes telles que CreateNode, qui définit comment créer l’ordinateur virtuel réel. Parmi les nombreux paramètres utilisés CreateNode , Location capture le centre de données où réside l’ordinateur virtuel.
Le Azure Compute API rassemble le Microsoft.Compute produit et la structure définie dans l’interface Compute . L’implémentation de la CreateNode méthode appelle l’include de azure-compute-1.0-CreateNode Serveur MID script, qui appelle l’include de script AzureComputeVirtualMachine Serveur MID . Les includes de script effectuent les appels réels à l’API Azure. Pour accéder au compte Azure, les méthodes , ClientID, SecretKeyTenantID, et d’autres sont transmises dans Remplacements de configuration.
Comment CAPI s’intègre à l’instance
- Mise en service et gouvernance du cloud Blocs de ressources
Un bloc de ressources représente une ressource cloud unique, telle qu’un serveur virtuel, un serveur de stockage virtuel ou un centre de données. Vous pouvez également le considérer comme un type de CI dans la CMDB. Vous rassemblez de nombreux blocs de ressources dans un plan, qui apparaît sous la forme d’un élément de catalogue (également appelé pile) pour vos utilisateurs dans le catalogue dans le cloud.
Dans le système, chaque bloc de ressource est comme un conteneur qui fait référence à CAPI et relie les réponses du fournisseur dans le cloud à un CI spécifique. Utilisation des blocs de ressources :- Étapes opérationnelles qui appellent CAPI pour chaque opération, telle que l’opération de mise en service, et transmettent les valeurs des paramètres nécessaires dont le fournisseur de cloud a besoin pour exécuter l’opération.
- Processeurs de réponses qui traitent et analysent la réponse REST du fournisseur et mettent à jour les enregistrements dans la CMDB.
- La CMDB
Chaque bloc de ressources est basé sur un type de CI de la CMDB. Pour Mise en service et gouvernance du cloud, tous les types de CI liés au cloud sont basés sur la Virtual Machine Object CI classe, qui fournit tous les attributs dont vous avez besoin pour toutes les ressources dans le cloud prises en charge par défaut. Si aucun type de CI pour une ressource dans le cloud n’existe dans le système de base, vous devez créer une nouvelle classe CI et ajouter les attributs nécessaires.
Si vous créez une nouvelle classe CI, vous devez également créer :- Une classe CI pour chacune des ressources mises à la disposition de vos utilisateurs. Toutes les classes CI sont basées sur la classe d’objet de l’ordinateur virtuel.
- Règle d’identification qui spécifie un ID d’objet. Chaque fois que les composants de Gestion cloud font référence à une ressource cloud spécifique dans la CMDB, ils ont besoin de l’ID d’objet pour trouver la ressource cloud correcte.
- Règle de relation qui spécifie la façon dont la classe CI de la ressource est liée à d’autres classes CI. Par exemple, un virtual server CI doit avoir une Hosted on::Hosts relation avec un datacenter CI. Ces règles de relation sont nécessaires à l’unicité d’un CI lorsqu’elles sont traitées par le moteur Identification et rapprochement (IRE). La combinaison du compte de service, de l’ID d’objet de la ressource et du centre de données (ou de l’emplacement) où se trouve la ressource détermine le caractère unique.
- Serveur MID include de script
- Chaque opération dans l’API CAPI a un Serveur MID include de script que vous configurez. L’include de script appelle les classes JavaScript qui se trouvent déjà dans d’autres includes de script du système ou les classes JavaScript que vous créez. Finalement, la classe invoker est appelée pour déclencher l’appel REST. Serveur MID Les includes de script sont configurés sur votre ServiceNow instance, mais s’exécutent sur le Serveur MID.
Cette image illustre comment les composants fonctionnent ensemble lorsqu’un utilisateur met en service une ressource à partir de :Portail de l'utilisateur dans le cloud
Appels REST vers le fournisseur dans le cloud
- Les classes que vous pouvez appeler dans Serveur MID les includes de script. Consultez Classes CAPI dans les Serveur MID includes de script.
- Comment le fournisseur de cloud implémente REST. Voir :
- Le point de terminaison est
management.azure.com - La méthode à appeler avec une opération PUT est
subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName} ?api-version=2018-02-01, où vous spécifiez l’ID de l’abonnement, le nom du groupe de ressources et la version de l’API.
N’oubliez pas que les appels d’API REST ont lieu à l’intérieur des includes de script associés aux mappeurs de méthode d’API Serveur MID CAPI. Appelez les méthodes que CAPI met déjà à votre disposition en utilisant les classes étendues à partir de CloudAPIBase et CloudRESTAPIInvoker. Vous pouvez également créer d’autres includes de script pour étendre ces classes de base et créer vos propres classes. Familiarisez-vous avec ces classes de base et les méthodes disponibles dans celles-ci.
Commencer ici
- Examiner les API CAPI fournies avec Mise en service et gouvernance du cloud par défaut.
- Passez en revue les classes CAPI fournies par défaut. Ces classes peuvent être appelées à partir des includes de script dans vos opérations d’API Serveur MID CAPI.
- Passez en revue le provisionnement d’un ordinateur virtuel Azure et d’un ordinateur virtuel AWS pour voir comment les composants fonctionnent ensemble. La procédure pas à pas Azure utilise un include de Serveur MID script pour vous permettre de voir les différentes classes CAPI utilisées dans l’opération de mise en service. La procédure pas à pas AWS n’utilise pas d’include de Serveur MID script.
- Ajouter un produit à un fournisseur existant dans CAPI.
- Créer une classe CI pour une ressource cloud virtuelle.
- Créer ou étendre une interface CAPI.
- Créer une API CAPI et un include de script personnalisé Serveur MID qui effectue les appels REST vers le fournisseur dans le cloud. Un script include vide Serveur MID est toujours généré pour les nouvelles API CAPI. Modifiez-le avec les appels à d’autres classes et méthodes JavaScript, telles que les méthodes de la classe Invocateur.