Каждая прикладная область знаний со временем (а то и быстро) обрастает своим понятийным аппаратом. Находясь в нашем традиционном мире ITIL/ITSM мы привыкли под определёнными словами понимать определённые вещи, и, читая профессиональную литературу, нам в большинстве случаев сразу же понятно что имеется ввиду, скажем, под управлением инцидентами или управлением конфигурациями.
Однако слова, которые мы используем для описания своей области, не принадлежат нам на эксклюзивных началах. Они (слова) используются и в других смыслах, даже если речь и идёт всё ещё про информационные технологии. Тем интереснее посмотреть что привычные нам понятия означают в смежных дисциплинах.
Сегодня мы рассмотрим управление конфигурациями на примере DevOps.
В одной очень хорошей и очень подробной книжке ("Continuous Delivery – Reliable Software Releases Through Build, Test And Deployment Automation", Jez Humble and David Farley) дано следующее определение управления конфигурациями:
Это процесс, с помощью которого все артефакты, относящиеся к вашему проекту, а также взаимосвязи между ними, сохраняются, извлекаются, уникально идентифицируются и изменяются.
В целом точно как в ITIL, только совсем по-другому. Чтобы осознать всю глубину различий, придётся погрузиться в детали.
Начнём с того, что система версионного контроля – не какое-то отдельное, дополнительное свойство CMDB, а насущная необходимость. DevOps-эксперты категорично утверждают, что без такой системы ни о каком DevOps говорить не следует. Система версионного контроля предназначена для сохранения и отслеживания изменений всего, что требует сохранения и отслеживания, в первую очередь исходного кода приложений, модулей и компонентов.
Однако настоящие джедаи этим не ограничиваются, распространяя действие контроля версий также на все тесты, скрипты создания и модификации баз данных, скрипты сборки и развёртывания, всю документацию. Это пока можно понять и осознать, однако мы движемся дальше.
В систему версионного контроля принято добавлять всё необходимое для (вос)создания любой из ваших сред: разработки, тестирования, продуктива. Включая компиляторы и дополнительные инструменты, используемые разработчиками, полный набор из операционных систем и всех необходимых компонет, стеков, файлов настройки зон DNS, конфигураций брендмауэров и прочая, и прочая.
Этого, конечно, недостаточно. Хорошей практикой считается хранение в СВК (системе версионного контроля, давайте уже введём сокращение) также образов серверных приложений, виртуальных машин и всего остального двоично-скомпилированного, за исключением двоичного кода вашего собственного приложения, разумеется.
Наша самая высокая цель – иметь в СВК всё, что необходимо для автоматического восстановления конфигурации. И здесь мы переходим к ещё одному важному отличию, слову "автоматического".
Понятно, что всё это многообразие вручную никуда не сложить и никак не отследить. Тут-то и помогает главное свойство СВК – контроль версий, берущий на себя заботу о выявлении и документировании отличий того, что стало, от того, что было. Да так, что разработчику и инженеру достаточно только набрать условную команду "git push".
Следующий важный момент – хранение в СВК не только исходного кода и требуемого окружения, но и всех настроек – тех самых "конфигураций". Независимо от механизма хранения и извлечения информации о настройках (файлы ini и cfg, либо реестр, либо база данных, либо REST API) – все настройки должны быть в СВК, и также должны подлежать контролю изменений. Утверждается, что по большому счёту любое полезное приложение состоит из трёх частей: двоичного кода, данных и настроек. Код и настройки просто обязаны входить в охват управления конфигурациями. Худшее, что в DevOps может быть, это настройка сервера вручную администратором путём проставления галочек в окошках, равно как и установка требуемых компонент через запуск файла setup.exe в интерактивном режиме. За такое предлагается увольнять немедленно, с занесением соответствующей записи о проф.пригодности в трудовую книжку. "Правильный" DevOps позволяет за весьма короткое время (минуты) создать любую часть любой среды, вместо того, чтобы искать и устранять причины неработоспособности этой части этой среды (часы и дни).
Просуммируем обозначенные ключевые отличия:
- В ITIL оно называется CMDB, в DevOps – система контроля версий, СВК.
- В СВК попадает всё. Вообще всё. Включая все настройки.
- В СВК оно попадает и далее контролируется автоматически.
Те, кто имеет опыт построения управления конфигурациями согласно ITIL, знают, насколько это непростая затея, и сколько ручного труда предполагает наполнение и актуализация CMDB – вплоть до предания забвению результатов многомиллионного проекта с закупленным многомиллионным программным обеспечением.
С другой стороны, DevOps без управления конфигурациями невозможен, и требуемая задача успешно решается даже на условно-бесплатных инструментах.
DevOps обошёл ITIL, так что ли?
На иллюстрации: упрощённая схема одной из систем (на схему можно нажать).
Вы немножко все смешали в кучу. СКВ для "виртуальных машин и ПО" конечно есть, но это специализированные СКВ, созданные как раз для того, чтобы не хранить в своих СКВ (где у вас именно артифакты ваших проектов) эти самые образы вирутальных машин и программных проектов. И максимум что вы храните у себя в файлах настройки сборки – это версии ваших пакетов или виртуалок/докер образов, котореы будут подтянуты при необходимости.
И уж в терминах ITIL это будет куча разых CMDB видимо – в одном образы (dockerhub), в другом js-пакеты (npm), ну а в ваших ваши локальные проекты.