Управление жизненным циклом Linux ПО: преодолеваем сложности без потерь

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

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

Проблемы же могут начаться тогда, когда требуемого пакета ПО нет в репозитории. Ведь каким бы полным он не был, всё существующее ПО не может быть включено. Кроме того, вендоры Linux ОС далеко не всегда успевают оперативно обновить репозиторий ПО — и нередка ситуация, когда бизнесу, к примеру, нужно приложение "A" версии 5.0, а в репозитории доступна лишь версия 4.0. Казалось бы, можно пойти на сайт вендора ПО, скачать и установить нужную версию, но именно здесь может поджидать неприятный сюрприз, когда новая версия ПО не адаптирована под целевой дистрибутив ОС и как результат не работает. Или же на сайте вендора нет собранного пакета, а взамен предложены исходники, из которых нужно собрать пакет ПО под свои нужды.

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

Во многих случаях распространённые Linux-дистрибутивы используют пакеты ПО в одном из двух популярных форматов, существенно различающихся друг от друга — deb- или rpm-пакета. Для сборки своего deb- или rpm-пакета или пересборки существующего необходимо следовать процессу, который обобщённо выглядит так:

1. - берём исходники от приложения,
2. - настраиваем целевой образ ОС, под который будет собираться пакет,
3.  - изучаем документацию от вендора ПО (в случае существующего пакета ПО),
4.  - собираем список зависимостей для успешной сборки,
5.  - собираем пакет ПО.

Такая сборка удобна тем, что на выходе мы получаем готовые пакеты, ПО которых следуют концепции deb или rpm и управляются на целевой ОС так же, как и любые другие пакеты ПО в репозиториях.

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

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

При использовании Linux в качестве ОС для рабочих мест у бизнеса возникает ряд задач, важнейшая из которых — доступ. Как правило, репозитории опубликованы в интернете, и для их использования каждый компьютер с Linux ОС должен иметь доступ в интернет.

Отсюда получаем проблемы:

• Интернет-канал. Если нужно установить какое-либо ПО на АРМ, то все они примерно в одно время будут забирать контент пакета ПО из репозитория, и тем самым будут нагружать интернет-канал компании.
• Отказоустойчивость. При обновлении вендором каких-либо компонентов в репозитории они сразу становятся доступными для установки. В случае, если обновленные компоненты не совместимы с вашим образом, есть высокий риск получить нерабочие приложения после массового обновления рабочих станций.
• Добавление в репозитории новых / модифицированных пакетов. Нет возможности добавлять свои пакеты ПО, а в условиях корпоративной ИТ-инфраструктуры, где задействовано множество АРМ, нужна централизация.

Эти проблемы могут быть решены путём размещения репозитория-зеркала и собственного репозитория в ИТ-инфраструктуре компании. В первом случаем мы решим вопрос с интернет-каналом и контролируемым обновлением ОС. Во втором случае — получим возможность добавлять свои собственные пакеты ПО и управлять ими централизованно.

Несмотря на то, что в мире Linux можно найти дистрибутивы или аналоги практически под любое Windows-приложение, бизнес может столкнуться с ситуацией, где требуется использовать определенное Windows ПО, для которого нет версии под Linux. Для этого существует технология WINE: ее основная задача — исполнение Windows ПО в Linux ОС.

WINE перехватывает Windows API-вызовы и транслирует их в Linux-вызовы. Так приложение Windows считает, что оно запущено в среде Windows, и действительно работает. К сожалению, технология имеет ряд ограничений, и далеко не все приложения можно запустить таким образом. Сложно дать однозначный ответ по конкретному Windows ПО — будет оно работать в WINE или нет, а потому каждое ПО нужно анализировать и тестировать отдельно.

Если говорить о процессе подготовки Windows-приложения для запуска через WINE, то это тоже своего рода подготовка пакета ПО: ведь есть ряд правил, рекомендаций, обходных решений и т. п., а также набор инструментов, которые позволяют создать WINE-пакет для Windows ПО. Как правило, каждое Windows ПО требует использования тех или иных подходов при создании WINE-пакета, и подбор нужного подхода является исследовательской задачей, требующей значительных трудозатрат.

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

• Инвентаризация — собирается информация об используемом ПО Windows в инфраструктуре заказчика, количестве экземпляров ПО и о частоте его использования.
• Рационализация — полученный список анализируется на наличие ПО с дублируемым функционалом, отмечается неиспользуемое/малоиспользуемое ПО, формируется сводный отчет. Предварительный список ПО, которое должно попасть в парк Linux ПО, согласуется с заказчиком.
• Категоризация — список анализируется на возможность миграции на ОС Linux. Результатом этого шага является отчет, в котором список ПО разделен на категории: «есть Linux дистрибутив», «есть аналог», или же «кандидат на WINE».
• Модификация — если нужно настроить Linux ПО под инфраструктуру заказчика, например, добавить регистрационные данные, указать сервер и т. д., можно внести требуемые изменения в установочные Linux-пакеты. Этот подход является де-факто золотым стандартом для управления большими инфраструктурами АРМ: он позволяет добиться существенной экономии на управлении АРМ благодаря снижению числа возникающих проблем после установки ПО и отсутствию необходимости конфигурировать ПО под разные группы пользователей вручную.
• WINE — сборка WINE-пакетов для ПО Windows, для которого нет установочных пакетов под Linux и аналоги.
• Тестирование — всего подготовленного парка Linux ПО на целевом образе ОС заказчика в тестовой среде, с целью окончательной проверки совместимости в условиях, максимально близких к продуктивной эксплуатации.

Процесс управления жизненным циклом Linux ПО в корпоративных средах имеет ряд сложностей. Основная причина в том, что до недавнего времени Linux ОС массово не применялись на предприятиях в качестве ОС для АРМ и нет чётких рекомендаций и процессов о том, как грамотно управлять ПО в Linux. Если компания принимает решение о переходе на Linux, то, помимо решения широкого спектра технических вопросов, ей придется вложиться в наращивание компетенций у сотрудников ИТ-департамента, что в свою очередь тоже не быстро. Либо же можно прибегнуть к помощи интеграторов, которые быстро помогут мигрировать на Linux и настроить процессы управления ПО.

Читайте также на TAdviser.