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

• все файлы, использующиеся для создания контейнеров (например, определения или композиционные файлы состава Docker или Rocket);

• все вспомогательные автоматические тесты и все сценарии тестирования вручную;

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

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

• все файлы конфигурации облаков (например, шаблоны формирования AWS Cloud, файлы Microsoft Azure Stack DSC, OpenStack HEAT);

• все другие сценарии или информация о конфигурации, требующаяся для создания инфраструктуры, которая поддерживает несколько служб (например, шина служб предприятия, системы управления базами данных, файлы конфигурации зоны DNS, правила для межсетевых экранов и других сетевых устройств) [66].

Можно иметь несколько репозиториев для различных типов объектов, в которых они маркированы и помечены наравне с исходным кодом. Например, мы можем хранить большие образы виртуальных машин и ISO-файлы, собранные двоичные файлы и тому подобное в репозиториях артефактов (таких, как Nexus, Artifactory и так далее). Или можем положить их в хранилища blob (например, блоки Amazon S3) или положить образы Docker в хранилища Docker и так далее.

Но недостаточно просто иметь возможность заново воссоздать любое из предыдущих состояний производственной среды; мы должны также иметь возможность воссоздать целиком предпроизводственную среду и процессы сборки. Поэтому нам необходимо включить в систему контроля версий все, что используется в ходе сборки, в том числе инструменты (например, компиляторы и инструменты для тестирования) и среды, от которых они зависят [67].

Согласно докладу 2014 State of DevOps Report компании Puppet Labs использование отделом эксплуатации системы контроля версий — наилучший показатель для предсказывания производительности как IT-подразделений, так и всей организации в целом. По сути, этот показатель даже лучше, чем использование системы контроля версий разработчиками.

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

Но почему использование системы контроля версий для сред разработки позволяет точнее предсказать производительность IT-подразделений и организации в целом, чем использование этой системы непосредственно для контроля кода?

Потому что почти во всех случаях количество конфигураций сред превосходит по порядку величины количество конфигураций нашего кода [68].

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

Будучи способны по первому требованию быстро заново собрать или пересоздать приложения и среды, мы можем делать это вместо исправлений, когда что-то пошло не так. Хотя именно этим приемом пользуются практически все крупные (имеющие более тысячи серверов) веб-операторы, такую практику надо применять, даже если в производственной среде у нас работает только один сервер.

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

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

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

Вместо входа на серверы вручную и внесения изменений в конфигурацию мы должны внести изменения таким образом, чтобы все они автоматически реплицировались всюду и автоматически же фиксировались в системе контроля версий. Мы можем полагаться на нашу систему управления конфигурацией для обеспечения согласованности сред (например, Puppet, Chef, Ansible, Salt, Bosh и др.). Можно создавать новые виртуальные машины или контейнеры с помощью механизма автоматизированной сборки и развертывать их в производство, уничтожая старые машины или выводя их из ротации [69].

Последняя модель — так называемая постоянная инфраструктура: в ней внести изменения в производственную среду вручную невозможно, единственный способ — внести изменения в систему контроля версий и создать код и среду «с нуля». При таком подходе вариабельность никак не сможет «вползти» в производственную среду.

Во избежание неконтролируемых вариаций конфигурации мы можем отключить удаленный вход на производственные серверы [70]или регулярно уничтожать экземпляры и заменять их новыми, чтобы обеспечить удаление вместе с ними всех изменений, внесенных вручную. Такой подход мотивирует всех членов команд вносить изменения как положено, через систему контроля версий. Применяя такие меры, мы систематически уменьшаем возможность того, что инфраструктура отклонится от рабочего состояния (например, из-за смены конфигураций, повреждаемости отдельных компонентов, чьих-то сознательных усилий и так далее).

Также мы должны поддерживать в актуальном состоянии предпроизводственные среды — в частности, необходимо сделать так, чтобы разработчики максимально обновленный вариант среды. Разработчики часто стремятся работать в старых средах, поскольку не любят изменений: так можно нарушить работу имеющихся функций. Однако мы хотим обновлять среды часто, чтобы можно было обнаруживать проблемы на как можно более ранней стадии жизненного цикла проекта [71].