Система управления конфигурациями Linux Ansible

Управление конфигурацией

Материал из Xgu.ru

Перейти к: навигация, поиск

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

Современные системы управления конфигурацией по сути стремятся к тому, чтобы в полной мере реализовать принцип Infrastructure-as-a-Code, в соответствеии с которым вся существующая IT-инфраструктура, машины, их конфигурация, связи между ними и так далее могут быть описаны одним или несколькими формальными файлами, а дальше это уже дело системы управления конфигурацией — воплотить описанную конфигурацию в жизнь.

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

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

Наиболее популярными на сегодняшний день являются такие системы:

  • Первая волна
  • Вторая волна
  • Третья волна

Разделение на волны весьма условно, однако можно сказать, что системы одной волны были созданы с учётом проблем возникших у систем волны предыдущей.

[править] Что это такое

[править] Главные элементы и принципы

[править] Сравнение наиболее популярных систем

Характеристки:

  • Язык
  • Год
  • Язык рецептов
  • Способ коммуникации
  • Модель взаимодействия
  • Нужен ли агент

Сравниваемы системы:

  • CFEngine
  • Puppet
  • Chef
  • Ansible
  • SaltStack

[править] Общие рекомендации

[править] Дополнительная информация

  Системы управления конфигурацией
Основы Система управления конфигурацией
Реализации CFEngine  • Puppet  • bcfg2  • Chef  • Ansible  • SaltStack

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

Каталог услуг среднестатистического ИТ-подразделения  может состоять из нескольких десятков или даже сотен услуг, количество эксплуатируемого/поддерживаемого оборудования и ИТ-систем – измеряться тысячами штук. Оборудование или его компоненты выходят из строя и устаревают, появляются новые технологии, вводятся в эксплуатацию новые услуги, проводятся изменения уже существующих услуг. В связи с этим перед ИТ-руководством встаёт ряд задач, а именно:

  • обеспечение гибкости ИТ-инфраструктуры;
  • обеспечение актуальности информации об ИТ-оборудовании и ИТ-системах;
  • минимизация рисков при проведении изменений;
  • информационная поддержка процессов управления ИТ-услугами.

Решить данные задачи помогает процесс управления конфигурациями.

Назначение процесса управления конфигурациями – определение и контроль компонентов ИТ-услуг и инфраструктуры, а также поддержание точной, целостной и актуальной информации о конфигурациях.

Система управления конфигурациями Linux Ansible

 Процесс управления конфигурациями также контролирует все изменения компонентов.

Основным объектом процесса управления конфигурациями является конфигурационная единица (КЕ, CI, Configuration Item).

Конфигурационная единица – любой компонент, которым необходимо управлять для того, чтобы предоставлять ИТ-услугу. Информация о каждой конфигурационной единице регистрируется в форме конфигурационной записи и поддерживается в актуальном состоянии в течение всего жизненного цикла процессом управления конфигурациями.

Процесс управления конфигурациями решает следующие основные задачи:

  • обеспечение учёта и контроля информации о конфигурационных единицах на протяжении всего жизненного цикла;
  • идентификация функциональной зависимости между различными КЕ для:
    • сокращения времени и ресурсов, необходимых для анализа инцидентов и проблем;
    • упрощения и ускорения взаимодействия между различными подразделениями, эксплуатирующими ИТ-инфраструктуру;
    • анализа рисков при проведении изменений в инфраструктуре;
  • обеспечение связности и непротиворечивости ресурсно-сервисной модели при ее формировании и сопровождении;
  • обеспечение учёта информации и взаимосвязях КЕ между собой и их влиянии на предоставление услуг.

Инструментами, поддерживающими процесс управления конфигурациями, являются:

  • База данных управления конфигурациями (CMDB);
  • Ресурсно-сервисная модель.
 

БАЗА ДАННЫХ КОНФИГУРАЦИОННЫХ ЕДИНИЦ (CMDB)

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

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

Тип КЕ – категория, которая используется для классификации конфигурационных единиц. Тип КЕ определяет, какие атрибуты и взаимоотношения требуются для конфигурационной записи.

 

РЕСУРСНО-СЕРВИСНАЯ МОДЕЛЬ

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

Проработанная ресурсно-сервисная модель позволяет решать следующие практические задачи:

  • описание состава ИТ-услуги;
  • понимание степени влияния отдельных КЕ на предоставление ИТ-услуги, тем самым содействуя выявлению «узких» мест ИТ-услуг, разрешению инцидентов и проблем, анализу мощностей;
  • возможность проведения быстрой оценки влияния изменений;
  • расчет критичности КЕ в зависимости от связей с другими КЕ и ИТ-услугами;
  • расчет утилизации и распределение стоимости ИТ-активов на ИТ-услуги.

3. ЗАДАЧИ АДМИНИСТРИРОВАНИЯ И ОСНОВНЫЕ СЛУЖБЫ

3.1.Служба управления конфигурациями и изменениями

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

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

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

Процесс управления конфигурациями состоит из следующих подпроцессов:

3.1.1.

Система управления конфигурацией

Идентификация конфигураций.

3.1.2. Контроль за конфигурациями.

3.1.3. Вычисление статуса конфигурации.

3.1.4. Аудиты/обзоры конфигураций.

3.1.1. Идентификация конфигураций

Процесс идентификации конфигураций требует выполнения следующих шагов:

·         ОПРЕДЕЛЕНИЕ ОБЪЕКТОВ КОНФИГУРАЦИИ

На начальном этапе следует определить, что входит в инфраструктуру системы и насколько подробно предполагается отслеживать ее отдельные элементы. Излишне высокая степень детализации позволяет при необходимости учесть даже минимальные возможности и отклонения, однако требует существенных ресурсов на ведение базы данных. Здесь, как и в других областях, должно работать простое правило: издержки, связанные с внедрением и эксплуатацией системы, не должны превышать положительного эффекта от ее внедрения.

Каждый объект системы, который может изменять свое представление, содержание, структуру или статус, подпадает под управление конфигурациями и, таким образом, должен быть определен с самого начала. Все имеющиеся конфигурационные единицы должны быть помечены соответствующими им учетными номерами.

·         ВЫБОР СХЕМЫ НАИМЕНОВАНИЯ ОБЪЕКТОВ КОНФИГУРАЦИИ

Желательно, чтобы по учетному номеру можно было определить, к какому типу относится конфигурационная единица, какой она версии и т.д. Схема наименования, применяемая для учетных номеров, чаще всего включает следующие данные:

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

·         ОПРЕДЕЛЕНИЕ УТВЕРЖДАЕМЫХ и ВНУТРЕННИХ СХЕМ

Во время жизненного цикла системы могут создаваться и использоваться внутренние и утверждающиесхемы. Такие схемы обеспечивают моментальный снимок состояния системы в некоторый момент времени. Схема может быть представлена документом или набором документов. Моменты времени задаютсяадминистратором как точки инициализации контролирующих действий функции управления конфигурациями.

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

 Семейство ОС    Windows используют реестр — централизованную базу данных, в которой содержатся сведения о конфигурации и параметры всех версий MicrosoftWindows. Реестр содержит информацию обо всех аппаратных средствах, программном обеспечении, операционной системе и сетевых параметрах компьютера. Эта сложная иерархическая база данных принимает участие во всех аспектах работы Windows 2000.

Для системных администраторов особенно важны: понимание принципов работы реестра, выполняемых им задач, а также умение манипулировать реестром, вопросы администрирования и защиты реестра, а также его резервного копирования и восстановления.

3.1.2. Контроль за конфигурациями

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

Часто предлагаемые изменения инфраструктуры потенциально могут оказать существенно большее влияние на ее остальные элементы, нежели предполагалось изначально. Поэтому принятие решения об изменении должно осуществляться с учетом различной информации и при взаимодействии с другими процессами. Большая часть необходимой для принятия решения информации содержится в базе данных конфигурационных единиц. Для проведения стандартных изменений необходимо определить все потенциально связанные с изменением конфигурационные единицы, оценить влияние на них данного изменения, проверить, не ведет ли оно к снижению качества предоставляемых услуг, оценить экономическую эффективность изменения и в итоге принять его или отвергнуть.

Если изменение принимается, пересматриваются объекты конфигурации, их идентификационные номера, модифицируетсясхема, на которую изменение оказало влияние.

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

3.1.3.

Вычисление статуса конфигураций

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

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

3.1.4. Аудиты и обзоры конфигураций

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

Существенную помощь при организации такого рода проверок могут оказать специфичные средства автоматизированного управления различным оборудованием и приложениями.

Заключение

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

Положительный эффект от реализации процесса управления конфигурациями и изменениями выражается в следующем:

  • эффективное планирование расходов, определение стоимости содержания инфраструктуры и отдельных ее элементов;
  • повышение производительности труда пользователей за счет более качественного обслуживания и меньшего числа нарушений в нем;
  • повышение производительности труда — за счет уменьшения числа незапланированных работ, связанных с восстановлением систем от сбоев;
  • наличие доступной, полной и достоверной информации обо всем имеющемся оборудовании и ПО, а также связанной с ними документации;
  • возможность контроля за ценными конфигурационными единицами, отслеживание их технического состояния и качества функционирования;
  • строгое соблюдение правил лицензирования в отношении используемых программ, снижение риска появления в системах закладок, вирусов, выявление случаев использования запрещенного ПО;
  • повышение готовности к устранению аварийных и иных непредвиденных ситуаций;
  • меньшее число неудачных, подлежащих возврату в исходное состояние изменений;
  • возможность контроля и осуществления необходимых изменений.

Прочее / Технология разработки программного обеспечения / 5.7. Управление конфигурацией  программного обеспечения

Управление конфигурацией ПО — это один из вспомогательных процессов, поддерживающих основные процессы ЖЦ ПО, прежде всего процессы разработки и сопровождения ПО.

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

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

Введение для отшельников, которые не слышали что такое configuration management systems

Чем больше проект, тем больше времени разработчики тратят на согласования изменений в исходных текстах и получения работающих версий программного продукта. Данная задача может усугубиться наличием в компании регионально удаленных групп-разработчиков.

Управление конфигурацией позволяет организовать, системати­чески учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ.

При групповой разработке сложных ПО, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, необходимо:

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

контролировать запросы на доработку модуля, сообщения о найденной ошибке или неисправности оборудования, запросы на модификацию оборудования или ПО, задания на установку рабочего места, задания разработчику, аналитику и т.п., так как эти объекты влияют на состояние текущих версий других объектов и относятся к сфере управления изменениями;

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

вести полный и достоверный архив всех версий всех объектов системы;

контролировать состояние и развитие коллективно используемых ком­понентов ПО и их версий, учитывая связи компонентов системы для согласования между собой измененных частей; обеспечивать адекватность реально изменяю­щихся компонентов и их комплектной документации;

проводить оценку конфигурации — оценивать функциональную пол­ноту компонентов ПО, а также соответствие их физического состо­яния текущему техническому описанию.

изготавливать эталон­ные копии ПО и документации, хранить и поставлять их пользо­вателям в соответствии с порядком, принятым в организации.

Это упрощает выпуск и поставку ПО;

обеспечивать развитие всей системы, ограничивая усложнение проекта.

Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2.

Рассмотрим, как пример, управление исходным кодом.

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

Контролю подвергается не только собственно код модулей, но и код скриптов генерации схемы базы данных, а также собственно схема базы данных, которая может храниться в виде версий бинарных файлов, экспортированных во внутренний формат СУБД схем баз данных.

Прикладные программисты должны придерживаться установленных правил групповой разработки.

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

Формат комментария к правке может быть таким:

10.01.2004 Ivanov: authorization bug fixed (found by Petrov)

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

Часто ведущие исполнители проектов не доверяют системам контроля исходного кода сливать правки в исходных текстах автоматически и частично или полностью контролируют этот процесс. Эта перестраховка во многих случаях себя оправдывает.

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

Функции, структуры, наиболее важные переменные должны сопровождаться комментариями. Необходимо избегать непонятных названий вида K1, Function10.

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

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

Зачастую разработчику, вызывающему функцию модуля, требуется знать, что нужно передать и как обработать результат, а что происходит внутри — знать не обязательно. Единственное, что его интересует, — это правильная инициализация модуля, правильный прием результатов его работы и правильная выгрузка модуля.

Взаимодействие компонентов не должно быть произвольным. Контролировать эти правила создания исходного кода в большинстве случаев приходится вручную.

Группа разработчиковдолжна иметь свой выделенный сервер баз данных, и, возможно, не один, а также выделенные рабочие места. Часто эти моменты далеко не очевидны руководству, и оно воспринимает это как совершенно ненужную трату средств. Сервер, обеспечивающий контроль исходного кода, также должен быть выделенным.

Рынок систем конфигурационного управления

Без хорошего инструментария невозможно оперативно управлять конфигура­циями ПО.

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

Можно выделить четыре группытаких продуктов:

1) обеспечивающие контроль версий (Rational ClearCase, Merant PVCS, Microsoft Visual SourceSafe);

2) обеспечивающие контроль версий и изменений (Rational ClearCase/ClearQuest, PVCS Professional);

3) обеспечивающие параллельную разработку, контроль версий, изменений и рабочих процессов (PVCS Dimensions, CCC:Harvest фирмы Computer Associates);

4) обеспечивающие все вышеуказанные возможности при взаимодействии нес­кольких географически удаленных команд (Rational MultiSite, PVCS Replicator).

Продукт ClearCase наиболее мощный и, соответственно, дорогой. Он лучше всего подходит для проектов, в которых участвует не менее 10 разработчиков и которые направлены на создание крупных систем или на выпуск тиражируемого ПО, когда особенно актуальны проблемы отслеживания версий. ClearCase поддерживает множество репозитариев проекта с их автоматической синхронизацией; координирует совместную работу всех участников проекта; управляет конфигурацией сборки ПО; обеспечивает визуальный контроль над происходящим.

В числе недостатков ClearCase — необходимость серьезного администриро­вания, т.е. нагрузка при работе с продуктом перекладывается с конечных пользователей на администратора.

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

Продукт Microsoft Visual Source Safe осуществляет простой контроль исходных текстов и подходит для индивидуальной работы или для проектов, объединяющих нескольких человек. В нем нельзя организовать связь между участниками проекта, но он значительно дешевле и проще. Используется для ОС Windows 98, NT, 2000.

В ноябре 2002 г. компания Merantвыпустилановую версию популярного инструмента для управления конфигурациями ПО PVCS Professional7.5.

В состав пакета входят:

— PVCS Version Manager 7.5 — система контроля версий;

— PVCS Tracker Manager 7.5 — утилита формирования журнала изменений и задач;

— Configuration Builder 7.5 — утилита обеспечения стандартизованной и надежной компоновки готовых приложений.

Добавить комментарий

Закрыть меню