Джин Ким - Руководство по DevOps

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

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

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

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

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

• копирование виртуализированной среды (например, образа VMware, запуск сценария Vagrant, загрузка файла Amazon Machine Image в EC2);

• создание процесса автоматизированного формирования среды, который начинает работу с нуля (например, PXE — установка из базовых образов);

• с помощью инструментов управления конфигурациями «инфраструктура как код» (например, Puppet, Chef, Ansible, Salt, CFEngine и так далее);

• с помощью автоматизированных инструментов конфигурации операционной системы (например, Solaris Jumpstart, Red Hat Kickstart, Debian preseed);

• сборка среды из набора виртуальных образов или контейнеров (например, Vagrant, Docker);

• сборка новой среды в общедоступной среде облачных вычислений (например, Amazon Web Services, Google App Engine, Microsoft Azure), частном облаке или в других PaaS (таких, как OpenStack или Cloud Foundry и так далее).

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

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

Предоставляя разработчикам полностью управляемую среду, мы даем им возможность быстро воспроизводить, диагностировать и устранять дефекты, причем их работа надежно изолирована от производственных серверов и других общих ресурсов. Разработчики могут экспериментировать с изменениями в средах, а также с кодом инфраструктуры, который их создает (например, сценариями Configuration Management), продолжая создавать новые знания, общие для разработки и IT-отдела [64].

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

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

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

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

• весь код приложения и все зависимости (например, библиотеки, статическое содержимое и так далее);

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

• все инструменты для создания среды и артефактов, описанных на предыдущем шаге (например, образы VMware или AMI, рецепты Puppet или Chef и так далее);