WWW.KNIGA.SELUK.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА - Книги, пособия, учебники, издания, публикации

 

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное агентство по образованию

Государственное образовательное учреждение

высшего профессионального образования

«Новосибирский государственный университет» (НГУ)

Кафедра общей информатики Е.Н. Семенова

РЕАЛИЗАЦИЯ ТЕХНОЛОГИИ ЗАЩИЩЕННОГО ОБНОВЛЕНИЯ

ПРОГРАММНЫХ СИСТЕМ ПО СЕТИ

МАГИСТЕРСКАЯ ДИССЕРТАЦИЯ

по направлению высшего профессионального образования 230100.68 ИНФОРМАТИКА И ВЫЧИСЛИТЕЛЬНАЯ ТЕХНИКА

ФАКУЛЬТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

Тема диссертации утверждена распоряжением по НГУ № 115 от «11» мая 2010 г.

Руководитель Федотов А.М.

д. ф.-м. н., чл. – корр. РАН Новосибирск, 2010 г.

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«НОВОСИБИРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ» (НГУ)

Кафедра общей информатики

УТВЕРЖДАЮ

Зав.кафедрой Пальчунов Д.Е (фамилия, И., О.) ………………….

(подпись, дата)

ЗАДАНИЕ

на магистерскую диссертацию студент Семенова Евгения Николаевна факультета ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ Направление подготовки 230100.68 ИНФОРМАТИКА И ВЫЧИСЛИТЕЛЬНАЯ

ТЕХНИКА

Магистерская программа 230100.68 ИНФОРМАТИКА И ВЫЧИСЛИТЕЛЬНАЯ

ТЕХНИКА

Тема «Разработка технологии защищенного обновления программных систем по сети»

Цели работы: разработка технологии для управления обновлениями программных системы, в том числе экземпляров системы, развернутых в других организациях, включающей автоматизацию сборок программного продукта и его отдельных частей Внедрение разработанной технологии в производственный процесс, на примере программной системы УИС.

Руководитель Федотов А.М Д.ф.-м.н, чл.кор РАН …………………………..

(подпись, дата) Оглавление ВВЕДЕНИЕ





Глава 1. Описание предметной области

Глава 1.1 Постановка задачи

Глава 1.2 Обзор существующих решений

Глава 2. Управляющая система

Глава 2.1 Непрерывная интеграция

Глава 2.2 Удалённое обновление

Глава 2.3 Реализация практики удаленного обновления

Заключение

Литература

ВВЕДЕНИЕ

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

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

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

Одним из примеров программных систем, в процессе разработки которой встречались все вышеперечисленные проблемы является Университетской информационной системы (УИС)[1-3]. УИС – это программная система, предназначенная для автоматизации деятельности образовательного учреждения. С каждым годом число используемых копий УИС растёт, она уже введена в эксплуатацию в университетах Санкт-Петербурга, Новосибирска, Томска, Барнаула, Красноярска.

УИС – развивающаяся программная система: непрерывно происходит разработка новых модулей автоматизирующих все большую часть деятельности университета;

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

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

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





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

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

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

Глава 1. Описание предметной области Система УИС состоит из двух независимых частей. Клиентское приложение представляет браузер, созданный на основе Mozilla FireFox и доработанный для взаимодействия с сервером УИС. Оно платформозависимо и сборка производится независимо для каждой из операционных систем, используемых заказчиком. Серверная часть – контейнер программных компонент, предоставляющий среду для выполнения и развертывания разнородных компонент, имеющих свой жизненный цикл, и набор компонент собранных по конфигурации заданной поставки. Каждый экземпляр УИС имеет свой уникальный профиль (набор конфигурационных файлов), зачастую несовместимых между собой. Для разделения конфигураций разных организаций были введены их уникальные короткие названия, или идентификаторы, которые позволяют однозначно получить набор нужных параметров, конфигураций и готовых пакетов обновлений, собранных с учетом нужных настроек.

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

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

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

Прежде чем приступить к обновлению удалённого сервера разработчику необходимо подготовить пакеты обновлений для каждой из частей УИС. Сборка клиентского приложения распределенная и занимает достаточно длительное время, что усложняет процесс обновления. Кроме того артефакты (результаты) сборок отдельных компонент необходимо собрать с разных серверов в случае успешного окончания сборки и опубликовать в приватные зоны организаций-клиентов на публичном сервере.

Глава 1.1 Постановка задачи После изучения предметной области была сформулирована основная задача.

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

Выделены функциональные требования:

- единая система управления сборками и процессом обновления;

- легкий и удобный интерфейс для выполнения производственных задач;

- автоматизация сборок программной системы УИС;

- передача и установка пакета обновления на удаленный сервер;

- возможность накопления статистические данных о проведенных операциях;

- автоматизация служебных процессов, связанных со сборкой и тестированием.

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

1. «КРОК»[4].

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

Предоставляет возможности контроля установки исправлений, обновления спектра ПО от Microsoft и других разработчиков, удаленного управления клиентами, создания детальных отчетов. КРОК представляет решение на основе Microsoft System Management Server (SMS) 2003. Как следствие отсутствие кросплатформености не позволяет использовать её под задачи УИС.

2. Центр обновления Microsoft [5] Центр обновления Microsoft помогает поддерживать систему в актуальном состоянии. Он позволяет загружать и устанавливать обновления как в полностью автоматическом режиме, так и вручную.

Предоставляет следующие возможности Уведомления о доступных обновлениях Рекомендации по настройке параметров обновления Поиск и установка обновлений Журнал обновлений Данное решение не применимо к УИС, поскольку платформозависимо и не распространяется в открытом доступе, а так же не позволяет решать задачи автоматизации сборок частей проекта и системы в целом 3. КМИС (Комплексные медицинские информационные системы[6] Это программное обеспечение для автоматизации деятельности медицинских Cистема базируется на объектно-реляционном принципе, согласно которого организации.

принципиально разные системы - Lotus Notes/Domino и SQL-сервер функционируют в единой связке, дополняя и усиливая достоинства другу друга и скрадывая недостатки. Все приложения, созданные в рамках КМИС, хранятся на сервере. Для этого предусмотрена специальная база данных – «Центр программ». Она тесно интегрирована в ядро системы, где существует отдельная программная библиотека, реализующая сервисы для работы с этой технологией. В результате КМИС сама определяет, какую редакцию приложения нужно инсталлировать или обновить - в зависимости от того, в какой операционной системе в данное время ведет работу пользователь. Подробности реализации не описаны, но возможности применить ее нет, поскольку программные Lotus Notes/Domino и SQL-сервер слишком громоздки в содержании и продукты обслуживании. Кроме того, подсистема обновлений интегрирована в саму КМИС, что скорее всего потребует дополнительных трудозатрат на выделение её, как независимый программный продукт.

4. Обновление портов и пакетов FreeBSD[7] Программное обеспечение во FreeBSD можно установить двумя путями. Первый: скачав необходимый пакет с одного из FTP серверов (зеркал) FreeBSD и установить с помощью команды pkg_add. Другой способ: самостоятельно скомпилировав нужную программу, скачав ее исходные коды с того же FTP сервера (зеркала). Каждый способ имеет свои достоинства и недостатки. В первом случае получают выигрыш во времени и экономим процессорное время своего компьютера, во втором случае, компилируя программное обеспечение (пакет) из портов получают самую последнюю версию программы. Такой подход, особенно второй способ, не очень удобен, так как потребует от администратора удаленного сервера произвести немалое количество операций.

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

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

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

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

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

Глава 2.1 Непрерывная интеграция С естественными процессами, сопровождающими успешный проект: увеличением числа занятых в производстве людей, обновлением состава команды, ростом количества автоматических тестов, автоматическая регулярная сборка начинает экономить всё большее времени. Непрерывная интеграци — практика частой автоматической сборки проекта, позволяющая сократить временной разрыв от момента возникновения ошибки до её исправления.

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

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

Сборка дистрибутива УИС осуществляется с помощью Ant[8], а клиенстких приложений - с помощью Make[9]. В добавок сборка клиентского приложения УИС производится для разных операционных систем на разных серверах с соответствующей операционной системой. То есть необходимо организовать распределенную структуру узлов сборки, с возможностью привязки определенной задачи к конкретному узлу. А после завершения сборки необходимо опубликовать артефакты (результаты сборок) на публичном сервере.

Как и в любой другой системе подобного масштаба в серверной части УИС есть слабо связанные компоненты, имеющие общие элементы модели данных. Взаимосвязь между большинством из них сложно отслеживать в процессе внесения изменений или написания новой функциональности, но правильность работы этих модулей является критичной в работе всей системы. Например: модуль расчета нагрузки преподавателей или модуль выгрузки данных в формате Yaml[10]. Для проверки корректности работы отдельных модулей создаются Unit-тесты, а для проверки корректности взаимодействия – integrationтесты. Их можно запустить в любой момент работы над исходным кодом, которая может затронуть логику действия одного из критических модулей, и проверить, что внесенные изменения не ломают работающий функционал. Таким образом, при обзоре серверов непрерывной интеграции необходимо предусмотреть возможность запуска Unit и Integration -тестов, и получение развернутого отчета об их выполнении.

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

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

Возможность сборки дистрибутивов с помощью утилит Ant и Make;

Запуск заданий в ручную и по расписанию;

Создание и управление подчиненными узлами, организация распределенной Запуск интеграционных и юнит тестов, анализ результатов их работы;

Выполнение послесборочных операций. Таких, например, как размещение результатов автоматизированной сборки на выделенном сервере;

Возможность использования системы плагинов, реализация и интегрирование Поддерживание версий сборок;

Простота и удобство используемых интерфейсов;

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

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

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

Наиболее удобным для решения служебных задач, связанных с разработкой УИС, оказался Hudson. Возможности Apache Continuum довольно ограничены в сравнении с остальными серверами непрерывной интеграции, он не позволяет создавать и использовать плагины. Atlassian Bamboo является коммерческой разработкой, несмотря на очень широкий спектр возможностей предоставляемых данным сервером и рекомендации по использованию именно этой разработки, соответственно нет возможности его внедрения в рамках данной работы. Между двумя оставшимися вариантами: сервера непрерывной интеграции Hudson и сервера Cruise Control, был выбран первый. Оба сервера являются web-приложениями, что позволяет получить доступ к данным авторизованным пользователям не только с рабочего места. Но при этом установка и настройка Cruise Control требует ручной работы над XML конфигурацией основных параметров сервера и создаваемых заданий, а в Hudson все возможные настройки сервера и задания задаются через довольно удобные интерфейсы. Что стало решающим фактором в выборе сервера непрерывной интеграции. Некоторые из плагинов для Hudson позволяют повысить эффективность использования его интерфейсов, отображая дополнительную информацию или скрывая ненужную, а некоторые, например Чак Норрис плагин, – делают использование более приятным, в зависимости от предпочтений разработчиков.

Этот плагин рисует Чака Норриса в разных эмоциональных состояниях в зависимости от статуса выполнения задачи (при успешной сборке - Чак Норрис улыбается, иначе Чак стоит в боевой стойке). Установка плагинов в Hudson производится через интерфейс, а для Cruise Control - редактированием конфигурационных файлов. Так же Hudson входит в пакеты установки операционных систем семейства Linux (для которых создана простая технология установки), что снижает трудозатраты на его установку на рабочем сервере до минимума. Кроме того, Hudson отслеживает выход новых версий, в том числе плагинов, и сам предлагает установить обновления через интерфейс. В Hudson заложена возможность построения кластера с отдельными узлами и управление ими, а также поиск по артефакту номера сборки, в которой он был создан.

В ходе работы была организована нижеприведённая схема непрерывной интеграции.

Рис. 1 Схема организации процесса непрерывной интеграции.

На центральном сервере установлен сервер непрерывной интеграции Hudson. Создано 4 подчиненных узла для сборки клиентских приложений для каждой из операционных систем Linux 32 и 64 разрядный и Windows 32 и 64 разрядный. Каждая из задач сборки клиентской части параметризована коротким идентификатором организации, для которой проводится сборка. После завершения сборки артефакты публикуются на сервере, в личные зоны каждой из организаций, имеющих копию УИС, в соответствии с параметром, указанным при запуске. Кроме этого, созданы отдельные параметризованные задачи для сборки и обновления серверной части, исполняющиеся на центральном сервере. Они позволяют легко и быстро, выбрав короткий идентификатор из списка доступных и запустив на выполнение задачу, собрать дистрибутив с нужной конфигурацией и обновить удаленную копию УИС, а по завершении получить отчет о ходе процесса обновления. И работа для запуска интеграционных тестов. В случае неуспешного завершения задачи администратор будет уведомлен по почте или коротким сообщением на телефон.

Глава 2.2 Удалённое обновление Перейдем к более подробному рассмотрению задачи обновления удалённых копий системы. Для программной системы этот вопрос актуален пока она развивается, пока появляется новая функциональность, пока продолжается работа над ней. Можно придумать разные способы поставки обновлений на удаленные сервера, но большая часть из них не продуктивны, неудобны для разработчиков, или не имею перспектив развития и оптимизации под новые требования. Одни технологии устаревают, другие наоборот набирают силу и получают все большее распространение. Поэтому одной из задач в процессе разработки технологии удаленного обновления стал подбор методов и средств, не только осуществляющих нужную функциональность, но представляющих интерес для изучения и имеющих перспективы развития.

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

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

• передача файлов и коллекций на удалённый сервер;

• получение файлов и коллекций с удалённого сервера;

• возможность получения свойств файлов и коллекций (дата создания, размер);

• запуск исполняемых файлов с набором параметров;

• удобный формат передачи и получения данных.

В качестве дополнительных требований были выдвинуты:

• возможность шифрования передаваемых данных;

• возможность настройки авторизованного доступа к сервису.

Кроме того, выделены еще несколько особенностей и связанные с ними последствия.

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

Глава 2.3 Реализация практики удаленного обновления Среди большого количества различных протоколов взаимодействия между удаленными серверами привлёк внимание протокол WebDAV[15]. WebDAV (Web-based Distributed Authoring and Versioning) — защищённый сетевой протокол высокого уровня, работающий поверх HTTP для доступа к объектам и коллекциям.

Протокол позволяет отправлять на сервер и получать с сервера файлы и коллекции, изменять их свойства, поддерживает одновременную работу над объектами, есть возможность выполнения расширенных файловых операций (блокировки, поддержка версий). Так как он реализован поверх HTTP[16], то возможно использование SSL для шифрования и защиты данных.

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

Для организации WebDAV доступа к ресурсу достаточно запустить сервер приложений и загрузить в него компонент, содержащий WebDAV-Servlet, с указанием директории доступной для выполнения различных файловых операций над её объектами.

Сервер приложений – достаточно сложная программная система, помимо загрузки и исполнения сервлетов, она предоставляет широкий спектр различного функционала для работы с HTTP запросами. Более удобно воспользоваться лишь частью сервера приложений, а именно - контейнером сервлетов. Эта система представляет собой сервер, который занимается системной поддержкой сервлетов и обеспечивает их жизненный цикл в соответствии с правилами, определёнными в спецификациях. Зачастую контейнер сервлетов интегрирован в сервер приложений. Одни из примеров независимого контейнера приложений является разработка компании Mort Bay Consulting – Jetty[17]. Он и был выбран для использования.

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

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

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

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

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

Необходимость контролируемого доступа к информации о процессах, выполняющихся в рамках контейнера сервлетов, обуславливает создание единственного экземпляра класса, аккумулирующего информацию обо всех запущенных, завершенных и ожидающих процессах; доступ, к которому можно получить в любое время работы. Жизненный цикл экземпляра сервлета ограничен, а информацию о процессах необходимо получать и по прошествии некоторого времени, таким образом, удобным архитектурным решением является использование шаблона проектирования «Singleton». Он будет содержать информацию о завершенных процессах, запускать на исполнение новые и управлять очередью ожидания, а так же следить за исполнением уже запущенных процессов.

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

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

Таким образом, структуру работы и основные функциональные элементы WebDAV сервера можно представить на рисунке 2.

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

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

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

Итогом работы агента становится полученная информация о запущенных процессах, записанная в отдельный файл и сообщения с результатами выполнения процессов на удалённом сервере.

Схематично основные принципы взаимодействия WebDAV агента и сервера изображены на рисунке 3, приведенном ниже.

Рис.3 Схема организации процесса обновления удаленного сервера Агент был реализован с использованием библиотеки apache jackrabbit для работы с WebDAV. Она содержит реализацию все основных команд, проста и удобна в использовании.

При проектировании архитектуры за основу был взят шаблон проектирования «Strategy». Это поведенческий шаблон проектирования, предназначенный для определения семейства алгоритмов, инкапсуляции каждого из них и обеспечения их взаимозаменяемости. Это позволяет выбирать алгоритм путем определения соответствующего класса. Шаблон Strategy позволяет менять выбранный алгоритм независимо от объектов-клиентов, которые его используют.

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

С использованием XML в конфигурационном файле описаны действия, необходимые для выполнения. Для входной конфигурации описаны XML-Shema, которая позволяет осуществлять проверку корректности входных данных.

Ниже приведен пример конфигурации, задаваемой для агента.

sync target rootHost=“server.host” rootPort=“1234” password=“password” login=“login” name=“updateServer” put into="/" transfer_if="date,size,new" files resource="/scripts/update.sh" property name="chmod" value="700"/ put into="/temp" transfer_if="date,size,new" files resource="files /" pattern=“distrib-*\.tar\.gz" lastModified="true" property name="exec" value="./update.sh" parameter name="blocked" value="true"/ parameter name="HOME" value="target"/ parameter name="CLIENT_NAME" value="demo"/ /target /sync После разбора данной конфигурации агентом будут выполнены следующие действия:

• Файл update.sh будет передан на сервер, затем ему будут установлены права доступа 700, описанные атрибутом с названием “chmod” • Из директории files был выбран файл с именем подходящим по шаблону «distribtar\.gz» с наибольшей датой модификации. Этот файл был передан на сервер и параметрами «target demo». Фактически команда запуска была составлена следующая «./update.sh./temp/distrib-20100425.tar.gz target demo». Инструкции для проведения обновления, создания контрольных точек восстановления и отката в случае необходимости указаны в файле update.sh, которому при запуске в качестве обновлений передается пакет обновлений, директория на сервер с местом расположения системы, и сокращенное название организации.

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

В том числе реализовано обновление самого WebDAV сервера с использованием запуска исполняемого файла на нём.

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

Как следствие получен целостный управляющий комплекс.

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

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

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

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

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

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

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

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

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

Литература 1. Адаманский А.В. Архитектура контейнера программных компонент Jaxion. // Вестн. Новосиб. гос. ун-та. Серия: Информационные технологии. 2005. Т. 2, вып.

2. Адаманский А.В., Денисов А.Л., Кочеев А.А. Опыт автоматизации вуза. Система УИС // Вестн. Новосиб. гос. ун-та. Серия: Информационные технологии. 2006. Т. 4, 3. Университетская информационная система. Презентация УИС для учебных заведений. [Электронный ресурс]. 2009г. Презентация. С. 1-24. Режим доступа:

http://www.softmotions.com/uploads/docs/uis_pres-site.ppt (дата обращения:

27.04.2010) 4. КРОК, автоматическое обновление программного обеспеченья. Официальный сайт http://www.croc.ru/solution/infrastructure/automatic/ (дата обращения: 24.05.2010) http://www.oszone.net/9448/Windows_Update#serttings (дата обращения: 24.05.2010) http://www.kmis.ru/site.nsf/pages/kmis_tecnology_autosetup.htm (дата обращения:

24.05.2010) 7. Portupgrade, или коррекция системы портов FreeBSD. Алексей Федорчук.

[Электронный ресурс]. Режим доступа: http://posix.ru/distro/bsd_portupgrade/ (дата обращения: 24.05.2010) 8. Ant, Java-утилита для автоматизации процесса сборки программного продукта.

http://ant.apache.org/ (дата обращения: 27.04.2010) 9. Make, утилита для автоматизации процесса сборки программного продукта.

http://linuxlib.ru/prog/make_379_manual.html (дата обращения: 27.04.2010) 10. Формат данных Yaml. Официальный web-сайт разработчиков. [Электронный ресурс]. Режим доступа: http://www.yaml.org/ (дата обращения: 27.04.2010) 11. Apache Continuum, сервер непрерывной интеграции. Официальный сайт проекта.

[Электронный ресурс]. Режим доступа: http://continuum.apache.org/ (дата обращения: 24.05.2010) 12. Atlassian Bamboo, сервер непрерывной интеграции. Официальный сайт проекта.

[Электронный ресурс]. Режим доступа: http://www.atlassian.com/software/bamboo/ (дата обращения: 24.05.2010) 13. Cruise Control, сервер непрерывной интеграции. Официальный сайт проекта.

[Электронный ресурс]. Режим доступа: http://cruisecontrol.sourceforge.net/ (дата обращения: 24.05.2010) 14. Hudson, сервер непрерывной интеграции. Официальный сайт проекта.

[Электронный ресурс]. Режим доступа: http://hudson-ci.org/ (дата обращения:

24.05.2010) 15. WebDAV, Сетевой протокол. Официальный сайт проекта. [Электронный ресурс].

Режим доступа: http://www.webdav.org (дата обращения: 24.05.2010) 16. HTTP, Сетевой протокол. Спецификация протокола [Электронный ресурс]. Режим доступа:

Версия: 1.0 http://tools.ietf.org/html/rfc Версия: 1.1 http://tools.ietf.org/html/rfc (дата обращения: 24.05.2010) 17. Jetty, Сервер приложений. Официальный сайт проекта. [Электронный ресурс].

Режим доступа: http://jetty.codehaus.org/jetty (дата обращения: 24.05.2010)

 
Похожие работы:

«РОССИЙСКАЯ АКАДЕМИЯ НАУК ИНСТИТУТ ПРОБЛЕМ ИНФОРМАТИКИ А.В. ИЛЬИН, В.Д. ИЛЬИН СИМВОЛЬНОЕ МОДЕЛИРОВАНИЕ В ИНФОРМАТИКЕ Москва ИПИ РАН 2011 Ильин Владимир Ильин Александр Дмитриевич Владимирович Доктор техн. наук, профессор. Кандидат техн. наук. Заведующий Старший научный сотрудник Лаб. Методологических основ информатизации в Институте проблем информатики РАН Автор более 100 трудов по Автор более 30 трудов по S-моделированию, S-моделированию, автоматизации конструированию программ и...»

«Дайджест публикаций на сайтах органов государственного управления в области информатизации стран СНГ Период формирования отчета: 01.04.2014 – 30.04.2014 Содержание Республика Беларусь 1. 1.1. Министр связи и информатизации принял участие в заседании Совета Палаты представителей Национального собрания Республики Беларусь. Дата новости: 10.04.2014. 1.2. Форум ТИБО-2014 открыт приветственным словом Премьер-министра Республики Беларусь Мясниковича М.В. Дата новости: 21.04.2014. 1.3. Форум ТИБО-2014...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования Тверской государственный университет Экономический факультет Кафедра математики, статистики и информатики в экономике УТВЕРЖДАЮ Декан экономического факультета Д.И. Мамагулашвили _2012 г. Учебно-методический комплекс по дисциплине Математические методы принятия решений в условиях неопределенности и риска Для студентов 4 курса Специальность 080401.65...»

«До И ин ст ссл те ф иж ед ме ле ор е ова ж ко ма ни ни ду мм ти я е на у за в с ро ни ци фе дн ка и ре ой ци и бе й в зо ко па н сн тек ос с т ти е 33 asdf Организация Объединенных Наций РАЗОРУЖЕНИЕ Управление по вопросам разоружения Доклад Группы правительственных экспертов по достижениям в сфере информатизации и телекоммуникаций в контексте международной безопасности asdf Организация Объединенных Наций Нью-Йорк, 2012 год Руководство для пользователей Настоящее издание, имеющееся на всех...»

«УСТАНОВОЧНАЯ СЕССИЯ I КУРСА ЗАОЧНОГО ОТДЕЛЕНИЯ Институт информационных коммуникаций и библиотек ДИСЦИПЛИНА, МАТЕРИАЛЫ К СЕССИИ СПЕЦИАЛИЗАЦИЯ Вопросы Отечественная История как наука. Отечественные научно-исторические школы и их представители. 1. история Исторические источники и их виды. • библиотечноФормационный и цивилизационный подходы к периодизации истории. Западная и 2. информационная восточная цивилизации. деятельность (зачет) Восточные славяне в древности, этапы образования государства....»

«ІІ. ІСТОРІЯ ФІЛОСОФІЇ Клаус Вигерлинг (Германия)1 К ЖИЗНЕННОЙ ЗНАЧИМОСТИ ФИЛОСОФИИ – ПО ПОВОДУ ОДНОГО СТАРОГО ФИЛОСОФСКОГО ВОПРОСА В статье производится ревизия современного состояния философии, анализируется её значение на основании философского анализа умозаключений, сделанных Гуссерлем, Хёсле. Данная статья подготовлена на основе двух докладов, которые были сделаны в университете Баня-Лука (Босния-Герцоговина). Ключевые слова: философия, жизненный мир, первоосновы, современное состояние...»

«И.М.Лифиц СТАНДАРТИЗАЦИЯ, МЕТРОЛОГИЯ И СЕРТИФИКАЦИЯ УЧЕБНИК Рекомендовано Министерством образования Российской Федерации в качестве учебника для студентов высших учебных заведений, обучающихся по специальностям Коммерция, Маркетинг, Товароведение и экспертиза товаров 5-е издание, переработанное и дополненное МОСКВА • ЮРАЙТ • 2005 УДК 389 ББК 30.10ц; 65.2/4-80я73 Л64 Рецензенты: М.А. Николаева — доктор технических наук, профессор, действительный член Международной академии информатизации: Г.Н....»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ УТВЕРЖДАЮ Заместитель Министра образования Российской Федерации В.Д. Шадриков 14 марта 2000 г. Номер государственной регистрации: 52 мжд / сп ГОСУДАРСТВЕННЫЙ ОБРАЗОВАТЕЛЬНЫЙ СТАНДАРТ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ Специальность 351400 ПРИКЛАДНАЯ ИНФОРМАТИКА (по областям) Квалификация информатик-(квалификация в области) В соответствии с приказом Министерства образования Российской Федерации от 04.12.2003 г. №4482 код данной специальности по...»

«МЕЖДУНАРОДНЫЙ МОЗМ D 1 ДОКУМЕНТ 2012 г. (изд. англ.) ОСНОВНЫЕ ПОЛОЖЕНИЯ ДЛЯ ЗАКОНА ПО МЕТРОЛОГИИ Considerations for a Law on Metrology Международная Организация Законодательной Метрологии (МОЗМ) 1 Содержание Предисловие Часть 1 – Введение Часть 2 – Обоснование Часть 3 – Руководящие указания по созданию структур в метрологии и предлагаемые статьи для Закона Часть 4 – Предложения по нормативным документам Часть 5 – Предложения по структуре Закона по метрологии Часть 6 – Библиография Предисловие...»

«МОСКОВСКИЙ ГОРОДСКОЙ ПЕДАГОГИЧЕСКИЙ УНИВЕРСИТЕТ Фундаментальная библиотека Отдел информационного обслуживания Бюллетень новых поступлений в Фундаментальную библиотеку март 2014 г. Москва 2014 1 Составители: Т.А. Сенченко В бюллетень вошла учебная, учебно-методическая, научная и художественная литература, поступившая в Фундаментальную библиотеку в марте 2014 г. Материал расположен в систематическом порядке по отраслям знаний, внутри разделов – в алфавитнохронологическом. Указано распределение по...»

«Содержание Игровая мебель для самых маленьких Тренировка дыхания и твердой руки Игровые стены для игровых зон Настенные игровые панели Двигательная активность Игрушки для самых маленьких Физкультура для самых маленьких Мебель для активных занятий Развиваем координацию движений Мелкая моторика и графомоторика Центры двигательной активности в помещении. 50 Развивающие игры напольные и настольные Математика и информатика Настольная песочница Математическая мастерская в начальной школе....»

«ДОКЛАДЫ БГУИР № 2 (14) АПРЕЛЬ–ИЮНЬ 2006 ЭКОНОМИКА И УПРАВЛЕНИЕ УДК 608. (075) ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ НЕМАТЕРИАЛЬНЫХ АКТИВОВ Т.Е. НАГАНОВА Белорусский государственный университет информатики и радиоэлектроники П. Бровки, 6, Минск, 220013, Беларусь Поступила в редакцию 28 ноября 2005 Рассматриваются теоретические составляющие интеллектуальной собственности с целью формулировки подходов к совершенствованию патентно-лицензионной работы в Республике Беларусь. Ключевые слова: интеллектуальная...»

«Направление подготовки: 010300.68 Фундаментальная информатика и информационные технологии (очная, очно-заочная) Объектами профессиональной деятельности магистра фундаментальной информатики и информационных технологий являются научно-исследовательские и опытноконструкторские проекты, математические, информационные, имитационные модели систем и процессов; программное и информационное обеспечение компьютерных средств, информационных систем; языки программирования, языки описания информационных...»

«ИСТОРИЯ И МЕТОДОЛОГИЯ ИНФОРМАТИКИ И ВЫЧИСЛИТЕЛЬНОЙ ТЕХНИКИ Введение Цели, задачи, структура курса Целью изучения дисциплины История и методология информатики и вычислительной техники является: обобщение и систематизация знаний об истории развития информатики и вычислительной техники; анализ предпосылок формирования тенденций развития вычислительных и информационных ресурсов в историческом аспекте; формирование представления о методологии научных исследований; освоение методов...»

«Научное обоснование развития сети особо охраняемых природных территорий в Республике Карелия Карельский научный центр Российской академии наук Научное обоснование развития сети особо охраняемых природных территорий в Республике Карелия Петрозаводск 2009 УДК 502.172 (470.22) ББК 20.18 (2Рос. Кар.) Н 34 Научное обоснование развития сети особо охраняемых природных территорий в Республике Карелия. Петрозаводск: Карельский научный центр РАН, 2009. 112 с.: ил. 14, табл. 6. Библиограф. 96 назв. ISBN...»

«УДК 004.432 ББК 22.1 Х27 Хахаев И. А. Х27 Практикум по алгоритмизации и программированию на Python: / И. А. Хахаев М. : Альт Линукс, 2010. 126 с. : ил. (Библиотека ALT Linux). ISBN 978-5-905167-02-7 Учебно-методический комплекс Практикум по алгоритмизации и программированию на Python предназначен для начального знакомства с основными алгоритмами и с программированием на языке Python в интегрированных средах разработки (IDE) Geany и Eric. Комплекс состоит из учебного пособия, в котором...»

«ДОКЛАДЫ БГУИР №2 ЯНВАРЬ–МАРТ 2004 УДК 538.945 НАНОЭЛЕКТРОНИКА И НАНОТЕХНОЛОГИЯ В БЕЛОРУССКОМ ГОСУДАРСТВЕННОМ УНИВЕРСИТЕТЕ ИНФОРМАТИКИ И РАДИОЭЛЕКТРОНИКИ: ОТ ПЕРВЫХ ШАГОВ ДО СЕГОДНЯШНЕГО ДНЯ В.Е. БОРИСЕНКО Белорусский государственный университет информатики и радиоэлектроники П. Бровки, 6, Минск, 220013, Беларусь Поступила в редакцию 19 ноября 2003 Представлены основные этапы развития работ по наноэлектронике и нанотехнологии в БГУИР. Показаны организационная структура научных исследований и...»

«Математическая биология и биоинформатика. 2011. Т. 6. № 1. С.102–114. URL: http:// www.matbio.org/2011/Abakumov2011(6_102).pdf ================== МАТЕМАТИЧЕСКОЕ МОДЕЛИРОВАНИЕ ================= УДК: 577.95 Неопределенность при моделировании экосистемы озера * **2 ©2011 Пахт Е.В. 1, Абакумов А.И. 1 ФГОУ ВПО Дальневосточный государственный технический рыбохозяйственный университет, Владивосток, 690087, Россия 2 Учреждение Российской академии наук Институт автоматики и процессов управления ДВО РАН,...»

«МОСКОВСКИЕ УЧЕБНО-ТРЕНИРОВОЧНЫЕ СБОРЫ ПО ИНФОРМАТИКЕ весна – 2006 Под редакцией В. М. Гуровица Москва Издательство МЦНМО 2007 УДК 519.671 ББК 22.18 ОГЛАВЛЕНИЕ М82 Московские учебно-тренировочные сборы по информатике. М82 Весна–2006 / Под ред. В. М. Гуровица М.: МЦНМО, Введение.......................................... 5 2007. 194 с.: ил. ISBN ?-?????-???-? I Задачи практических туров Книга предназначена для школьников, учителей информатики, студен-...»

«1 Общие положения Полное наименование вуза на русском языке: федеральное государственное бюджетное образовательное учреждение высшего профессионального образования Тихоокеанский государственный университет. Сокращенные наименования вуза на русском языке: Тихоокеанский государственный университет, ФГБОУ ВПО ТОГУ, ТОГУ. Полное наименование на английском языке: Pacific National University. Сокращенное наименование на английском языке: PNU. Место нахождения вуза: 680035, г. Хабаровск, ул....»





Загрузка...



 
© 2014 www.kniga.seluk.ru - «Бесплатная электронная библиотека - Книги, пособия, учебники, издания, публикации»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.