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

Создание иллюзии изобилия сред для уменьшения дефицита

Часто после инициализации среды коллективного пользования она никогда не ликвидируется и может работать неделями или месяцами, причем на протяжении этого срока инженеры вносят в нее всяческие ручные настройки и изменения. Этот рискованный подход регулярно вызывает проблемы развертывания и другие странные ошибки «окружения», происходящие во время циклов разработки, тестирования и производства. В этой статье из цикла Agile DevOps говорится о том, как создать эфемерную среду, которая быстро ликвидируется. Когда тестовая среда описана сценариями и находится под контролем версий, ее можно использовать ровно столько времени, сколько нужно для выполнения набора тестов по мере продвижения программного обеспечения к производству по конвейеру поставки.

Пол Дюваль, технический директор, 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 г.).



01.03.2013

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

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

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

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

Иногда ее называют другими именами: эфемерная, временная или одноразовая среда. Все это, по сути, означает одно и то же: непроизводственную среду, которая живет как можно меньше. В последнее время моя компания рекомендует не более 72 часов — и это максимум.

Мотивы

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

Что такое среда?

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

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


Особенности

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

Вот основные особенности кратковременной среды:

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

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


Преимущества

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

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

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

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

Как это работает

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

  • составить правила группы: вместе с членами группы определить ее правила на основе требований проекта. Я рекомендую начать агрессивно и регулярно сокращать количество часов жизни этой среды — примерно до 72 часов;
  • автоматизировать ликвидацию среды: напишите сценарий, который ликвидирует все среды, превышающие установленные правила аренды;
  • запланировать ликвидацию среды: спланируйте процесс регулярного запуска, выполняющий сценарий ликвидации среды.

Основывайте правила группы на времени, необходимом для проведения всех необходимых тестов.

Чтобы запланировать ликвидацию среды, можно начать с использования планировщика, такого как cron или — если вы работаете с Java — Quartz (см. раздел Ресурсы). Для ежедневного регулярного запуска заданий можно также использовать планировщик, предоставляемый сервером непрерывной интеграции. В следующем примере приведено простое выражение cron, которое запускает сценарий каждый день в 2:15 ночи.

0 15 02 * * /usr/bin/delete_envs.sh

А вот пример использования интерфейса командной строки, предоставляемого Amazon Web Services (AWS) CloudFormation, для ликвидации среды в соответствии с определением стека CloudFormation:

/opt/aws/apitools/cfn/bin/cfn-delete-stack --access-key-id $AWS_ACCESS_KEY \
--secret-key $AWS_SECRET_ACCESS_KEY --stack-name $current_stack_name --force

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

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

Устранение неполадок

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

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


Мимолетность навсегда

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

Следующая статья из цикла Agile DevOps будет посвящена созданию условий постоянных отказов — как это ни парадоксально, с целью предотвращения отказа. В ней я расскажу о Chaos Monkey ― инструменте, созданном технической группой компании Netflix, который регулярно ― намеренно и случайным образом ― отключает отдельные экземпляры в производственной инфраструктуре Netflix, чтобы убедиться, что в случае отказа система продолжает работать.

Ресурсы

Научиться

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

  • Quartz: служба планирования заданий с открытым исходным кодом.
  • 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, Облачные вычисления
ArticleID=860113
ArticleTitle=Agile DevOps ― гибкая разработка и эксплуатация ПО: Кратковременные среды
publish-date=03012013