Руководство по 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]. Система контроля версий записывает изменения в файлах или наборах файлов, хранящихся внутри системы. Это может быть исходный код, другие активы или любые документы как часть проекта создания программного обеспечения. Мы вносим изменения в группы, называемые коммитами, или редакциями. Каждый коммит вместе с метаданными (кто внес изменения и когда) сохраняется в системе тем или иным способом, что позволяет нам сохранять, сравнивать, выполнять слияния и восстанавливать предыдущие версии объектов в репозитории. Это решение также минимизирует риски, поскольку предоставляет способ откатить объекты, измененные в производственной среде, к предыдущим версиям (в дальнейшем следующие термины будут использоваться как равнозначные: загрузить в систему контроля версий, зафиксировать в системе контроля версий, зафиксировать код, зафиксировать изменения, фиксация, коммит).