Развертывание новых приложений в IBM PureSystems с помощью плагинов. Часть 2

Уроки, извлеченные из проекта по обеспечению поддержки реального решения SugarCRM

С появлением IBM® PureSystems™ - комплексного семейства облачных систем корпоративного уровня, в которое входят приложения, услуги, оборудование и даже опыт (в виде практических моделей) - облачные вычисления достигли новых высот. Один из способов подготовить приложение к использованию с IBM PureSystems ― создать плагин, наводящий мост между пакетом приложения и системой. Первая статья была посвящена процессу разработки, позволяющему приложению SugarCRM работать на платформе IBM PureSystems. В предлагаемой статье разбираются уроки, извлеченные из проделанной работы.

Цзинь Хуан, архитектор облачных решений, IBM

Цзинь Хуан (Chin Huang) ― архитектор облачных решений, специализирующийся на ИТ-архитектуре и программном обеспечении. Его профессиональный опыт заключается в разработке передовых решений, в том числе на IaaS-платформе, а также в области SaaS-интеграции, облачного анализа, Web-сервисов и IWD-плагинов. Сертифицированный консультант по облачным вычислительным решениям и автор более чем 10 технических публикаций. Живет и работает в Кремниевой долине, штат Калифорния, США.



Тонь Нго, архитектор облачных решений, IBM

Фото автораТонь Нго (Ton Ngo) ― архитектор облачных решений и ведущий разработчик IBM Silicon Valley Lab в Сан-Хосе, штат Калифорния, США. До недавнего времени был архитектором "Высокопроизводительного вычислительного облака" в Наньянском технологическом университете в Сингапуре и занимался тестированием и разработкой облачной системы для канадского Royal Bank. До этого 17 лет работал научным сотрудником в IBM T.J. Watson Research Center и Almaden Research Center и имеет публикации по широкому кругу вопросов.



20.09.2012

В первой части этого цикла статей специалисты группы IBM Cloud описывают процесс разработки, позволяющий реализовать приложение SugarCRM на базе IBM PureSystems. SugarCRM ― это PHP-приложение, которому требуется набор LAMP (Linux®, Apache, MySQL, PHP). IBM PureSystems не поддерживает LAMP, поэтому группа разработала новый типовой образ и набор подключаемых модулей (плагинов), который поддерживает моделирование, развертывание и эксплуатацию приложения поверх базового образа Linux и IBM AIX®. Вторая часть посвящена урокам, извлеченным из этого проекта.

Перед продолжением чтения этой статьи полезно прочесть Часть 1, но это не обязательно.

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

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

Поддержка нескольких платформ

Плагины IBM PureSystems по своей природе нейтральны к платформе. Для поддержки нескольких платформ на разных этапах жизненного цикла приложения и плагина разработчики плагина должны составить рабочий план. В противном случае процесс разработки, обслуживания и отладки довольно быстро может стать чрезвычайно трудным.

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

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

Рассмотрим эти вопросы подробнее.

Объявление поддерживаемых платформ и предъявляемых ими требований

Для каждого экземпляра пакета файл конфигурации плагина config.json содержит раздел requires. Если плагин поддерживает несколько платформ при одном и том же наборе файлов, объявлять платформу не обязательно.

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

Организация файлов и сценариев для разных платформ

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

Сбор файлов, необходимых для поддержки плагина на разных платформах

Пользовательский интерфейс настройки плагина определен в файле config_meta.json. Декларативный подход облегчает построение пользовательского интерфейса и в то же время ограничен с точки зрения гибкости поддержки разных платформ с разными требованиями.

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

Написание сценариев, как не зависящих от платформы, так и специальных

Принцип заключается в том, чтобы по возможности писать один и тот же набор сценариев для платформ AIX и Linux. Мы все же написали два набора ввиду резкого различия процессов, необходимых для работы PHP.

Тем не менее, мы осознали важность знания ограничений платформы с точки зрения команд и сценариев. Например, в AIX первая строка сценария оболочки должна быть #!/bin/sh или #!/bin/ksh, а не #!/bin/bash, и нужно использовать команду gunzip, а заней tar, потому что команда tar не имеет параметра -z.

Управление поддерживаемыми и неподдерживаемыми платформами

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

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

В нашем случае полный охват матрицы поддержки был невозможен ввиду ограниченных ресурсов. Это ограничение чревато неожиданностями для пользователей, когда шаблон не удается развернуть на неподдерживаемой платформе. Мы нашли обходной путь для этой ситуации - предоставить шаблоны с именами, ассоциируемыми с поддерживаемой платформой, например, SugarCRM with DB2 on AIX.


Управление MySQL и DB2

Технически MySQL и DB2 служат одной и той же цели в качестве серверной базы данных для приложений SugarCRM. Для моделирования и преобразования мы использовали одинаковые шаблоны Velocity, что сократило время разработки. Однако аспект собственности на программное обеспечение внес серьезную коррективу в поддерживаемую топологию и реализацию нашего решения. DB2 принадлежит IBM; поэтому мы, естественно, предназначали свои решения для интеграции с готовыми плагинами DB2, как описано в разделе Повторное использование плагинов Части 1.

Для поддержки существующих плагинов MySQL мы, напротив, придерживались свободного подхода.


Разработка сценария

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

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

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

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


Отладка плагинов

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

На практике для ускорения разработки сценария мы использовали поддержку отладки в PDK. Сначала в плагин добавлялись все необходимые артефакты и базовые файлы сценариев. Мы развертывали образ с компонентом отладки, создавая среду с артефактами в хранилище и каталогами активации, содержащими файлы JSON. Затем мы обращались к ВM и по отдельности извлекали сценарии для дополнительной разработки и отладки. Эти сценарии копировались обратно в проекты Eclipse.


Выполнение сценария жизненного цикла

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

Например, install.py запускается только один раз для инициализации, в то время как configure.py, start.py и stop.py вызываются при каждой перезагрузке виртуальной машины.

Мы предъявляли конкретные требования к процессу установки SugarCRM в сценарии связи плагина с базой данных changed.py после правильной настройки Apache, PHP и базы данных. Сценарий установки должен запускаться только один раз для установки и настройки содержимого SugarCRM, а не всякий раз, когда вызывается changed.py для перезапуска каждой виртуальной машины.

В Python для обозначения статуса установки можно указать атрибут role. Чтобы установка не выполнялась несколько раз, мы проверяем наличие в changed.py постоянного файла, созданного SugarCRM в конце процесса установки.

Подробные сведения о сценариях жизненного цикла можно найти в Информационном центре IBM Workload Deployer и в Руководстве по разработке плагинов.


Удаление неудаляемого плагина

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


Импортирование отдельных плагинов, вместо плагинов, упакованных в пакет

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

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

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

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


Использование версий для ускорения разработки

Каждый типовой образ имеет версию в формате major.minor. В процессе разработки иногда нужно развернуть и сравнить несколько версий типового образа или просто исключить цикл очистки типового образа. Мы обнаружили, что целесообразно использовать для построения и установки типового образа другую major-версию.

Плагины, упакованные в типовой образ, также должны иметь новые major-версии и ссылаться на новую версию типового образа. Например, если в данный момент установлена версия типового образа 1.0.0.1, а новый типовой образ имеет версию 2.0.0.1, то плагины должны иметь такую конфигурацию, которая соответствует следующему фрагменту config.json:

"name": "sugarcrm",
"version": "2.0.0.2",
"patterntypes": {
    "primary": {
        "sugarcrm": "2.0"
    }   
},

Этот метод не только способствует быстрой проверке новой реализации типового образа, но и позволяет нескольким разработчикам использовать одну и ту же среду IBM PureSystems.


Работа с большими двоичными файлами

Из соображений лицензирования, изложенных выше, нам пришлось упаковать некоторые программы отдельно и загружать их при развертывании плагина. В нормальной ситуации этот шаг выполняется только один раз; однако в процессе разработки плагина повторная загрузка больших двоичных файлов размером порядка 500 МБ может быть затруднительной, особенно в медленной сети.

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


Расширение базового образа

Чтобы предоставить набор необходимого программного обеспечения для приложения, часто рассматривается компромисс между установкой программного обеспечения поверх базового образа и его включением в состав базового образа. Поскольку IBM PureSystems позволяет расширять базовый образ, мы рассмотрели возможность создания нового базового образа с необходимыми RPM для SugarCRM. Это упрощает первоначальную разработку, а также будущие усилия по поддержке, поскольку плагин отделен от изменений в базовом образе.

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


Заключение

В этой статье и в Части 1 мы рассмотрели вопросы проектирования, которые пришлось решать нашей группе при создании плагина для развертывания существующего решения SugarCRM в системе IBM PureSystems; мы показали также весь процесс разработки и подробно описали уроки, извлеченные из этого проекта.

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

После успешного тестирования примеров мы объявили, что решение SugarCRM «готово к применению в IBM PureSystems». Мы считаем, что наш проект не только позволил приобрести ценный опыт разработки сложных плагинов, но и принес важные результаты.

  • Успешный выпуск первого образа приложения в системе IBM PureSystems на основе нестандартного набора программного обеспечения. Это будет способствовать успеху IBM PureSystems и SugarCRM, позволяя влиятельным ISV предлагать свое программное обеспечение в составе каталога IBM PureSystems.
  • Наглядная демонстрация того, что IBM PureSystems не ограничивается готовыми образами приложений. Разрабатывая новые плагины, можно интегрировать новые приложения заказчиков и ISV, используя возможности IBM PureSystems.
  • Хорошее упражнение по поддержке разработки плагинов в IBM PureSystems. Эта поддержка должна быть надежной, чтобы составить богатый каталог образов приложений. Предложив среду плагинов для сценариев, отличных от текущего набора программного обеспечения IBM, мы помогли группе IBM PureSystems выявить области, требующие совершенствования, и эти усилия привели к появлению целого ряда новых функций, которые помогут в будущей разработке.

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

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления, Information Management
ArticleID=836223
ArticleTitle=Развертывание новых приложений в IBM PureSystems с помощью плагинов. Часть 2
publish-date=09202012