Содержание


Практическая автоматизация

Быстрое автоматизированное развертывание

Эффективное использование автоматизации для быстрого развертывания программного обеспечения в различных средах

Comments

Серия контента:

Этот контент является частью # из серии # статей: Практическая автоматизация

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Практическая автоматизация

Следите за выходом новых статей этой серии.

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

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

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

Внедрение может быть безболезненным

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

  • Развертывание двоичных файлов на удаленных системах
  • Выделение конфигурационных параметров
  • Дистанционное обновление СУБД MySQL
  • Дистанционное конфигурирование сервлет-контейнера Jakarta Tomcat

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

Необходимые инструменты

Главным инструментом для автоматизации развертывания является сценарий сборки; в данном случае это будет Ant. Представленный сценарий Ant будет использовать файлы .properties (разные для разных целевых систем, например, предварительного тестирования (staging) и конечной (production)), взаимодействовать с базой данных MySQL посредством задачи sql из арсенала Ant, а также использовать Java Secure Channel (JSch) для копирования файлов на удаленные компьютеры (с помощью протокола Secure-Copy (SCP)) и остановки и запуска сервисов Tomcat (через SSH).

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

Рис. 1. Обобщенная структура сборки для дистанционного развертывания
Рис. 1. Обобщенная структура сборки для дистанционного развертывания
Рис. 1. Обобщенная структура сборки для дистанционного развертывания

Можно автоматизировать все эти процессы, чтобы запускать развертывание одной командой или нажатием кнопки мыши или даже планировать его выполнение без вмешательства человека. Заманчиво?

Выделение свойств

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

В листинге 1 показан простой пример определения свойств в сценарии сборки Ant, который дает возможность передавать файл .properties в качестве системного параметра (например, test.properties), содержащего все значения для конкретной целевой среды. Значением параметра property.file.location может быть путь, например, C:\Documents and Settings\patrick.henry\test.properties. Например, в командной строке можно написать: ant -Dproperty.file.location=C:\Documents and Settings\patrick.henry\test.properties.

Листинг 1. Выделение атрибутов свойств
<property file="${property.file.location}" />

Пример файла .properties для целевой среды приведен в листинге 2. В этом файле значения атрибутов должны (или могут) варьироваться от одной целевой среды к другой, но названия атрибутов всегда должны оставаться теми же.

Листинг 2. Пример атрибутов и соответствующих значений в файле свойств
db.database=brewery
db.username.system=root
db.password.system=sa
db.username=root
db.password=sa
db.hostname=my-hostname.domain.com
db.driver=com.mysql.jdbc.Driver
db.port=3306
db.url.system=jdbc:mysql://${db.hostname}:${db.port}/
db.url=jdbc:mysql://${db.hostname}:${db.port}/${db.database}

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

Упрощение на базовом уровне

Развертывание программного обеспечения в другой среде не должно быть неприятным процессом; оно, по моему мнению, должно быть не сложнее ввода команды deploy в командной строке. К счастью, такие системы сборки, как Ant, позволяют этого достичь. Логически определив рабочий процесс, последовательно выполняющий ряд шагов, можно затем создать одну команду, которая запускает их.

Цели Ant, перечисленные в атрибуте depends в листинге 3, в обобщенном виде определяют настоящее автоматизированное развертывание. Сначала сценарий удаляет из локальной среды все ранее созданные артефакты (с помощью цели clean), компилирует исходный код, дистанционно создает базу данных, вводит тестовые данные, запускает базу данных и, наконец, дистанционно развертывает WAR-файл в контейнере Tomcat, находящемся в целевой среде.

Листинг 3. Ключевые цели, выполняемые при дистанционном развертывании
<target name="build" 
  depends="clean, compile, refresh-database, remote-tomcat-deploy" />

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

Автоматизация администрирования базы данных

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

Команды языка определения данных (Data Definition Language, DDL), например, удаление существующей базы данных, создание базы данных и создание пользователей базы данных, а за ними такие команды языка манипулирования данными (Data Manipulation Language, DML), как insert, легко могут быть внесены в сценарий и запущены в составе сборочного сценария Ant. Более того, эти команды можно выполнять дистанционно.

Например, если передавать свойство db.url.system (из файла .properties целевой среды), как это показано в листинге 4, сценарий сборки может выполнять команды SQL на удаленной базе данных:

Листинг 4. Сценарий для создания базы данных и добавления данных
<target name="refresh-database" depends="create-database,insert-data" />
<target name="create-database">
  <sql driver="${db.driver}"
    url="${db.url.system}" 
    userid="${db.username.system}"
    password="${db.password.system}"
    src="${database.dir}/create-database.sql"> 
    <classpath>
      <pathelement location="${mysql-connector.jar}"/>
    </classpath>
  </sql>
</target>
...
<target name="insert-data">
  <sql driver="${db.driver}"
    url="${db.url}"
    userid="${db.username}"
    password="${db.password}"
    src="${database.dir}/insert-data.sql">
    <classpath>
      <pathelement location="${mysql-connector.jar}"/>
    </classpath>
  </sql>
</target>

Содержимое файла insert-data.sql, приведенное в листинге 5, вызывается из цели insert-data в листинге 4. Любые SQL-инструкции, будь то DDL или DML, могут быть выполнены аналогичным способом с помощью задачи sql из набора задач Ant.

Листинг 5. SQL-предложения, вставляющие данные
insert into beer(id, beer_name, date_received) values 
  (1, 'Samuel Adams Lager','2006-12-09');
insert into beer(id, beer_name, date_received) values 
  (2, 'Guinness Stout','2006-12-29');
insert into beer(id, beer_name, date_received) values 
  (3, 'Olde Saratoga Lager','2007-02-14');
insert into beer(id, beer_name, date_received) values 
  (4, 'Sierra Nevada Pale Ale','2007-05-14');

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

Распространение и развертывание

Осуществление дистанционного развертывания не сильно отличается от локального развертывания, для него просто требуется другой канал для безопасного копирования всего необходимого из одного места в другое (с машины для сборки на целевую систему). На большинстве предприятий безопасность является одной из приоритетных задач, поэтому простая пересылка файлов с помощью FTP и telnet не всегда подходят. В этом случае эту работу легко выполнить с помощью SCP и SSH. Эти каналы легко использовать из Ant. Я часто применяю задачи sshexec и scp из JSch для дистанционного копирования файлов и запуска команд на удаленных компьютерах.

Безопасное копирование файлов с помощью SCP

SCP обеспечивает возможность безопасного копирования ресурсов с одной машины на другую. Существует множество инструментов, поддерживающих SCP. Неудивительно, что JSch в Ant использует SCP для копирования ресурсов (например, файлов JAR) без человеческого вмешательства, то есть автоматически.

В листинге 6 задача scp (предоставляемая JSch) копирует (в данном случае) WAR-файл со сборочной системы на удаленный компьютер. Чтобы можно было использовать задачу scp, библиотека JSch (jsch-0.1.36.jar) должна быть в CLASSPATH Ant.

Листинг 6. Безопасное копирование WAR-файла с одной машины на другую
<target name="copy-tomcat-dist">
  <scp file="${basedir}/target/brewery.war" 
  trust="true" 
  keyfile="${ssh.key.file}"
  username="${ssh.username}"
  passphrase=""
  todir="${ssh.server.username}:${ssh.server.password}@${ssh.server.hostname}
  :${tomcat.home}/webapps" />
</target>

При вызове задачи scp необходимо указать местоположение локального файла, предназначенного для копирования, а также местоположение локального файла с закрытым ключом SSH (ssh.key.file в листинге 6, используется для безопасной идентификации). Наконец, необходимо также указать местоположение на удаленной системе (ssh.server.hostname в листинге 6), куда scp должен поместить локальный файл (или файлы).

Дистанционный запуск процессов с помощью SSH

Как и в случае SCP, для запуска команд на удаленной системе часто требуется безопасный механизм, например, SSH. В листинге 7 для остановки и перезапуска контейнера Tomcat, находящегося на удаленном компьютере, используется задача Ant sshexec из JSch. Предполагается, что это та же система, на которую процесс сборки только что безопасно скопировал набор ресурсов, например, WAR-файлов.

Листинг 7. Остановка и запуск удаленного экземпляра Tomcat
<target name="remote-tomcat-stop>
  <sshexec host="${ssh.hostname}"
  port="${ssh.port}"  
  keyfile="${ssh.key.file}"
  username="${ssh.username}"
  passphrase=""
  trust="true"
  command="${tomcat.home}/bin/shutdown" />
  <sleep seconds="${sleep.time}" />
</target>
...
<target name="remote-tomcat-start">
  <sshexec host="${ssh.hostname}"
  port="${ssh.port}"
  username="${ssh.username}" 
  passphrase=""
  trust="true"
  keyfile="${ssh.key.file}" 
  command="${tomcat.home}/bin/startup" />
  <sleep seconds="${sleep.time}" />
</target>

В листинге 7 указаны имя компьютера, на котором находится Tomcat, номер порта для Tomcat (обычно это 8080) и файл закрытого ключа (ssh.key.file), поэтому сценарий сборки может безопасно получить доступ к машине и выполнить специальную команду. Видно, что в этом случае запускается команда shutdown, а за ней команда startup.

Эти последние шаги естественным образом завершают дело: удаленная база данных сконфигурирована, Web-приложение перенесено на удаленную систему, экземпляр Tomcat обновлен. Таким образом, новая версия приложения теперь работает, ее можно тестировать и эксплуатировать.

Автоматизированное развертывание на практике

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


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


Похожие темы

  • Automation for the people: Speed deployment with automation: оригинал статьи (EN).
  • Database Integration in your Build scripts (Пол Дювал, testearly.com, июнь 2006 г.) (EN): обновление БД и данных с каждой сборкой.
  • SmartFrog (EN): ресурс о конфигурировании распределенного развертывания (есть задачи Ant для выполнения).
  • Derby database development with Apache Ant (Джеймс Снелл (James Snell), developerWorks, декабрь 2004 г.) (EN): знакомство с задачами Apache Ant, облегчающими интеграцию базы данных в процесс сборки.
  • Developing Web applications with Tomcat and Eclipse (Натан А. Гуд (Nathan A. Good), developerWorks, май 2007 г.) (EN): Apache Tomcat и Eclipse Platform составляют отличную платформу для Web-разработки.
  • JSch: загрузить Java Secure Channel для использования безопасных коммуникаций.(EN)
  • Ant: загрузить Ant, чтобы начать создавать программное обеспечение в предсказуемом и воспроизводимом режиме.(EN)
  • Tomcat: загрузить Web-контейнер Tomcat для быстрого создания Web-приложений.(EN)
  • DbUnit: загрузить DbUnit, чтобы использовать XML для управления данными.(EN)
  • Примеры: примеры сценариев из статьи.(EN)
  • Automation for the people (Пол Дювал, developerWorks) (EN): все статьи серии.
  • Раздел Технология Java : сайта developerWorks: сотни статей обо всех аспектах Java-программирования.

Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Технология Java
ArticleID=438162
ArticleTitle=Практическая автоматизация: Быстрое автоматизированное развертывание
publish-date=10192009