Портал №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

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

Комментариев: 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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
    • 5 основных тенденций развития искусственного интеллекта и машинного обучения на 2022 год
      Вот несколько основных тенденций, к которым вашему бизнесу стоит начать готовиться. Искусственный интеллект и машинное обучение становятся доминирующей частью технологической
    • 6 тенденций в ИТ, за которыми нужно следить
      Чтобы выжить во время пандемии, организации обратились к ИТ, чтобы помочь справиться с последствиями - как негативными, так и позитивными. В некоторых отраслях, таких как телемедицина и видеоконференции, бизнес резко вырос, и ИТ-отделам таких компаний пришлось в спешке справляться с нагрузкой. В других, например, в сфере путешествий и развлечений, бизнес резко просел. Кроме того, возобновилось стремление к цифровой трансформации.
    • Восход Desktop-as-a-Service: что это такое и зачем вам это нужно?
      Широкое распространение облачных вычислений добавило в наш словарь множество сокращений, наиболее распространенными из которых являются SaaS, PaaS и IaaS. Действительно, наступила эра облачных решений, которые доставляют программное обеспечение, платформу и инфраструктуру потребителям и предприятиям по запросу и с оплатой по мере использования.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT