Рубрики
Без рубрики

Краткое руководство по Spring Cloud Open Service Broker

Узнайте, как реализовать API Open Service Broker с помощью Spring Cloud Open Service Broker.

Автор оригинала: baeldung.

1. Обзор

В этом уроке мы представим проект Spring Cloud Open Service Broker и узнаем, как реализовать API Open Service Broker|/.

Во-первых, мы погрузимся в спецификацию API Open Service Broker. Затем мы узнаем, как использовать Spring Cloud Open Service Broker для создания приложений, реализующих спецификации API.

Наконец, мы рассмотрим, какие механизмы безопасности мы можем использовать для защиты конечных точек нашего брокера услуг.

2. Откройте API Брокера услуг

Проект Open Service Broker API позволяет нам быстро предоставлять банковские услуги нашим приложениям, работающим на облачных платформах, таких как Cloud Foundry и Kubernetes . По сути, спецификация API описывает набор конечных точек REST, через которые мы можем предоставлять эти службы и подключаться к ним.

В частности, мы можем использовать брокеров услуг в рамках облачной платформы для:

  • Реклама каталога банковских услуг
  • Экземпляры служб предоставления услуг
  • Создание и удаление привязок между службой резервного копирования и клиентским приложением
  • Экземпляры службы Deprovision

Spring Cloud Open Service Broker создает базу для реализации API, совместимой с Open Service Broker, предоставляя необходимые веб-контроллеры, объекты домена и конфигурацию . Кроме того, нам нужно будет придумать нашу бизнес-логику, реализовав соответствующие интерфейсы service broker .

3. Автоматическая настройка

Чтобы использовать Spring Cloud Open Service Broker в нашем приложении, нам нужно добавить связанный starter артефакт . Мы можем использовать Maven Central для поиска последней версии open-service-broker starter .

Помимо облачного стартера, нам также потребуется включить веб-стартер Spring Boot и либо Spring WebFlux, либо Spring MVC, чтобы активировать автоматическую настройку:


    org.springframework.cloud
    spring-cloud-starter-open-service-broker
    3.1.1.RELEASE


    org.springframework.boot
    spring-boot-starter-web

Механизм автоматической настройки настраивает реализации по умолчанию для большинства компонентов, необходимых для брокера служб. Если мы хотим, мы можем переопределить поведение по умолчанию, предоставив нашу собственную реализацию компонентов open-service-broker Spring.

3.1. Конфигурация Пути к Конечным Точкам Сервисного Брокера

По умолчанию контекстный путь, в котором регистрируются конечные точки service broker, равен “/”.

Если это не идеально, и мы хотим изменить его, самый простой способ-установить свойство spring.cloud.openservicebroker.base-path в наших свойствах приложения или файле YAML:

spring:
  cloud:
    openservicebroker:
      base-path: /broker

В этом случае, чтобы запросить конечные точки service broker, сначала нужно будет префиксировать ваши запросы с помощью /broker/|/basepath.

4. Пример Брокера Услуг

Давайте создадим приложение service broker с помощью библиотеки Spring Cloud Open Service Broker и рассмотрим, как работает API.

В нашем примере мы будем использовать service broker для подготовки и подключения к резервной почтовой системе. Для простоты мы будем использовать фиктивный почтовый API, предоставленный в наших примерах кода.

4.1. Каталог услуг

Во-первых, чтобы контролировать, какие услуги предлагает наш брокер услуг, нам нужно определить каталог услуг . Чтобы быстро инициализировать каталог служб, в нашем примере мы предоставим компонент Spring типа Catalog :

@Bean
public Catalog catalog() {
    Plan mailFreePlan = Plan.builder()
        .id("fd81196c-a414-43e5-bd81-1dbb082a3c55")
        .name("mail-free-plan")
        .description("Mail Service Free Plan")
        .free(true)
        .build();

    ServiceDefinition serviceDefinition = ServiceDefinition.builder()
        .id("b92c0ca7-c162-4029-b567-0d92978c0a97")
        .name("mail-service")
        .description("Mail Service")
        .bindable(true)
        .tags("mail", "service")
        .plans(mailFreePlan)
        .build();

    return Catalog.builder()
        .serviceDefinitions(serviceDefinition)
        .build();
}

Как показано выше, каталог услуг содержит метаданные, описывающие все доступные услуги, которые может предложить наш брокер услуг. Более того, определение службы намеренно расширено , поскольку оно может относиться к базе данных, очереди сообщений или, в нашем случае, почтовой службе .

Еще один ключевой момент заключается в том, что каждая услуга строится на основе планов, что является еще одним общим термином. По сути, каждый план может предлагать разные функции и стоить разные суммы .

В конце концов каталог служб становится доступным для облачных платформ через брокер служб /v2/catalog endpoint:

curl http://localhost:8080/broker/v2/catalog

{
    "services": [
        {
            "bindable": true,
            "description": "Mail Service",
            "id": "b92c0ca7-c162-4029-b567-0d92978c0a97",
            "name": "mail-service",
            "plans": [
                {
                    "description": "Mail Service Free Plan",
                    "free": true,
                    "id": "fd81196c-a414-43e5-bd81-1dbb082a3c55",
                    "name": "mail-free-plan"
                }
            ],
            "tags": [
                "mail",
                "service"
            ]
        }
    ]
}

Следовательно, облачные платформы будут запрашивать конечную точку каталога брокера служб у всех брокеров служб, чтобы представить агрегированное представление каталогов служб.

4.2. Предоставление услуг

Как только мы начнем рекламировать услуги, нам также необходимо предоставить механизмы в нашем брокере для их предоставления и управления жизненным циклом в рамках облачной платформы.

Кроме того, то, что представляет собой подготовка, варьируется от брокера к брокеру. В некоторых случаях подготовка может включать в себя запуск пустых баз данных, создание брокера сообщений или просто предоставление учетной записи для доступа к внешним API .

С точки зрения терминологии, службы, созданные брокером услуг, будут называться экземплярами служб.

С помощью Spring Cloud Open Service Broker мы можем управлять жизненным циклом службы, реализуя интерфейс ServiceInstanceService . Например, для управления запросами на предоставление услуг в нашем сервисном брокере мы должны предоставить реализацию метода createServiceInstance :

@Override
public Mono createServiceInstance(
    CreateServiceInstanceRequest request) {
    return Mono.just(request.getServiceInstanceId())
        .flatMap(instanceId -> Mono.just(CreateServiceInstanceResponse.builder())
            .flatMap(responseBuilder -> mailService.serviceInstanceExists(instanceId)
                .flatMap(exists -> {
                    if (exists) {
                        return mailService.getServiceInstance(instanceId)
                            .flatMap(mailServiceInstance -> Mono.just(responseBuilder
                                .instanceExisted(true)
                                .dashboardUrl(mailServiceInstance.getDashboardUrl())
                                .build()));
                    } else {
                        return mailService.createServiceInstance(
                            instanceId, request.getServiceDefinitionId(), request.getPlanId())
                            .flatMap(mailServiceInstance -> Mono.just(responseBuilder
                                .instanceExisted(false)
                                .dashboardUrl(mailServiceInstance.getDashboardUrl())
                                .build()));
                    }
                })));
}

Здесь мы выделяем новую почтовую службу в наших внутренних сопоставлениях, если она с тем же идентификатором экземпляра службы не существует, и предоставляем URL-адрес панели мониторинга. Мы можем рассматривать панель мониторинга как веб-интерфейс управления для нашего экземпляра службы.

Предоставление услуг становится доступным для облачных платформ через конечную точку /v2/service_instances/{instance_id} :

curl -X PUT http://localhost:8080/broker/v2/service_instances/[email protected] 
  -H 'Content-Type: application/json' 
  -d '{
    "service_id": "b92c0ca7-c162-4029-b567-0d92978c0a97", 
    "plan_id": "fd81196c-a414-43e5-bd81-1dbb082a3c55"
  }' 

{"dashboard_url":"http://localhost:8080/mail-dashboard/[email protected]"}

Короче говоря, когда мы предоставляем новую услугу, нам нужно передать service_id и plan_id , объявленные в каталоге услуг . Кроме того, нам необходимо предоставить уникальный instance_id , который наш брокер услуг будет использовать в будущих запросах на привязку и отмену подготовки.

4.3. Привязка услуг

После предоставления услуги мы захотим, чтобы наше клиентское приложение начало взаимодействовать с ней. С точки зрения брокера услуг, это называется привязкой службы.

Подобно экземплярам и планам служб, мы должны рассматривать привязку как еще одну гибкую абстракцию, которую мы можем использовать в нашем сервисном брокере. В общем случае мы предоставим привязки служб для предоставления учетных данных, используемых для доступа к экземпляру службы .

В нашем примере, если объявленная служба имеет поле bindable , равное true , наш брокер услуг должен предоставить реализацию интерфейса ServiceInstanceBindingService . В противном случае облачные платформы не будут вызывать методы привязки служб у нашего брокера служб.

Давайте обработаем запросы на создание привязки службы, предоставив реализацию метода createServiceInstanceBinding :

@Override
public Mono createServiceInstanceBinding(
    CreateServiceInstanceBindingRequest request) {
    return Mono.just(CreateServiceInstanceAppBindingResponse.builder())
        .flatMap(responseBuilder -> mailService.serviceBindingExists(
            request.getServiceInstanceId(), request.getBindingId())
            .flatMap(exists -> {
                if (exists) {
                    return mailService.getServiceBinding(
                        request.getServiceInstanceId(), request.getBindingId())
                        .flatMap(serviceBinding -> Mono.just(responseBuilder
                            .bindingExisted(true)
                            .credentials(serviceBinding.getCredentials())
                            .build()));
                } else {
                    return mailService.createServiceBinding(
                        request.getServiceInstanceId(), request.getBindingId())
                        .switchIfEmpty(Mono.error(
                            new ServiceInstanceDoesNotExistException(
                                request.getServiceInstanceId())))
                        .flatMap(mailServiceBinding -> Mono.just(responseBuilder
                            .bindingExisted(false)
                            .credentials(mailServiceBinding.getCredentials())
                            .build()));
                }
            }));
}

Приведенный выше код генерирует уникальный набор учетных данных – имя пользователя, пароль и URI, – с помощью которых мы можем подключиться и пройти аутентификацию к нашему новому экземпляру почтовой службы.

Платформа Spring Cloud Open Service Broker предоставляет операции привязки служб через /v2/service_instances/{instance_id}/service_bindings/{binding_id} конечную точку:

curl -X PUT 
  http://localhost:8080/broker/v2/service_instances/[email protected]/service_bindings/admin 
  -H 'Content-Type: application/json' 
  -d '{ 
    "service_id": "b92c0ca7-c162-4029-b567-0d92978c0a97", 
    "plan_id": "fd81196c-a414-43e5-bd81-1dbb082a3c55" 
  }'

{
    "credentials": {
        "password": "bea65996-3871-4319-a6bb-a75df06c2a4d",
        "uri": "http://localhost:8080/mail-system/[email protected]",
        "username": "admin"
    }
}

Точно так же, как подготовка экземпляра службы, мы используем service_id и plan_id , объявленные в каталоге служб в нашем запросе привязки. Кроме того, мы также передаем уникальный binding_id , который брокер использует в качестве имени пользователя для нашего набора учетных данных.

5. Безопасность API Брокера услуг

Обычно, когда сервисные брокеры и облачные платформы взаимодействуют друг с другом, требуется механизм аутентификации.

К сожалению, спецификация API Open Service Broker в настоящее время не охватывает часть проверки подлинности для конечных точек service broker. Из-за этого также библиотека Spring Cloud Open Service Broker не реализует никакой конфигурации безопасности.

К счастью, если нам нужно защитить конечные точки нашего брокера услуг, мы можем быстро использовать Spring Security для установки Базовой аутентификации или OAuth 2.0 механизм. В этом случае мы должны аутентифицировать все запросы брокера услуг, используя выбранный нами механизм аутентификации, и возвращать 401 Несанкционированный ответ при сбое аутентификации.

6. Заключение

В этой статье мы рассмотрели проект Spring Cloud Open Service Broker.

Во-первых, мы узнали, что такое API Open Service Broker и как он позволяет нам предоставлять резервные службы и подключаться к ним. Впоследствии мы увидели, как быстро создать проект, совместимый с API Service Broker, с помощью библиотеки Spring Cloud Open Service Broker.

Наконец, мы обсудили, как мы можем защитить наши конечные точки брокера услуг с помощью Spring Security.

Как всегда, исходный код этого учебника доступен на GitHub .

Читайте ещё по теме: