API de nuvem (CAPI)
A API de nuvem (CAPI) permite que você integre Cloud Provisioning and Governance com provedores de nuvem usando REST APIs.
Componentes de CAPI
A integração com provedores de nuvem é realizada por meio de chamadas REST, como PUT, GET, POST e DELETE. O CAPI fornece a estrutura para você integrar uma REST API de fornecedores de nuvem para que sua instância possa se comunicar com o provedor de nuvem para gerenciar recursos de nuvem.
Consulte Browse APIs by product para saber mais.
- Provedores
Os provedores de nuvem são as nuvens às quais você pode se conectar. Por padrão, Cloud Provisioning and Governance inclui os provedores usados com mais frequência, como AWS, Azure e VMware. Cada provedor tem muitos produtos, cada um dos quais fornece tipos de recursos. Cada tipo de recurso é mapeado para um único tipo de IC. Por exemplo, o AWS provider inclui o produto AWS Elastic Compute Cloud, que inclui o tipo de recurso AWS::EC2::Instance. Este tipo de recurso é um dos recursos de nuvem mais comuns que você pode criar. Ele é mapeado diretamente para o tipo de IC de instância de máquina virtual [cmdb_ci_vm_instance], em que as máquinas virtuais são salvas no CMDB.
- Interfaces
As interfaces definem a estrutura de que o sistema precisa para estruturar as chamadas REST que as APIs do provedor de nuvem esperam. As interfaces definem as operações, também chamadas de métodos, e os parâmetros que cada método requer.
As interfaces são reutilizáveis. Se você estender o CAPI para incluir novos produtos e APIs, poderá usar as interfaces existentes para fazer as mesmas chamadas REST.
- APIs
As APIs do CAPI são o componente principal do CAPI que vincula um produto e uma interface. As APIs incluem o código real que o sistema executa.
Cada API de CAPI inclui estes componentes:- Os mapeadores de método CAPI fornecem os métodos que são mapeados para as operações definidas na interface. Nos mapeadores de método CAPI, você cria MID Server inclusões de script em JavaScript para informar ao provedor de nuvem exatamente o que fazer. É por meio das inclusões de script que ocorre a conexão com o provedor de nuvem.Nota:Se você criar APIs de CAPI personalizadas, o sistema fornecerá uma inclusão de script vazia para você personalizar. Você também pode modificar as inclusões de script existentes nos mapeadores de método, se necessário. No entanto, muitas das APIs padrão que vêm com a aplicação Cloud Provisioning and Governance não usam inclusões de script modificáveis. As conexões são codificadas em Java. Você ainda pode usar essas APIs em novos blocos de recursos que cria, mas não pode modificar as APIs.
- As Substituições de configuração de API contêm a identidade, como uma chave, e credenciais, como a chave secreta, e outros parâmetros importantes exigidos pelo provedor de nuvem. Esses parâmetros ajudam o provedor de nuvem a executar as operações na lista relacionada Mapeadores de método CAPI. As substituições de configuração de API são necessárias porque, quando o sistema chama a API do provedor de nuvem via REST, os dados de credencial não são incluídos. Os blocos de recursos usam os parâmetros e valores definidos nas Substituições de configuração de API para consultar o armazenamento de credenciais. Quando sua API é executada, os atributos são disponibilizados para todas as chamadas de método em suas inclusões de script.
As substituições têm escopo somente para esta API. As substituições não substituem nada em outras APIs.
Como é possível definir várias versões de uma API CAPI com pequenas variações, você pode estender (sem substituir) uma API existente enquanto mantém a funcionalidade desejada.
- Os mapeadores de método CAPI fornecem os métodos que são mapeados para as operações definidas na interface. Nos mapeadores de método CAPI, você cria MID Server inclusões de script em JavaScript para informar ao provedor de nuvem exatamente o que fazer. É por meio das inclusões de script que ocorre a conexão com o provedor de nuvem.
Neste exemplo, o produto Microsoft.Compute está contido no provedor Azure. O Azure usa o produto Microsoft.Compute para máquinas virtuais. Em sua instância, o produto Microsoft.Compute é mapeado para o tipo de recurso Microsoft.Compute/virtualMachines, que está associado ao tipo de IC Virtual Machine Instance no CMDB.
A interface Compute contém definições para métodos como CreateNode, que define como criar a máquina virtual real. Dos muitos parâmetros que CreateNode usa, Location captura o datacenter em que a máquina virtual reside.
O Azure Compute API reúne o produto Microsoft.Compute e a estrutura definida na interface Compute. A implementação do método CreateNode chama a inclusão de script azure-compute-1.0-CreateNode MID Server, que chama a inclusão de script AzureComputeVirtualMachine MID Server. As inclusões de script fazem as chamadas reais para a API do Azure. Para acessar a conta do Azure, os métodos SecretKey, ClientID, TenantIDe outros são passados em Substituições de configuração.
Como o CAPI se integra à instância
- Cloud Provisioning and Governance blocos de recursos
Um bloco de recursos representa um único recurso de nuvem, como um servidor virtual, armazenamento de servidor virtual ou um datacenter. Você também pode pensar nisso como um tipo de IC no CMDB. Você coloca muitos blocos de recursos juntos em um plano gráfico, que aparece como um item do catálogo (também chamado de pilha) para os usuários no Catálogo na nuvem.
No sistema, cada bloco de recursos é como um contêiner que faz referência ao CAPI e vincula as respostas do provedor de nuvem a um IC específico. Os blocos de recursos usam:- Etapas operacionais que chamam CAPI para cada operação, como a operação de provisionamento, e transmitem os valores de parâmetro necessários que o provedor de nuvem precisa para executar a operação.
- Processadores de resposta que processam e analisam a resposta REST do provedor e atualizam registros no CMDB.
- O CMDB
Cada bloco de recursos é baseado em um tipo de IC do CMDB. Para Cloud Provisioning and Governance, todos os tipos de IC relacionados à nuvem são baseados na classe Virtual Machine Object CI, que fornece todos os atributos necessários para todos os recursos de nuvem compatíveis por padrão. Se um tipo de IC para um recurso de nuvem não existir no sistema base, você deverá criar uma nova classe de IC e adicionar os atributos necessários.
Se você criar uma nova classe de IC, também deverá criar:- Uma classe de IC para cada um dos recursos que estão disponíveis para os usuários. Todas as classes de IC são baseadas na classe de objeto da máquina virtual.
- Uma regra de identificação que especifica um ID de objeto. Sempre que os componentes de Gestão de nuvem se referem a um recurso de nuvem específico no CMDB, eles precisam do ID do objeto para encontrar o recurso de nuvem correto.
- Uma regra de relacionamento que especifica como a classe de IC do recurso está relacionada a outras classes de IC. Por exemplo, um IC virtual server deve ter um relacionamento Hosted on::Hosts com um IC datacenter. Essas regras de relacionamento são necessárias para a exclusividade do IC quando processadas pelo Mecanismo de Identificação e Reconciliação (IRE). A combinação da conta de serviço, o ID do objeto do recurso e o datacenter (ou local) onde o recurso está localizado determina a exclusividade.
- MID Server inclusão de script
- Cada operação na API CAPI tem uma inclusão de script MID Server que você configura. A inclusão de script chama as classes JavaScript que já estão em outras inclusões de script no sistema ou as classes JavaScript que você cria. Por fim, a classe do invocador é chamada para acionar a chamada REST. MID Server inclusões de script são configuradas em sua instância ServiceNow, mas são executadas em MID Server.
Esta imagem ilustra como os componentes funcionam juntos quando um usuário provisiona um recurso do Portal de usuário da nuvem:
Chamadas REST para o provedor de nuvem
- As classes que estão disponíveis para você chamar em MID Server inclusões de script. Consulte Classes de CAPI em MID Server inclusões de script.
- Como o provedor de nuvem implementa REST. Veja:
- O endpoint é
management.azure.com - O método a ser chamado com uma operação PUT é
signatures/{subscriptionId}/resourcegroups/{resourceGroupName}?api-version=2018-02-01, em que você especifica o ID de assinatura, o nome do grupo de recursos e a versão da API.
Lembre-se de que as chamadas de REST API ocorrem dentro das inclusões de script MID Server que estão associadas aos mapeadores de método de API de CAPI. Chame os métodos que o CAPI já disponibiliza para você usando as classes estendidas de CloudAPIBase e CloudRESTAPIInvoker. Você também pode criar mais inclusões de script para estender essas classes base e criar suas próprias classes. Familiarize-se com essas classes base e os métodos disponíveis nelas.
Comece aqui
- Revisar APIs de CAPI fornecidas com Cloud Provisioning and Governance por padrão.
- Revise as classes de CAPI fornecidas por padrão. Essas classes podem ser chamadas a partir das inclusões de script MID Server em suas operações de API de CAPI.
- Analise o provisionamento de uma máquina virtual do Azure e uma máquina virtual da AWS para ver como os componentes funcionam juntos. O passo a passo do Azure usa uma inclusão de script MID Server para que você possa ver as várias classes de CAPI usadas na operação de provisionamento. O passo a passo da AWS não usa uma inclusão de script MID Server.
- Adicionar um produto a um provedor existente no CAPI.
- Criar uma classe de IC para um recurso de nuvem virtual.
- Criar ou estender uma interface de CAPI.
- Criar uma API de CAPIe uma inclusão de script MID Server personalizada que faz as chamadas REST para o provedor de nuvem. Uma inclusão de script MID Server vazia é sempre gerada para novas APIs de CAPI. Modifique-o com as chamadas para outras classes e métodos JavaScript, como os métodos na classe Invoker.