Джин Ким - Руководство по 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, язвительно заметил, что мы подходили к исправлению серверов как к лечению домашних питомцев: «Вы даете им имя, и если они заболевают, то ухаживаете за ними, пока они не выздоровеют. Сейчас с серверами обращаются как с крупным рогатым скотом. Вы нумеруете их, а если они заболевают, вы их пристреливаете».

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