Сравнение методов развертывания программного обеспечения

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

Управление жизненным циклом для настольных систем в мире Microsoft будет еще долго оставаться очень важной темой. Однако вопрос о подходящих инструментах управления встал только после того, как администрация г. Мюнхен с количеством рабочих мест много больше 10 тыс. решил перевести свои клиенты на Linux. Эти инструменты должны были помочь отделу ИТ решать типичные административные задачи: в частности, выяснить, какое программное обеспечение, какой версии и на каком компьютере установлено, какие аппаратные компоненты инсталлированы и на каком количестве систем, какое ядро используется на персональных компьютерах. Определить, применяются ли надлежащие драйверы, а в случае Linux - модули ядра. Понять, имеются ли в системе уже известные «дыры», для которых доступна соответствующая заплата или обновление, и если они существуют, то какому количеству управляемых устройств необходимо уделить внимание при развертывании.

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

LINUX LINUX?У РОЗНЬ

В корпоративном сегменте Германии получили распространение три дистрибутива: Red Hat, SuSE (с января 2004 г. принадлежит Novell) и все чаще встречающийся Debian GNU/Linux. При сравнении с Windows выясняется, что Linux в определенных аспектах управления программным обеспечением обладает заметными преимуществами. Так, уже несколько лет все производители предлагают сравнительно устоявшийся формат пакета. Microsoft, напротив, лишь в недавнем прошлом осознала значение такого формата и представила в качестве стандарта MSI (Windows Installer). Он уже неплохо себя зарекомендовал, и многие разработчики выпускают свои приложения и в этом формате. Кроме того, на рынке имеются вспомогательные программы, в частности InstallShield AdminStudio и Wise Package Studio, для составления пакета любого программного обеспечения, которое недоступно в виде MSI.

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

В случае Linux системному администратору, к сожалению, приходится иметь дело с различными, зависящими от производителя форматами (см. Рисунок 1): SuSE и Red Hat издавна работают с Red Hat Package Management (RPM), в то время как Debian доверяет собственному Debian Package (DPKG). Однако они настолько схожи, что при помощи специальных инструментов один формат можно трансформировать в другой - важно лишь, чтобы составление пакета осуществлялось в соответствии с определенным стандартом. Кроме того, каждый дистрибутив предлагает инструменты для инсталляции отдельных пакетов или их небольших групп посредством командной строки либо графического интерфейса. Эти инструменты работают в фоновом режиме с собственными базами данных, посредствам которых осуществляется управление состоянием, именем и версией конкретного пакета.

Рисунок 1. При управлении клиентами с ориентацией на Linux необходимо учитывать разные дистрибутивы.

УПРАВЛЕНИЕ ПАКЕТАМИ

Для максимально простого, насколько это только возможно применительно к управлению программным обеспечением, использования пакета должен быть выполнен ряд условий. Программное обеспечение должно быть необслуживаемым, т. е. обходиться без вмешательства администратора. В среде Windows пользователь привык к тому, что после помещения в дисковод компакт- или DVD-диска либо после запуска файла setup.exe загруженного из Internet продукта запускается графическая процедура инсталляции. Причем всякий раз запрашивается как полезная, так и не имеющая никакого смысла информация. Однако процесс может быть автоматизирован (в случае MSI это стандартизировано).

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

В этом и заключается одно из главных отличий Linux от Windows: форматы Linux учитывают зависимости между пакетами. Упаковщик в соответствующем заголовке пакета определяет, какие еще пакеты и в какой версии должны присутствовать. Различные форматы, как правило, предоставляют возможность определения относительных условий, к примеру «в версии более поздней или совпадающей с x.y». На основе локальной базы данных управления пакетами принимается решение: задана уже зависимость или нет. В последнем случае операция выполняется лишь тогда, когда пользователь явным образом исключил проверку зависимостей при помощи опции.

После успешной инсталляции приложения или услуги администратору предстоит еще выполнить индивидуальную конфигурацию. При наличии сотен и тем более тысяч управляемых систем эта задача крайне сложна. Мир открытых источников предлагает в помощь такие инструменты, как cfengine, которые требуют, впрочем, трудоемкого предварительного учета всех возможных вариантов. А вот гетерогенной средой ИТ, состоящей из систем Windows и Linux, управлять подобным образом не удастся (см. Рисунок 2).

ПОЛЕЗНЫЕ ДОПОЛНЕНИЯ

Большинство дистрибутивов Linux содержат дополнения для собственных инструментов управления пакетами. Они позволяют автоматически разрешать зависимости при помощи различных источников. АРТ от Debian предлагает, к примеру, наряду с локальными ресурсами (CD-ROM или каталогом NFS) выбрать в качестве источника инсталляции сервер Internet. Если пользователь хочет установить пакет, то автоматически определяется, выполнены ли уже заданные в пакете зависимости. В противном случае подается запрос источнику и загружаются недостающие пакеты. Так можно обновить все инсталлированные пакеты - вплоть до новой версии. Однако при использовании в корпоративной области у этого подхода есть недостатки: точно настроенное безукоризненное управление и, прежде всего, контроль очень сложно реализовать на базе имеющихся встроенных средств, и тогда изменение подхода к администрируемой системе в духе ITIL становится игрой ва-банк. Выполнение одного пакета в соответствии с вышеописанными методами может автоматически повлечь за собой большое число других пакетов. Они, в свою очередь, способны повлиять на другие приложения и процессы, что станет причиной нежелательной дестабилизации целевой системы.

Для поддержания распределенных систем Linux в актуальном состоянии или предоставления пользователям новых приложений производители SuSE и Red Hat разработали собственные инструменты. При этом Novell - благодаря приобретению Ximian - в Red Carpet предлагает дополнение, которое до сих пор отсутствовало в SuSE.

В случае Red Hat решение называется Red Hat Network (RHN). В принципе, технологии сравнимы: на центральном сервере пакеты хранятся в так называемых «каналах», при этом на управляемом устройстве соответствующий клиент может быть сконфигурирован таким образом, что программное обеспечение автоматически устанавливается и обновляется путем абонемента канала (см. Рисунок 3). Конфигурацией обновления и инсталляции конечных систем администратор управляет из центра. Крупные среды по причинам масштабируемости, как правило, требуют наличия дополнительного сервера - так называемого сателлита.

Рисунок 3. Каналы, как в данном случае у Red Hat Network, облегчают обновление клиентов Linux.

ПЕРВАЯ ИНСТАЛЛЯЦИЯ ОПЕРАЦИОННЫХ СИСТЕМ

Первоначальное использование Linux мало чем отличается от установки Windows. Различные решения поддерживают создание образов. С его помощью на основании эталонной системы можно сформировать, нейтрализовать и при позднейшем развертывании индивидуализировать копию. Однако при поддержке множества имеющихся в Linux файловых систем (Ext2/3, XFS, ReiserFS и т. д.) возникают некоторые частичные ограничения.

Большинство дистрибутивов предлагает метод для необслуживаемого проведения «родной» процедуры инсталляции операционной платформы при условии предварительного предоставления всей необходимой информации. У SuSE эта технология называется Autoyast2, у Red Hat - Kickstart, у Debian - FAI. С их помощью заранее определяются все существенные конфигурационные настройки. По сравнению с решением по созданию образа «необслуживаемая установка» системы Linux обычно занимает больше времени. Зато она обеспечивает большую гибкость как раз в отношении распознавания и поддержки аппаратного обеспечения, которое отсутствовало в эталонной системе или имелось в ней в ином исполнении.

УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ

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

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

СВОБОДНО РАСПРОСТРАНЯЕМЫЕ И КОММЕРЧЕСКИЕ РЕШЕНИЯ

Решения, предлагаемые составителями дистрибутивов, можно лишь условно называть свободно распространяемыми. В некоторых случаях клиентские компоненты или, по крайней мере, их части доступны в виде открытых кодов, так что соответствующую функциональность можно использовать в других решениях. Однако предоставление централизованного серверного компонента, как правило, обуславливается приобретением лицензии. Исключение представляет собой Debian GNU/Linux с модулями АРТ и FAI.

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