Lógica de terminal necessária para todos os brokers de serviço

Os brokers de serviço devem fornecer um conjunto padrão de valores de metadados que são consumidos por APIs de REST e os brokers do IBM Cloud devem ter lógica para os terminais ou caminhos da API de REST a seguir:

catálogo (GET)

Retorna os metadados do catálogo incluídos em seu broker.

instâncias de recurso (PUT)

Cria sua instância de serviço.

instâncias de recurso (DELETE)

Exclui sua instância de serviço.

instâncias de recurso (PATCH)

Atualiza sua instância de serviço.

Nota sobre catálogo (GET): esse terminal define o contrato entre o broker e a plataforma IBM Cloud para os serviços e planos suportados pelo broker. Esse endpoint retorna os metadados do catálogo que estão armazenados em seu corretor. Esses valores definem o contrato mínimo entre seu serviço e a plataforma IBM Cloud. Todos os metadados adicionais do catálogo que não são necessários são armazenados no catálogo IBM Cloud. Quaisquer atualizações para os valores de exibição do catálogo, como links e ícones, devem ser atualizadas no console do IBM Cloud e não hospedadas em seu broker. Nenhum dos metadados armazenados em seu broker é exibido no console do IBM Cloud ou na CLI do IBM Cloud CLI. O console e a CLI retornam o que foi definido no Partner Center Sell e armazenado no catálogo IBM Cloud. A seção a seguir mostra os valores mínimos exigidos que o catálogo (GET) retorna:

{
       "services": [{
           "id": "0bc9d744-6f8c-4821-9648-2278bf6925bb",
           "name": "ibmcloud-link",
           "description": "An IBM provided service that enables aliasing to service instances in the IBM Cloud.",
           "bindable": true,
           "plan_updateable": false,
           "plans": [
               {
                   "id": "da40662d-2f72-4a19-8c79-8c77cf285e1",
                   "name": "ibmcloud-alias",
                   "free": true,
                   "description": "The IBM Cloud alias plan used for linking."
               }
               ]
       }]
}

Lógica de terminais necessários para serviços ligáveis

Se o seu serviço puder ser vinculado a aplicativos em IBM Cloud, ele deverá retornar endpoints e credenciais de API para os consumidores do serviço. Um serviço que permite ligação deve usar as operações que permitem ligação na especificação Open Service Broker e implementar os terminais ou os caminhos a seguir:

ligações e credenciais (PUT)

Liga sua instância de serviço a um aplicativo.

ligações e credenciais (DEL)

Desvincula sua instância de serviço de um aplicativo.

Terminais de extensão IBM Cloud necessários

A especificação OSB não suporta um estado de instância desativada. Um estado desativado inclui um pagamento ausente ou outras situações que resultam em uma suspensão de conta (mas ainda não o cancelamento) e é diferente de um estado de instância excluído. Para que o IBM Cloud suporte clientes que podem ter um estado desativado, o IBM Cloud definiu os terminais de API estendidos que permitem que as instâncias de serviço sejam desativadas e reativadas. As seguintes extensões de endpoint são necessárias:

ativar e desativar instâncias (GET)

Status - retorna o estado de sua instância de serviço.

ativar e desativar instâncias (PUT)

Ativar ou desativar uma instância de serviço.

É responsabilidade do provedor de serviços desativar o acesso à instância de serviço quando o terminal de desativação se inicia e reativar esse acesso quando o terminal de ativação é iniciado.

X-Broker-API-Originating-Identity

O cabeçalho de identidade do usuário é fornecido por meio de um cabeçalho de identidade de origem da API. Esse cabeçalho de solicitação inclui a Identidade do IAM do IBM Cloud do usuário. A Identidade IAM é codificada como base64. O IBM Cloud suporta uma única região de autenticação: IBMid. A região IBMid usa um IBMid Unique ID (IUI) para identificar a identidade do usuário no IBM Cloud. Esse IUI é uma sequência opaca para o provedor de serviços.

Exemplo:

X-Broker-API-Originating-Identity: ibmcloud eyJpYW1faWQiOiJJQk1pZC01MEdOUjcxN1lFIn0=
Decoded:
{"iam_id":"IBMid-50GNR717YE"}

Versão de cabeçalho da API

O cabeçalho da versão da API é 2.12. Por exemplo: X-Broker-Api-Version: 2.12.

Instância de recurso (PUT) body.context e instância de recurso (PATCH) body.context

PUT /v2/service_instances/:resource_instance_id e PATCH /v2/service_instances/:resource_instance_id recebem o valor a seguir em body.context: { "platform": "ibmcloud", "account_id": "tracys-account-id", "crn": "resource-instance-crn" }.

Recomendações sobre o uso assíncrono em vez de operações síncronas

O OSB API suporta os modos síncrono e assíncrono de operação. Se suas operações vão levar menos de 10 seconds minutos, você deve usar respostas síncronas. Caso contrário, deve-se usar o modo assíncrono da operação. O modo assíncrono requer o terminal last_operation. Para obter mais informações, consulte Obtenha o status de uma provisão em andamento para uma instância de serviço.

Recomendações para gerenciar brokers em locais

É importante que os usuários entendam o local de seus serviços de nuvem para latência, disponibilidade e residência de dados.

Ao criar instâncias de serviço em IBM Cloud, um dos parâmetros obrigatórios que os usuários fornecem é o local onde desejam que a instância de serviço seja criada. Alguns serviços podem oferecer suporte à criação em vários locais. Por exemplo, um serviço de banco de dados pode suportar a criação em todas as regiões do site IBM Cloud ou pode suportar um subconjunto.

Se seu serviço baseado em API de terceiros for implementado em outra nuvem e exposto no IBM Cloud, o local indicará o local do serviço na outra nuvem.

Quando você se integra ao IBM Cloud, deve implementar pelo menos um broker do OSB. É possível ter mais de um broker, dependendo de sua estratégia de implementação e dos locais que deseja suportar para seu serviço. Dentro Do Partner Center Sell, você estabelece o mapeamento entre o seu plano de precificação e o intermediário. As opções típicas são definir um único intermediário para atender a todos os locais do seu serviço ou definir um intermediário por local; essa escolha fica a cargo do provedor de serviços.

Para uma lista de locais disponíveis, revise o IBM locais de catálogo globais. Se o seu serviço exigir mais locais a serem definidos, consulte a equipe de integração do IBM Cloud .