Настройка тестовой среды для сложных облачных приложений

Постоянно растущая сложность облачных приложений становится серьезным препятствием для быстрой разработки облачных решений, будь то простые производственные приложения, сложные виртуальные приложения или шаблоны систем. В этой статье обсуждаются основные проблемы, которые пришлось преодолеть команде разработчиков для создания быстро развертываемой легко воспроизводимой рабочей системы для управления жизненным циклом при коллективной работе (Collaborative Lifecycle Management, CLM; другой термин Collaborative Application Lifecycle Management - управление жизненным циклом приложений при коллективной работе) на базе сервера приложений IBM WebSphere Application Server с использованием DB2 в качестве базы данных.

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

Предлагаемая статья является одним из примеров исследования и решения проблем, обусловленных высокой сложностью облачных приложений. В качестве решения одной из таких проблем в статье описывается набор шагов, обеспечивающий повторяемое быстрое развертывание рабочей системы Collaborative Lifecycle Management на базе сервера IBM WebSphere Application Server и базы данных DB2. При развертывании системы используются функции IBM Workload Deployer и Rational Team Concert CLM. Конечным результатом является готовая топология, которая может быть легко воспроизведена тестировщиками на базе текущей сборки для проверки исправленных дефектов, верификации сборки, выполнения smoke-тестов и для других задач тестирования.

Приступим

IBM Workload Deployer (IWD) - это аппаратный комплекс, предоставляющий среду для развертывания в частном облаке воспроизводимых шаблонов (или воспроизводимых решений) промежуточного ПО.

Первоначальная задача, поставленная перед нашей командой, состояла в том, чтобы предложить решение, которое позволяло бы быстро и воспроизводимо развертывать рабочую систему CLM на сервере WebSphere с DB2 в качестве базы данных. Основные сложности, связанные с решением этой задачи, заключались в том, что:

• Необходимо было найти способ развертывания тестовой топологии "на лету", используя каждый раз новую ежедневную сборку. Такая тестовая топология была необходима тестировщикам для проверки исправленных дефектов, верификации сборок и smoke-тестирования (базовой проверки работоспособности всей системы)
• До этого, прежде чем приступить непосредственно к выполнению тестового сценария, в среднем тестировщик затрачивал от 3 до 5 рабочих дней на установку и настройку тестовой системы.

Чтобы избавиться от длительных ручных операций по установке и обеспечить возможность многократного развертывания тестовой топологии, мы воспользовались IWD и его интегрированными функциями автоматизации (такими, как скрипты bash, Python и WSAdmin). С использованием пакетов скриптов для IWD полное развертывание тестовой системы по описанным ниже шагам занимает 60 минут.

Шаг 1. Создаем основу виртуальной системы

Шаблон топологии системы, рассматриваемой в данной статье, основан на готовом виртуальном образе Red Hat Enterprise Linux 64-bit WebSphere 8.0.0.1 Network Deployment (виртуальный образ 64-разрядной системы Red Hat Enterprise Linux с заранее установленными WebSphere ND версии 8.0.0.1 и IBM Installation Manager 1.4.4). С помощью дополнительных пакетов скриптов на этом образе устанавливается, настраивается и разворачивается платформа CLM, при этом определяется связь основного образа с готовым образом 64-разрядной версии RHEL с DB2 V9.7.4. На рисунке 1 показана схема топологии CLM, которая задается шаблоном виртуальной системы IWD VSP (virtual systems pattern), это наглядное представление шаблона VSP, который рассматривается в данной статье.

Рисунок 1. Топология системы CLM, задаваемая шаблоном виртуальной системы IWD VSP

В данном случае CLM-система работает на сервере WebSphere V8.0.0.1, а данные CLM хранятся на сервере DB2 V9.7.4.

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

Рисунок 2. Взаимосвязь между виртуальными образами, устанавливаемая IWD

Стрелка показывает, что сервер WebSphere 8.0.0.1 распознает сервер DB2 9.7.4. Таким образом, для установления соединения между двумя серверами пользователю не придется преодолевать множество сложных препятствий (в виде сетевых экранов, прокси-серверов и т.д.).

Теперь, когда основа нашего виртуального решения готова, можно переходить к следующему шагу, а именно к подготовке серверов WebSphere и DB2 для развертывания CLM-приложений.

Шаг 2: Создаем базы данных (JTS, CCM, QM, DW)

Для автоматизации этого шага мы разработали пакет скриптов, который включает в себя скрипт Linux bash. Этот скрипт вызывает db2admin (командный интерфейс DB2) и с его помощью создает базы данных, которые необходимы для работы приложений, входящих в состав платформы CLM. Скрипт работает в "молчаливом" режиме без вывода на экран промежуточной информации.

"Родительский" bash-скрипт выглядит следующим образом:

#!/bin/sh
su - db2inst1 -c "sh /tmp/createDatabases.sh"

Он вызывает "дочерний" скрипт:

#!/bin/sh
db2 CREATE DATABASE jtsDB AUTOMATIC STORAGE YES ON '/db2fs' DBPATH ON '/db2fs'
USING CODESET UTF-8 TERRITORY US COLLATE USING SYSTEM PAGESIZE 16384

Шаг 3: Обновление установленного пакета Installation Manager до версии 1.5.2

CLM 4.0 требует Installation Manager версии 1.5.2. Мы обновили готовую установочную версию Installation Manager до требуемой версии 1.5.2 с помощью файла ответа (response file), встроенного в пакет скриптов IWD:

Пример bash-скрипта:

echo "Enter IM Directory"
cd /opt/IBM/InstallationManager/eclipse

echo "Launching IM 1.5.2 Update"
./IBMIM --launcher.ini silent-install.ini -input $IMFilePath/imUpdate152.xml
-keyring $IMFilePath/im.keyring -accessRights admin -acceptLicense

При этом шаблон ответного файла IM будет выглядеть следующим образом

<?xml version="1.0"?>
<agent-input clean="true" temporary="true">
<server>
<repository location="<IM repository>"/>
</server>
<install> <offering features="agent_core,agent_jre" id="com.ibm.cic.agent"
version="<IM BUILD Version>"/>
</install> <profile id="IBM Installation Manager" installLocation="/opt/IBM/InstallationManager"
kind="self"><data key="eclipseLocation" value="/opt/IBM/InstallationManager"/>
</profile>
</agent-input>

Шаг 4: Установка CLM на сервер WebSphere

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

Перед началом установки скрипт просит пользователя ввести Build ID сборки. Затем с помощью команд bash этот номер подставляется в сгенерированный ответный файл Installation Manager.

Основной bash-скрипт выглядит следующим образом:

#!/bin/sh
. /etc/virtualimage.properties

echo "CLM Build to be installed: "$CLM_BUILD_ID

echo "Substitute CLM Build ID"

sed -i s%CLM_BUILD_ID_1%$CLM_BUILD_ID% /tmp/CLM/CLM.xml
sed -i s%CLM_BUILD_ID_2%$CLM_BUILD_ID% /tmp/CLM/CLM.xml

echo "Install CLM 4.x via Installation Manager"

cd /opt/IBM/InstallationManager/eclipse
./IBMIM --launcher.ini silent-install.ini -input /tmp/CLM/CLM.xml
-keyring /tmp/CLM/im.keyring -acceptLicense -accessRights admin

Exit

Шаг 5: Настройка WebSphere Server и развертывание CLM-приложений

На последнем шаге развертывания шаблона выполняется настройка параметров сервера WebSphere, необходимых для загрузки на сервер WAR-файлов CLM.

Для настройки WebSphere в соответствии с нашими требованиями команда разработала Python-скрипт, который вызывает объект AdminTask object:

После настройки параметров WebSphere нам нужно внести необходимые изменения в файлы teamserver.properties, создать таблицы баз данных и развернуть на сервере файлы CLM WAR.

Мы включили шаблоны файлов teamserver.properties в пакет скриптов для настройки приложений. В эти шаблоны с помощью функции поиска и замены строк bash подставляются соответствующие имена хостов и баз данных.

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

Далее все сводится к использованию инструментов установки CLM. Утилита установки CLM предоставляет набор инструментов для работы с репозиторием (repotools), которые позволяют создать таблицы в заранее подготовленных базах данных. Таким образом, при установке Jazz Team Server (JTS) с помощью мастера этот шаг выполнять уже не требуется.

Пример использования repotools:

echo "------Run Repo Tools for JTS Tables------"
cd /opt/IBM/JazzTeamServer/server
./repotools-jts.sh
-createTables teamserver.properties=
"/opt/IBM/JazzTeamServer/server/conf/jts/teamserver.properties"
logFile=repotools.log

И наконец, мы разворачиваем на сервере WebSphere WAR-файлы приложений. Для развертывания приложений используется Python-скрипт, который передается программе администрирования WebSphere (wsadmin.sh) и вызывается из нее для выполнения собственно развертывания приложений.

Python-скрипт для развертывания приложений выглядит следующим образом:

def deployJazzApp(app_name):

print "====== installing " + app_name + " Web Application on WAS ======\n"
app_war= app_name + '.war'
installed_appname = app_name + '_war'
app_ctx = '/' + app_name
appfile = properties.getProperty("CLM_HOME") + "/server/webapps/" + app_war

installcmd = ""

AdminApp.install(appfile, installcmd)
AdminConfig.save()
print "====== application " + app_name + " is installed on WAS =========\n"

print "====== Install completed. Please restart your WAS server.============\n"

По окончании развертывания всех приложений сервер WebSphere перезапускается. Теперь пользователь может воспользоваться мастером установки JTS и зарегистрировать нужные им CLM-компоненты. Окончательный вид шаблона после выполнения всех шагов показан на рисунке 3.

Рисунок 3. Окончательный вид шаблона

В заключение

Рассматриваемый в этой статье шаблон виртуальной системы первоначально разрабатывался для того, чтобы обеспечить тестировщикам возможность быстрого развертывания топологии CLM/WebSphere/DB2 в любой момент времени с дополнительной возможностью выбора конкретной сборки. Однако, как выяснилось, область возможного применения этого шаблона оказалась гораздо шире, чем мы рассчитывали. Теперь эта технология доступна всем разработчикам ПО Rational и, помимо верификации системы, используется:

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

Шаблон развертывания системы CLM - всего лишь небольшой пример возможностей, предлагаемых IWD. Кроме того, эта модель служит наглядной демонстрацией того, как использование инноваций на всех уровнях процесса разработки ПО может кардинально повысить качество программного обеспечения. Использование решения для быстрого развертывания тестовой среды при разработке продуктов Rational позволило значительно сократить затраты ценного времени разработчиков на установку и настройку системы CLM и использовать высвободившиеся ресурсы для разработки и тестирования ПО.

Использование IWD помогло нам превратить сложные и трудоемкие операции по созданию тестовой среды в простую автоматизированную процедуру.