Портал №1 по управлению цифровыми
и информационными технологиями

Управление конфигурациями в DevOps

configuration_managementКаждая прикладная область знаний со временем (а то и быстро) обрастает своим понятийным аппаратом. Находясь в нашем традиционном мире 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 позволяет за весьма короткое время (минуты) создать любую часть любой среды, вместо того, чтобы искать и устранять причины неработоспособности этой части этой среды (часы и дни).

Просуммируем обозначенные ключевые отличия:

  1. В ITIL оно называется CMDB, в DevOps – система контроля версий, СВК.
  2. В СВК попадает всё. Вообще всё. Включая все настройки.
  3. В СВК оно попадает и далее контролируется автоматически.

Те, кто имеет опыт построения управления конфигурациями согласно ITIL, знают, насколько это непростая затея, и сколько ручного труда предполагает наполнение и актуализация CMDB – вплоть до предания забвению результатов многомиллионного проекта с закупленным многомиллионным программным обеспечением.

С другой стороны, DevOps без управления конфигурациями невозможен, и требуемая задача успешно решается даже на условно-бесплатных инструментах.

DevOps обошёл ITIL, так что ли?


На иллюстрации: упрощённая схема одной из систем (на схему можно нажать).

simplified_nas

«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

Комментариев: 6

  • Вячеслав Алпатов

    Вы немножко все смешали в кучу. СКВ для "виртуальных машин и ПО" конечно есть, но это специализированные СКВ, созданные как раз для того, чтобы не хранить в своих СКВ (где у вас именно артифакты ваших проектов)  эти самые образы вирутальных машин и программных проектов. И максимум что вы храните у себя в файлах настройки сборки – это версии ваших пакетов или виртуалок/докер образов, котореы будут подтянуты при необходимости.

    И уж в терминах ITIL это будет куча разых CMDB видимо – в одном образы (dockerhub), в другом js-пакеты (npm), ну а в ваших ваши локальные проекты.

    • В определённый момент развития и применения ITIL консультанты и практики поняли, что одна CMDB на все случаи жизни – это очень хорошо и довольно утопично. Разнородные данные можно, конечно, пытаться свести в единую базу данных, только а) непонятно зачем устраивать избыточность и дублирование, б) можно устать сводить и актуализировать. В то время как пользователю CMDB, по большому счёту, не очень интересно где и как конкретно лежат требуемые для работы данные, а намного важнее их наличие и актуальность. Так родилась концепция федеративной CMDB.

      Схожая ситуация и с DevOps. Нигде не утверждается, что СВК – это такая одна большая "программа".

       

      • Вячеслав Алпатов

        @ игде не утверждается, что СВК — это такая одна большая "программа".@ По тексту это выглядит именно так.

        Т.е. например разделы download на cisco.com и microsoft.com вы предлагаете рассматривать как "специализированные CMDB" аналогичные тому же dockerhub? Вы понимаете что нужную мне версию ПО с dockerhub я заберу одной командой, а сайт cisco придется парсить и ручками вытягивать то, что мне нужно (если я вообще это найду зная привычки вендоров "подчищать" неудачные релизы)?

        СКВ в DevOps заточены на тотальную автоматизацию. Приведите пример аналогичной реализации в "классическом" CMDB, пожалуйста.

        По факту весь DevOps вырос из СКВ для программистов (слышали о cvs?). Зачем теперь ITIL сюда приплетать?

        • Уважаемый Вячеслав! Благодарю, что продолжаете обсуждение. Однако в нашей с Вами дискуссии я не вижу предмета разногласий. Управлять конфигурациями надо? Да. СВК нужна? Да. Будет ли она единой системой? Вряд ли. Нужно ли всё максимально автоматизировать? Да.

          • Вячеслав Алпатов

            Я не очень понимаю зачем надо обязательно "натягивать" ITIL на DevOps или "забивать" DevOps в ITIL? Да еще с обязательным подчеркиванием "ITIL универсальнее и первичнее"?

            • В своей заметке я описал управление конфигурациями в DevOps. Для того, чтобы читателям было понятнее, в нескольких местах я проводил аналогии с управлением конфигурациями в ITIL – всё же мы находимся на портале Real ITSM.

              Натягивание, забивание и подчёркивание в заметке отсутствуют и даже не подразумеваются.


Добавить комментарий для Вячеслав АлпатовОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM