Содержание


Интеграция службы с облаком с помощью SDK IBM Cloud Orchestrator

Comments

Многие компании среднего размера и крупные предприятия переносят свои бизнес-процессы и инфраструктуру в облаке в расчете на консолидацию ресурсов, упрощение обслуживания, сокращение расходов и гибкость. Это может дать им возможность создавать решения, способные адаптироваться к изменяющейся динамике их бизнеса. Настоящая статья основана на моем опыте работы с компаниями, которые перевели свой бизнес и инфраструктуру на IBM Cloud Orchestrator для достижения двух основных целей:

  1. Консолидация бизнес-процессов с помощью компонента IBM Business Process Manager решения IBM Cloud Orchestrator – в частности, интеграции в единую инфраструктуру различных ИТ-систем, необходимых предприятию (таких как программные продукты, компоненты сети, системы учета, а также системы управления лицензиями и расходами).
  2. Перемещение бизнес-приложений и служб в облако с использованием широких возможностей и гибкости моделей IBM Workload Deployer, а также стандартизации OpenStack-компонентов IBM Cloud Orchestrator.

На реализацию типичного сценария, такого как внедрение на предприятии новой ИТ-системы (такой как служба управления IP-адресами) могут уйти недели или месяцы. Основным фактором задержки служит тот факт, что разработчики бизнес-процессов, ответственные за добавление новых возможностей, часто не знакомы с конкретной предметной областью ИТ во всех деталях. С другой стороны, эксперт в этой предметной области ИТ, хорошо знакомый с данными, интерфейсами и API программных продуктов и компонентов, обычно не обладает опытом разработки бизнес процессов и работы с соответствующими инструментами.

Мы с моей группой поддерживали многих клиентов в их усилиях по созданию и внедрению специализированных модулей Business Process Manager, необходимых для построения облачной инфраструктуры; часто это занимало несколько недель из-за множества итераций, необходимых для сочетания двух областей знаний. Инструментарий IBM Cloud Orchestrator Development Kit for Integration (далее – SDK IBM Cloud Orchestrator) помогает тем, у кого нет опыта создания контент-пакетов для Business Process Manager, делать это быстро, надежно и повторяемым образом.

Архитектура специализированных модулей IBM Cloud Orchestrator

IBM Cloud Orchestrator состоит из базового продукта (платформы IBM Cloud Orchestrator) и набора дополнительных функций (специализированных модулей IBM Cloud Orchestrator, или контент–пакетов [Content Packs]), которые можно выбрать из каталога и установить для расширения поведения платформы. Эти модули дополняют платформу IBM Cloud Orchestrator и эффективно поддерживают сценарии клиентов облачных служб, предоставляя компоненты сети, накопители, функции биллинга и многие другие функции. Чтобы интегрировать в IBM Cloud Orchestrator новую ИТ-систему, необходимо создать специализированный модуль. На следующем рисунке приведена структура типичного специализированного модуля IBM Cloud Orchestrator.

Рисунок 1. Структура специализированного модуля IBM Cloud Orchestrator
Структура специализированного модуля IBM Cloud Orchestrator
Структура специализированного модуля IBM Cloud Orchestrator

Архитектура специализированного модуля включает в себя следующие компоненты:

  • службы интеграции: специализированные API-интерфейсы для автоматизации в определенной области ИТ. Обычно служба интеграции является средством интеграции с внешней системой для извлечения, обновления или вставки данных для решения задачи;
  • процессы: рабочие процессы автоматизации. Обычно это уровень бизнес-логики, на котором реализуются полезные для работы алгоритмы;
  • службы персонального обращения: процессы автоматизации особого типа, в которые входят интерфейсы для личного взаимодействия. Обычно такая служба собирает данные, необходимые бизнес-процессу для достижения своей цели.

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

Стандартные сценарии интеграции, в которых можно использовать SDK

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

  • интеграции на основе CLI: компонент, реализующий интегрируемую службу, предоставляет интерфейс командной строки для поддержки операций. Например, в большинстве решений Microsoft® Enterprise предлагается интерфейс командной строки PowerShell;
  • интеграция на основе HTTP (REST): Компонент, реализующий интегрируемую службу, предоставляет HTTP-интерфейс. REST и/или REST-подобные интерфейсы очень широко распространены благодаря полной независимости клиентов от поставщиков услуг. В число примеров входят ServiceNow, IBM Omnibus, Chef и многие другие;
  • интеграция на основе клиентской библиотеки: для связи с компонентом, предоставляющим услуги, (т.е. для совершения операций) клиент использует специальные библиотеки, обычно файл Java®-архива, распространяемый поставщиком услуг. Примером служит клиент VMWare.

SDK IBM Cloud Orchestrator обеспечивает простой способ создания специализированных модулей IBM Cloud Orchestrator для определенных ИТ-систем, если они относятся к одному из описанных выше основных сценариев.

По существу, SDK IBM Cloud Orchestrator создает службы интеграции (то есть наборы реализаций API), необходимые для взаимодействия с новой системой. Более того, он обеспечивает основные процессы и услуги, которые могут использоваться в качестве конструктивных блоков для автоматизации этой системы.

Практический пример

Рассмотрим пример компании, которая хочет построить служебный портал, облегчающий ее сотрудникам организацию полезных ИТ-услуг. Для построения служебного портала компания использует IBM Cloud Orchestrator и создает каталог услуг, позволяющий развертывать такие ресурсы, как простые виртуальные машины, системы с инструментами разработки и промежуточное ПО (стеки LAMP, базы данных и т.д.). Когда эти ресурсы размещены в облаке, должна быть надлежащим образом создана и настроена сеть - подсети, IP-адреса, маршрутизаторы, DNS и т.п.

IBM Cloud Orchestrator выполняет функции уровня «инфраструктура как услуга» (IAAS), опираясь на инфраструктуру OpenStack Cloud. В OpenStack есть компонент «сеть как услуга» – OpenStack Neutron. В последнее время многие операторы сетей используют преимущество открытой архитектуры Neutron для разработки модулей, которые позволяют им включать свои технологии в OpenStack, от сложных решений Software Defined Network (SDN) до более простых, таких как назначение IP-адресов. Таким образом, Neutron становится одним из ключевых компонентов управления уровнем оркестрации, где реализуются бизнес-процессы компании.

По этой причине я использую пример автоматизации сети, основанный на OpenStack Neutron. С технической точки зрения OpenStack Neutron предлагает интерфейс интеграции, реализованный посредством API-интерфейсов REST (Neutron API). Neutron API-интерфейсы описаны на стандартном языке WADL (Web Application Description Language), что облегчает интеграцию компонентов программного обеспечения.

Neutron может управлять большим количеством сетевых ресурсов (сети, подсети, порты, маршрутизаторы и т.д.). Я использую SDK для создания модуля управления сетевыми ресурсами. Тем не менее, ту же процедуру можно повторить и для других сетевых ресурсов, которые входят в Neutron.

Установка и настройка SDK

SDK IBM Cloud Orchestrator распространяется в качестве Eclipse-плагина и требует установки Eclipse 3.8.2 поверх Windows®. Eclipse 3.8.2 можно легко загрузить с официального сайта Eclipse, используя список заархивированных выпусков. Обратите внимание, что в Eclipse не входит JRE (Java Runtime Environment), а для SDK IBM Cloud Orchestrator требуется JRE 1.7. Загрузив ZIP-файл Eclipse (например, eclipse-SDK-3.8.2-win32.zip), его можно распаковать в любой каталог (например, C:\SDK).

Загрузите из библиотеки ISM модуль IBM Cloud Orchestrator SDK Eclipse. Чтобы включить SDK IBM Cloud Orchestrator в Eclipse, распакуйте файл Eclipse-модуля SDK в каталог плагинов Eclipse (C:\SDK\eclipse\plugins). Убедитесь, что появился новый каталог, SDK_<дата сборки> (C:\SDK\eclipse\plugins\SDK_1.0.0.2014-07-21). Запустите Eclipse и выберите рабочую область. SDK IBM Cloud Orchestrator находится в меню Eclipse Cloud Orchestrator.

При необходимости можно настроить SDK IBM Cloud Orchestrator на непосредственное импортирование инструментария в серверный компонент IBM Cloud Orchestrator Process Manager. Выберите пункт меню Eclipse Cloud Orchestrator > Settings. Вам понадобятся реквизиты доступа к машине, где работает сервер Business Process Manager, (чтобы копировать и дистанционно выполнять команды) и права администратора Business Process Manager (чтобы импортировать созданный инструментарий). Как и при работе с любым другим модулем Eclipse, SDK IBM Cloud Orchestrator сохраняет рабочие сеансы и параметры конфигурации в рабочей области. Если изменить рабочую область в сеансе, то в этом сеансе не будут доступны данные, относящиеся к другим рабочим областям.

Отладка конфигурации SDK IBM Cloud Orchestrator

Если меню Eclipse Cloud Orchestrator не отображается или SDK IBM Cloud Orchestrator не работает должным образом, проверьте состояние плагина из представления консоли.

  1. Выберите Windows > Show View > Console.
  2. Откройте командную строку Eclipse OSGI: Open Console > Host OSGI console.
  3. Введите команду lb.

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

Рисунок 2. Консоль OSGI для проверки состояния плагина SDK
Консоль OSGI для проверки состояния плагина SDK
Консоль OSGI для проверки состояния плагина SDK

Создание специализированного модуля IBM Cloud Orchestrator для OpenStack Neutron Networks

В этом разделе показано, как создать специализированный модуль для управления ресурсами OpenStack Neutron Network. Операция занимает несколько минут и не требует никаких специальных знаний в области разработки для IBM Cloud Orchestrator.

Загрузка WADL-документа по API-интерфейсу OpenStack Neutron Networks из сообщества OpenStack и его подготовка для SDK

Первым шагом процесса создания специализированного модуля станет загрузка WADL-определения API-интерфейса OpenStack Neutron Networks. WADL-документы по API-интерфейса OpenStack Neutron можно найти в GitHub, а на странице OpenStack есть полный справочник по Rest-API OpenStack. В GitHub также имеется копия сетевого файла os-networks-provider-ext.wadl.

Прежде чем приступить к созданию специализированного модуля, нужно заметить, что WADL-определения на REST API-интерфейса OpenStack не учитывают проверку подлинности/авторизацию, необходимые для их выполнения; определения API-интерфейса OpenStack в официальных WADL-документах OpenStack нельзя использовать как есть, потому что они не включают никаких учетных данных, которые служба проверки подлинности OpenStack (Keystone) проверяет для предоставления доступа к облачным ресурсам. Модель проверки подлинности/авторизации OpenStack требует проверки подлинности с учетными данными службы Keystone. После этого возвращается маркер, который используется с другими методами API-интерфейса OpenStack.

По этой причине необходимо изменить файл os-networks-provider-ext.wadl file, добавив параметр маркера аутентификации, который получит OpenStack Keystone. Отредактируйте файл os-networks-provider-ext.wadl и добавьте маркер аутентификации в раздел ресурсов WADL-документа на том же уровне определения методов API; тогда все методы API-интерфейса смогут наследовать новый параметр без необходимости повторять это в каждом определении.

Вставка нового параметра демонстрируется в следующем фрагменте файла os-networks-provider-ext.wadl.

Рисунок 3. Фрагмент WADL-файла Neutron Network с добавлением маркера аутентификации
Фрагмент WADL-файла Neutron Network с добавлением маркера аутентификации
Фрагмент WADL-файла Neutron Network с добавлением маркера аутентификации

Обратите внимание, что маркеру аутентификации присвоено значение по умолчанию {token_id} для указания на то, что это значение не является предопределенным, а будет входным параметром (token_id) для каждого метода API-интерфейса ресурса Neutron Networks. Обратите также внимание на стиль этого параметра – header; это значит, что он передается в заголовке HTTP-запроса.

Создание определения API-интерфейса в SDK IBM Cloud Orchestrator, начиная с WADL-документа

Для создания специализированного модуля REST API:

  1. Откройте клиент Eclipse и запустите мастер создания нового специализированного модуля: выберите Cloud Orchestrator > Create Content Plugin).
  2. На странице мастера Create your integration plugin (Создать специализированный модуль) выберите Import from file и импортируйте только что отредактированный WADL-документ. В таблице Rest API появятся определения методов API-интерфейса OpenStack Neutron Networks.
    Рисунок 4. API-интерфейсы Neutron Networks, импортированные из WADL-документа, на странице редактирования API
    API-интерфейсы Neutron Networks, импортированные из WADL-документа, на странице редактирования API
    API-интерфейсы Neutron Networks, импортированные из WADL-документа, на странице редактирования API

Для каждого метода API-интерфейса имеется набор данных, который можно редактировать. Мы сосредоточимся на методе API-интерфейса updateNetwork, чтобы понять смысл атрибутов метода, научиться редактировать методы в SDK и узнать, как определение метода отображается на окончательную реализацию специализированной службы, созданной в компоненте IBM Cloud Orchestrator Business Process Manager.

  • RestAPI name: updateNetwork: этот параметр представляет собой имя метода API-интерфейса. Это также имя соответствующей специализированной службы в специализированном модуле IBM Cloud Orchestrator.
  • Method: PUT: с помощью метода HTTP PUT метод API-интерфейса выполняет обновление существующей сети.
  • URI: /v2/networks/{network_id}: это относительный URI, который указывает на ресурс. Так как это обновление существующей сети, для идентификации обновляемого ресурса требуется уникальный идентификатор. Он должен быть назначен до выполнения HTTP-запроса и сопоставлен с входным параметром метода API-интерфейса.
  • Accept: application/json: поле заголовка Accept HTTP-запроса. по умолчанию метод API-интерфейса Neutron имеет формат JSON.
  • Content type: application/json: поле заголовка Content-Type HTTP-запроса. Тело обновления представлено в формате JSON.
  • Content: {body}: тело HTTP-запроса. По умолчанию, если HTTP-методом служит PUT/POST, то все тело представлено как входной параметр метода API-интерфейса.
  • Credentials: Если этот флаг имеет значение true, то HTTP-запрос использует обычную проверку подлинности HTTP, и параметры имени пользователя и пароля добавляются в качестве входных данных в сигнатуру метода API-интерфейса. В случае API-интерфейса OpenStack маркер проверки подлинности передается как параметр заголовка, и обычная проверка подлинности не используется.

Расширенные возможности

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

Рисунок 5. Расширенная настройка метода REST API для присвоения параметров заголовка, запроса и куки
Расширенная настройка метода REST API для присвоения параметров заголовка, запроса и куки
Расширенная настройка метода REST API для присвоения параметров заголовка, запроса и куки

SDK IBM Cloud Orchestrator позволяет глубоко настраивать HTTP-запрос для создания гибких методов API-интерфейса. Основные переменные HTTP-запроса можно редактировать. Из этих переменных SDK IBM Cloud Orchestrator создаст входные параметры окончательной сигнатуры метода API-интерфейса (специализированной службы).

В частности, в заголовках, куки, параметрах запросов, содержании и URL-адресах можно использовать нотацию {parameter_X} для настройки HTTP-запроса, которому присваивается входное значение parameter_X метода API-интерфейса. Примером служит значение {token_id} маркера проверки подлинности OpenStack, импортированное из WADL-определения.

Ниже приведена результирующая специализированная служба, сгенерированная SDK IBM Cloud Orchestrator и импортированная в IBM Cloud Orchestrator. По умолчанию SDK IBM Cloud Orchestrator добавляет предопределенный параметр ко всем сгенерированным специализированным службам для указания конечной точки REST, обслуживающей запрос.

Рисунок 6. Интерфейс специализированной службы updateNetwork
Интерфейс специализированной службы updateNetwork
Интерфейс специализированной службы updateNetwork

Сведения о специализированной службе:

  • имя: updateNetwork
  • входные параметры:
    • restEndpoint: конечная точка службы Neutron;
    • network_id: идентификатор обновляемой сети – присваивается в URL-адресе HTTP-запроса;
    • token_id: маркер аутентификации – присваивается в параметре заголовка X-Auth-Token;
    • Body: код JSON, представляющий новую версию ресурса – присваивается в содержании запроса.

Для завершения специализированного модуля сети добавьте вручную метод проверки подлинности API. Чтобы создать определение нового метода API, нажмите кнопку Add Rest API на странице "Create your integration Plugin" мастера. Назначьте новому API-интерфейсу следующие атрибуты:

  • Имя: auth;
  • Метод: POST;
  • URL: /v3/auth/tokens;
  • Реквизиты доступа: false (флажок снят).

Для завершения создания метода API-интерфейса необходимо указать содержание HTTP-запроса. Один из способов – вставить в качестве содержания HTTP-запроса {body}. Таким образом, вызывающий объект, чтобы успешно пройти аутентификацию, должен будет передать весь код JSON в качестве входного параметра с правильно заполненными полями имени и пароля. Допустимые значения тела методов OpenStack Keystone API приведены в документации API-интерфейса OpenStack.

В следующем примере вызывающий объект передает в качестве входных данных весь код JSON.

{ 
    "auth": { 
        "identity": { 
            "methods": [ 
                "password" 
            ], 
            "password": { 
                "user": { 
                    "domain": { 
                        "name": "example.com" 
                    }, 
                    "name": "Joe", 
                    "password": "secretsecret" 
                } 
            } 
        } 
    } 
}

Чтобы упростить метод, во входных параметрах передают не все тело JSON, а только имя домена, имя пользователя и пароль. В качестве шаблона можно использовать приведенный выше код JSON и указать в методе API-интерфейса только три параметра, перечисленных выше. Сначала необходимо заблокировать символы фигурных скобок { и }, чтобы SDK IBM Cloud Orchestrator мог правильно распознавать код JSON и его параметры. Для этого используйте знак косой черты, как показано ниже:

/{ 
    "auth": /{ 
        "identity": /{ 
            "methods": [ 
                "password" 
            ], 
            "password": /{ 
                "user": /{ 
                    "domain": /{ 
                        "name": "example.com" 
                    /}, 
                    "name": "Joe", 
                    "password": "secretsecret" 
                /} 
            /} 
        /} 
    /} 
/}

Теперь можно добавить параметры в JSON.

/{ 
    "auth": /{ 
        "identity": /{ 
            "methods": [ 
                "password" 
            ], 
            "password": /{ 
                "user": /{ 
                    "domain": /{ 
                        "name": "{domain_name}" 
                    /}, 
                    "name": "{user_name}", 
                    "password": "{psw}" 
                /} 
            /} 
        /} 
    /} 
/}

Вставьте измененный код JSON, приведенный выше, в тело вновь созданного API-интерфейса auth. Таким образом, содержание тела нового API-интерфейса auth определяет три новых входных параметра: domain_name, user_name и psw. Эти параметры предоставляются в качестве входных параметров определения метода API-интерфейса и передаются вызывающим объектом вместо всего кода JSON.

Создание специализированного модуля и его импортирование в IBM Cloud Orchestrator

Теперь можно создать специализированный модуль и импортировать его в IBM Cloud Orchestrator.

Назначьте новому специализированному модулю уникальное имя и сокращенное обозначение. Добавьте комментарий, чтобы разработчикам средств автоматизации было легче понять преимущества модуля. На странице "Create your integration plugin" мастера нажмите кнопку Next, и вам будет предложено сохранить инструментарий локально и/или загрузить его в настроенный компонент сервера Business Process Manager (если таковой имеется) IBM Cloud Orchestrator.

Рисунок 7. Создание специализированного модуля и его импортирование в IBM Cloud Orchestrator
Создание специализированного модуля и его импортирование в IBM Cloud Orchestrator
Создание специализированного модуля и его импортирование в IBM Cloud Orchestrator

Теперь специализированный модуль доступен в IBM Cloud Orchestrator и содержит API-интерфейс Neutron Network. Также имеется метод API-интерфейса auth с настроенными параметрами.

Рисунок 8. Службы интеграции созданного инструментария
Службы интеграции созданного инструментария
Службы интеграции созданного инструментария

Заключение

Специализированные модули дополняют платформу IBM Cloud Orchestrator и эффективно поддерживают широкий спектр сценариев клиентов облачных служб, предоставляя компоненты сети, накопители, биллинг и многие другие средства автоматизации. Инструментарий Development Kit for Integration Toolkit (SDK) обеспечивает простой способ создания специализированных модулей IBM Cloud Orchestrator для определенной системы. В этой статье приведен практический пример использования SDK IBM Cloud Orchestrator, включающий создание специализированного модуля для автоматизации сети на основе OpenStack Neutron. В ней описано, как установить и настроить SDK IBM Cloud Orchestrator и как устранить неполадки конфигурации. Также продемонстрировано, как импортировать WADL-определение REST API в SDK IBM Cloud Orchestrator и как отредактировать методы API-интерфейса с помощью пользовательского интерфейса SDK IBM Cloud Orchestrator. Кроме того, показано, как создать новый метод API-интерфейса и как использовать расширенные функции SDK для глубокой настройки HTTP-запроса. Наконец, в этой статье показано, как создать специализированный модуль и импортировать его в IBM Cloud Orchestrator


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления
ArticleID=1020082
ArticleTitle=Интеграция службы с облаком с помощью SDK IBM Cloud Orchestrator
publish-date=11052015