Содержание


Agile DevOps ― гибкая разработка и эксплуатация ПО

Кратковременные среды

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

Comments

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

Этот контент является частью # из серии # статей: Agile DevOps ― гибкая разработка и эксплуатация ПО

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

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

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

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

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

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

Мотивы

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

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

Особенности

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

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

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

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

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

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

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

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

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

  • составить правила группы: вместе с членами группы определить ее правила на основе требований проекта. Я рекомендую начать агрессивно и регулярно сокращать количество часов жизни этой среды — примерно до 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, чтобы убедиться, что в случае отказа система продолжает работать.


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


Похожие темы

  • Оригинал статьи: Agile DevOps: Transient environments.
  • Дефицит: статья в Википедии, посвященная экономическому дефициту (EN).
  • Automation for the people: Deployment-automation patterns, Part 2 (Paul Duvall, developerWorks, февраль 2009 г.): о модели развертывания «одноразовый контейнер».
  • Сервер отказал, ну и что?: Грегг Ульрих из Netflix рассказывает, почему Netflix для надежной работы не полагается ни на одну конкретную среду (EN).
  • Quartz: служба планирования заданий с открытым исходным кодом.
  • IBM Tivoli® Provisioning Manager: Tivoli Provisioning Manager позволяет создавать динамическую инфраструктуру, автоматизируя управление физическими серверами, виртуальными серверами, программным обеспечением, системами хранения данных и сетью.
  • IBM Tivoli System Automation for Multiplatforms: Tivoli System Automation for Multiplatforms обеспечивает высокую готовность и автоматизацию приложений и ИТ-услуг по всей организации.

Комментарии

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

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