Содержание


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

Принципы автоматизации развертывания приложений, часть 1

Развертывание приложений одним нажатием на кнопку

Comments

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

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

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

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

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

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

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

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

Дополнительные принципы будут рассмотрены в следующей части.

На рисунке 1 показаны связи между принципами развертывания, рассматриваемыми в настоящей статье.

Рисунок 1. Принципы автоматизации развертывания
Deployment-automation patterns
Deployment-automation patterns

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

Сохранение всех файлов в системе контроля версий

Название. Репозиторий

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

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

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

Выполнение всех процессов развертывания при помощи скриптов

Название. Развертывание при помощи скриптов

Принцип. Все процессы, участвующие в развертывании, реализуются в виде скриптов.

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

В листинге 1 иллюстрируется развертывание при помощи скриптов на примере автоматизации процесса перезапуска контейнера Tomcat. Весь процесс описывается на скриптовом языке Apache Ant.

Листинг 1. Пример запуска Web-контейнера Tomcat
<available file="@{tomcat.home}/server/@{tomcat.server.name}/bin" 
   property="tomcat.bin.exists"/>
<if>
  <isset property="tomcat.bin.exists"/>
<then>
  <echo message="Starting tomcat instance at @{tomcat.home} with start_tomcat" />
  <exec executable="@{tomcat.home}/server/@{tomcat.server.name}/bin/start_tomcat" 
   osfamily="unix" />
</then>
<else>
  <echo message="Starting tomcat instance at @{tomcat.home} with startup.sh" />
  <exec osfamily="unix" executable="chmod" spawn="true">
    <arg value="+x" />
    <arg file="@{tomcat.home}/bin/startup.sh" />
    <arg file="@{tomcat.home}/bin/shutdown.sh" />
  </exec>
		
  <exec executable="sh" osfamily="unix" dir="@{tomcat.home}/bin" spawn="true">
    <env key="NOPAUSE" value="true" />
    <arg line="startup.sh" />
  </exec>

    <exec osfamily="windows" executable="cmd" dir="@{tomcat.home}/bin" spawn="true" >
      <env key="NOPAUSE" value="true" />
        <arg line="/c startup.sh" />
    </exec>
    <sleep seconds="15" />
    </else>
  </if>

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

Запуск процесса развертывания одной командой

Название. Принцип одной команды

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

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

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

Листинг 2. Пример развертывания путем выполнения одной команды при помощи Ant
ant -Dproperties.file=$USERHOME/projects/petstore/properties/dev-install.properties \
  deploy:remote:install

Команда, приведенная в листинге 2, вызывает задачу Ant под названием deploy:remote:install, которая выполняет развертывание приложения на удаленных компьютерах. При этом ей передается имя файла, содержащего значения параметров, специфичных для конкретного окружения. Далее задача выполняет такие действия, как безопасное копирование файлов по протоколу SCP (Secure Copy protocol), безопасное выполнение команд на удаленных машинах при помощи SSH (Secure Shell), установка, конфигурирование и перезапуск Web-контейнеров. Все это делается автоматически, т.е. без участия человека. Разумеется, первоначальная команда может быть вызвана человеком, но с тем же успехом ее может выполнять автономный процесс, например сервер непрерывной интеграции или управления сборкой.

Вставка значений переменных в конфигурационные файлы

Название. Токенизация конфигурирования

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

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

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

Листинг 3. Пример токенизированного файла конфигурации Web-контейнера
<datasources>
  <local-tx-datasource>
    <jndi-name>@application.context.name@</jndi-name>
    <use-java-context>false</use-java-context>
    <connection-url>@database.url@</connection-url>
    <user-name>@database.user@</user-name>
    <password>@database.password@</password>
    <driver-class>@database.driver@</driver-class>
  </local-tx-datasource>
</datasources>

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

Вынос всех зависящих от среды параметров во внешние свойства

Название. Внешнее конфигурирование

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

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

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

Листинг 4. Пример свойств, которые являются внешними по отношению к приложению
authentication.type=db
application.url=http://${tomcat.server.hostname}:${tomcat.server.port}/brewery-webapp
database.type=mysql
database.server=localhost
database.port=3306
database.name=mydb
database.user=myuser!
database.password=mypa$$!
database.url=jdbc:mysql://${database.server}:${database.port}/${database.name}
tomcat.server.hostname=localhost
tomcat.server.name=default
tomcat.web.password=pa$$123!
tomcat.cobraorb.port=12748

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

Экономьте свое время при помощи автономных процессов

Название. Автономное выполнение

Принцип. Безопасное развертывание на нескольких серверах без вмешательства человека.

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

Автономные процессы являются эффективным подходом к проблеме автоматического развертывания приложения на удаленных серверах. Инфраструктура на основе открытых ключей (PKI) позволяет автоматически управлять командами, которые обычно выполняются разработчиками, инженерами сборки, членами команды управления конфигурированием (SCM) и операционистами. В схеме, показанной на рисунке 2, файл с секретным ключом находится на сервере, выполняющем сборку системы, доступ к которому осуществляется через SSH. Параметры, специфичные для конкретной среды развертывания, содержатся в файлах свойств (.properties). К ним, как правило, относятся такие параметры, как имя и расположение файла с секретным ключом, а также имя компьютера и порт для доступа по SSH. При этом серверы, на которых будет развернуто приложение, содержат файлы с открытым SSH-ключом для выполнения процедуры обмена ключами (SSH handshake).

Рисунок 2. Использование ключей SSH при реализации принципа автономного выполнения
Using SSH keys to implement Headless Execution pattern
Using SSH keys to implement Headless Execution pattern

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

Проверка идентичности атрибутов во всех средах развертывания

Название. Проверка по шаблону

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

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

Необходимо гарантировать, что при развертывании в нескольких различных окружениях используется единый набор атрибутов. При автоматизированном процессе развертывания этого можно добиться, создав единственный шаблонный файл свойств, относительно которого можно проверять файлы, содержащие свойства, специфичные для конкретного окружения. Таким образом, вы будете уверены, что вне зависимости от среды развертывания будут использованы одни и те же атрибуты. На рисунке 3 показана задача Ant, которая сравнивает атрибуты (а не их значения) в шаблонном файле с атрибутами в специфичных файлах (dev.properties, qa.properties и т.д.). Если будет выявлено расхождение, то процесс развертывания завершится с ошибкой.

Рисунок 3. Реализация принципа проверки по шаблону
Implementation of Template Verifier pattern

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

Листинг 5. Шаблон, содержащий только список атрибутов без их значений
db.database=
db.username=
db.password=
db.hostname=
db.driver=
db.port=
db.url=

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

Листинг 6. Файл, содержащий свойства и их значения, специфичные для конкретной среды развертывания
db.database=brewery
db.username=root
db.password=p@ssword
db.hostname=dev1.domain.com
db.driver=com.mysql.jdbc.Driver
db.port=3306
db.url=jdbc:mysql://${db.hostname}:${db.port}/${db.database}

Одновременное развертывание в нескольких средах

Название. Унифицированное развертывание

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

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

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

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

Рисунок 4. Схема одного развертывания в нескольких целевых средах
Single deployment, multiple target environments
Single deployment, multiple target environments

Это еще не все

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


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


Похожие темы


Комментарии

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

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