Agile DevOps ― гибкая разработка и эксплуатация ПО: Непрерывная поставка программного обеспечения в облаке

Использование открытой платформы Continuous Delivery

Когда разработчики и производственные подразделения предприятия сотрудничают, им часто требуется общее место, чтобы управлять процессом поставки программного обеспечения и конвейером изменений. Платформа Continuous Delivery (CD) удовлетворяет эту потребность. В этом выпуске цикла Agile DevOps эксперт по гибкой разработке Пол Дюваль показывает, как можно использовать открытую платформу CD OpenDelivery.

Пол Дюваль, технический директор, Stelligent Incorporated

Paul DuvallПол Дюваль (Paul Duvall) является техническим директором компании Stelligent Incorporated – консалтинговой фирмы, которая помогает командам разработчиков оптимизировать гибкие методологии разработки программного обеспечения. Он также соавтор книги Continuous Integration: Improving Software Quality and Reducing Risk (Addison-Wesley, 2007 г.). Он принимал участие в создании книг UML 2 Toolkit (Wiley, 2003 г.) и No Fluff Just Stuff Anthology (Pragmatic Programmers, 2007 г.).



19.03.2013

Об этом цикле статей

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

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

Эта статья знакомит читателя с платформой CD с открытым исходным кодом OpenDelivery, разработанной компанией Stelligent. OpenDelivery сочетает в себе инструменты с открытым исходным кодом, облачную инфраструктуру и сценарии. Она поддерживает идею, что вся программная система должна быть представлена кодом. Все сценарии находятся под контролем версий в репозитории GitHub. OpenDelivery использует многочисленные инструменты для создания платформы, перечисленные в таблице 1, и поддерживает Rails, Grails и Java™-разработку на Linux™. В этой статье я опишу основные шаги по применению этой платформы с использованием конвейера поставки и запуску заданий для инициализации рабочей среды и развертывания приложений.

Таблица 1. Инструменты, используемые платформой OpenDelivery
ИнструментОписание
Amazon Web Services (AWS) CloudFormationПлатформа OpenDelivery использует CloudFormation — язык шаблонов для описания инициализации ресурсов AWS — в целях полной автоматизации инфраструктуры среды Jenkins и конфигурации ресурсов AWS целевой рабочей среды.
Amazon Elastic Compute Cloud (EC2)OpenDelivery использует EC2 для всех своих экземпляров машин.
Amazon CloudWatchOpenDelivery использует CloudWatch для контроля некоторых базовых рабочих параметров и отправляет уведомления Simple Notification Service (SNS) при превышении пороговых значений.
Amazon Route 53Route 53 — это высоконадежная и масштабируемая DNS, которую OpenDelivery использует для задания доменов конечных точек на основе предпочтений пользователя.
Amazon SimpleDBSimpleDB ― это высоконадежная и масштабируемая база данных NoSQ. OpenDelivery использует ее для хранения параметров конфигурации конвейера, таких как IP-адреса и имена стеков CloudFormation.
Amazon Simple Notification Service (SNS)OpenDelivery использует SNS для отправки сообщений при создании рабочей среды.
Amazon Simple Storage Service (S3)OpenDelivery использует S3 для хранения временных файлов, используемых платформой.
CapistranoCapistrano ― это специальный DSL для среды развертывания на основе Ruby, который OpenDelivery использует для развертывания приложений.
GitHubНа GitHub размещается исходный код OpenDelivery. Пользователи OpenDelivery применяют учетную запись GitHub для своего кода приложений.
JenkinsJenkins — это сервер непрерывной интеграции (CI). OpenDelivery использует Jenkins в качестве платформы для запуска всех сборок и установок кода приложений, конфигурации, данных и изменений инфраструктуры.
PuppetPuppet ― это инструмент автоматизации инфраструктуры со своим собственным предметно-ориентированным языком (DSL). Вся автоматизация инфраструктуры целевой среды написана на Puppet и вызывается в CloudFormation.
RubyБольшинство сценариев, автоматизирующих конвейер, написано на Ruby.

Предварительные условия

Вот три предварительных условия успешной установки платформы OpenDelivery:

  • CloudFormation: подпишитесь на AWS CloudFormation, чтобы получить доступ ко всем требуемым службам, используемым OpenDelivery.
  • GitHub: необходимо иметь учетную запись GitHub. Регистрация на GitHub осуществляется бесплатно.
  • Route 53: Нужно настроить зону размещения в Route 53 для своего домена. Этот домен будет использоваться в сценариях OpenDelivery для обращения к тем ресурсам, которые создаются в составе платформы.

Ссылка на краткое руководство по OpenDelivery приведена в разделе Ресурсы. Имейте в виду, что при работе с OpenDelivery AWS берет плату за использование ресурсов.

Инициализация платформы непрерывной интеграции

Первым шагом по установке платформы CD OpenDelivery для своих проектов является подготовка сервера CI Jenkins в AWS. Сначала запустите шаблон установки CloudFormation. Вам будет предложено ввести следующие параметры:

  • ApplicationName: префикс CNAME для создаваемой среды CI Jenkins. Например, http://ApplicationName.domainname.com.
  • GithubUsername: ваше имя пользователя GitHub.
  • ProjectName: имя проекта GitHub. Например, если URL-адрес моего проекта GitHub https://github.com/stelligent/continuous_delivery_open_platform, то имя ProjectName будет continuous_delivery_open_platform.
  • Email: адрес электронной почты, на который будут отправляться сообщения.
  • HostedZone: имя домена, которым вы владеете и в котором размещается зона Route 53.
  • GithubOrganization: имя организации в GitHub. Например, если URL-адрес моего проекта GitHub https://github.com/stelligent/continuous_delivery_open_platform, то GithubOrganization будет stelligent.
  • GithubPassword: пароль GitHub для ваших GithubOrganization и ProjectName.
  • KeyName: имя пары ключей EC2. Не следует добавлять никаких суффиксов имени файла.
  • InstanceType: тип экземпляра EC2. Если вы не уверены, используйте значение по умолчанию.

После завершения работы мастера сборка платформы займет около 20 минут. После этого перейдите в консоль CloudFormation и установите флажок рядом с jenkinsstack. Затем перейдите на вкладку Outputs. Скопируйте значение из строки ключа Domain и введите его в Web-браузер, чтобы запустить вновь созданный сервер CI Jenkins в AWS. Вы увидите начальную конфигурацию Jenkins, показанную на рисунке 1.

Рисунок 1. Начальная конфигурация Jenkins после инициализации с использованием CloudFormation
Начальная конфигурация Jenkins после инициализации с использованием CloudFormation Показаны также две вкладки: DeliveryPipeline и Email Group Administration.

Конвейер CD

В OpenDelivery входит готовый стандартный конвейер поставки. Он последовательно выполняет задачи Jenkins StartDeliveryPipeline, Build, CreateTargetEnvironment и DeployApplication. Если любая из этих задач заканчивается неудачно, конвейер выдает ошибку, и программное обеспечение не развертывается.

Пример конвейера поставки — как он представлен в системе Jenkins — приведен на рисунке 2.

Рисунок 2. Конвейер поставки, как он представлен на сервере непрерывной интеграции Jenkins
Конвейер поставки

На рисунке 2 программное обеспечение проходит три этапа. Во-первых, после того как сборка прошла процесс CI, Jenkins выполняет всю необходимую настройку с помощью задания StartDeliveryPipeline. Затем он создает целевую среду с помощью задания CreateTargetEnvironment. Наконец, он развертывает приложение в целевой среде, как оно представлено в задании DeployApplication. Эти три этапа выполняются как единая задача, в которой, если любое из заданий не удается, конвейер перестает работать.

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


Инициализация целевой среды

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

Конвейер поставки OpenDelivery создает среду с нуля, вызывая шаблон CloudFormation. Этот шаблон выполняет сценарии Puppet (вызывая puppet apply). (Подробнее о Puppet см. в статье Agile DevOps ― гибкая разработка и эксплуатация ПО: автоматизация инфраструктуры.

В листинге 1 показана часть шаблона CloudFormation, которая вызывает Puppet.

Листинг 1. Фрагмент кода CloudFormation из production.template, который вызывает Puppet
"# Установка Ruby 1.9.3\n",
"rpm -Uvh /tmp/ruby-1.9.3p0-2.amzn1.x86_64.rpm\n",

"# Установка Puppet 3.0.1 from Rubygem\n",
"gem install puppet --no-rdoc --no-ri\n",
"groupadd puppet\n",

"# Запуск Puppet\n",
"puppet apply --modulepath=/home/ec2-user/modules /home/ec2-user/manifests/site.pp\n",
...

OpenDelivery предоставляет эти сценарии из своего репозитория GitHub. Стандартные сценарии, используемые для серверов и конфигурации инфраструктуры, можно изменить.


Выполнение развертывания

Будьте в курсе

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

Автоматическое развертывание выполняется в Capistrano. Capistrano можно использовать для развертывания систем разного типа и на разных платформах ОС. Процесс развертывания запускается посредством заданий Jenkins в среде, созданной по сценариям CloudFormation иPuppet, описанным в предыдущем разделе. За запуск сценариев, которые выполняют развертывание, отвечает задание Jenkins DeployApplication.

Фрагмент кода, приведенный в листинге 2, демонстрирует сценарий Capistrano, который выполняет задания preconfigure и deploy.

Листинг 2. Фрагмент сценария Capistrano deploy.rb, который приводит среду в исходное состояние и выполняет развертывание.
task :preconfigure do
  run "cd #{deploy_to} && sudo rm -rf #{deploy_to}/#{artifact_name}"
  config_content = from_template("config/templates/s3_download.erb")
  put config_content, "/home/ec2-user/s3_download.rb"
  run "sudo chmod 655 /home/ec2-user/s3_download.rb"
end

task :deploy do
  run "sudo ruby /home/ec2-user/s3_download.rb --outputdirectory #{deploy_to}/ \
    --bucket #{s3_bucket} --key #{artifact}"
  case
  when language == "rails"
    run "cd #{deploy_to} && sudo tar -zxf #{artifact}"
    run "sudo chown -R ec2-user:ec2-user #{deploy_to}/#{artifact_name}"
  end
end
...
case
when language == "rails"
after "preconfigure", "deploy", "database:configuration", "stripe:initializer", \
      "bundler:install", "database:migration", "virtualhost:configuration", \
      "whenever:set", "postconfigure", "restart"

Другие рецепты Capistrano находятся в подкаталоге каталога с именем развертываемой системы в репозитории GitHub OpenDelivery. В листинге 2 примеры этих рецептов называются stripe (stripe.rb) и virtualhost (virtualhost.rb). Рецепты можно добавлять, изменять и удалять по собственному усмотрению.


Непрерывное тестирование

В платформу OpenDelivery входят основные приемочные тесты Cucumber, которые проверяют инфраструктуру (CI и целевые среды) и установки. Эти тесты запускаются каждый раз при изменении сценариев, которые инициализируют среду или запускают процесс развертывания посредством заданий CreateTargetEnvironment и DeployApplication соответственно. Пример, приведенный в листинге 3, взят из Cucumber-сценария на платформе OpenDelivery, который проверяет, что определенные серверные компоненты установлены и работают.

Листинг 3. Фрагмент Cucumber-сценария на платформе OpenDelivery (production.feature), который запускает автоматизированные тесты среды
Feature: Scripted Provisioning of Target Environment
As a Developer
I would like my target environment provisioned correctly
so I can deploy applications to it

Background:
Given I am sshed into the environment

Scenario: Is the proper version of Postgresql installed?
When I run "/usr/bin/postgres --version"
Then I should see "8.4"

Scenario: Is the proper version of Apache installed?
When I run "/usr/sbin/httpd -v"
Then I should see "2.2"

...

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


Сборка, развертывание, тестирование и выпуск при каждом изменении

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

Ресурсы

Научиться

Получить продукты и технологии

  • OpenDelivery: исходный код и шаблоны для запуска платформы OpenDelivery.
  • IBM Tivoli Provisioning Manager: Tivoli® Provisioning Manager позволяет создавать динамическую инфраструктуру, автоматизируя управление физическими серверами, виртуальными серверами, программным обеспечением, системами хранения данных и сетью.
  • IBM Tivoli System Automation for Multiplatforms: Tivoli System Automation for Multiplatforms обеспечивает высокую готовность и автоматизацию приложений и ИТ-услуг по всей организации.

Комментарии

developerWorks: Войти

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


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


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

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

 


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

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

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



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

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

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

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

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

 


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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Технология Java, Open source, Облачные вычисления
ArticleID=861812
ArticleTitle=Agile DevOps ― гибкая разработка и эксплуатация ПО: Непрерывная поставка программного обеспечения в облаке
publish-date=03192013