Распространение ПО в Linux: контейнеры или пакеты?

 ДЕНИС СИЛАКОВ, к.ф.-м.н., старший системный архитектор Virtuozzo, dsilakov@virtuozzo.com

Распространение ПО в Linux:
контейнеры или пакеты?

Процедура распространения и установки приложений для Linux посредством пакетов с прекомпилированными программами традиционно отличала эту систему от альтернатив. Внесет ли контейнерная виртуализация серьезные изменения вэтот механизм?

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

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

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

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

Установив себе несколько подобных программ, можно обнаружить в разных директориях системы копии одних и тех же библиотек и других компонентов, которые при этом входят и в состав самого дистрибутива. Попытки решить эту проблему за счет стандартизации (в частности, в рамках Linux Standard Base) особым успехом не увенчались – на практике привести сотни дистрибутивов к некоторому общему знаменателю оказалось практически не реально.

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

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

Установка в обход пакетных менеджеров

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

Наиболее прямолинейный способ развернуть приложение без участия менеджера пакетов – это сделать для него отдельную программу установки. Можно обойтись написанием собственных скриптов установки (это вполне приемлемо, если установка сводится к копированию файлов в нужные места системы), а можно воспользоваться и чем-то готовым – например, более десяти лет назад небезызвестный инструментарий InstallShield предлагал версию под Linux [1]. Назвать этот подход популярным на сегодняшний день нельзя – даже коммерческие разработчики предпочитают готовить пакеты в формате RPM и Deb.

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

Одной из наиболее старых и в то же время активных и популярных реализаций этого сценария является AppImage, появившаяся в 2004 году под именем klik. Формат распространения приложений в AppImage подразумевает упаковку всех нужных файлов в ISO-образ и добавление к этому образу небольшой среды исполнения, которая при запуске программы в формате AppImage смонтирует образ ISO и запустит непосредственно приложение. Такой путь не требует каких-либо изменений в файлах ОС и позволяет использовать AppImage обычным пользователям без привилегий root.

У AppImage немало альтернатив, например ZeroInstall и Listaller, однако особой популярности они не снискали, хотя у каждой из них есть определенные изюминки. Возможно, одной из причин популярности AppImage стало то, что в 2015году на нее обратил внимание Линус Торвальдс, заметивший, что этот инструментарий действительно «просто работает».

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

Для домашнего использования отсутствие централизованного управления вряд ли критично, но вот для системного администратора, обслуживающего парк машин, подобная активность пользователей по самостоятельному управлению ПОможет обернуться кошмаром. Если же администратор сам захочет устанавливать на подшефные машины программы в формате AppImage или схожих, то ему придется самостоятельно заботиться об их доставке и обновлении с помощью дополнительных средств – например, систем управления конфигурацией наподобие Puppet или Ansible.

Наконец, инструменты типа AppImage сконцентрированы на процессе доставки приложения пользователю и практически никак не затрагивают вопросы безопасности. Время от времени появляются предложения наподобие запуска приложений Listaller в отдельных песочницах, но до готовых к использованию реализаций дело доходит редко. И именно дополнительная изоляция приложений друг от друга и от ОС – это то радикальное улучшение, которое может предложить контейнерная виртуализация.

Статью целиком читайте в журнале «Системный администратор», №7-8 за 2017 г. на страницах 19-23.

PDF-версию данного номера можно приобрести в нашем магазине.

1. Programming Tools: InstallShield X // Linux Journal, Nov 2004 – http://www.linuxjournal.com/article/7875.
2. Силаков Д. LXD – управляем контейнерами Linux. // «Системный администратор», № 7-8, 2015 г. – С. 18-22 (http://samag.ru/archive/article/2983).
3. Силаков Д. Проект Docker. Управляем виртуальными окружениями. // «Системный администратор», № 3, 2015 г. – С. 10-14 (http://samag.ru/archive/article/2887).
4. Хрюкин А. Изоляция процессов с помощью LXC на примере со Skype. // «Системный администратор», № 5, 2014 г. – С. 19-21 (http://samag.ru/archive/article/2684).
5. How Many Public Images are there on Docker Hub? – https://goo.gl/2ndJRH.
6. Силаков Д. Open Containers Initiative. Стандартизация в мире контейнеров. // «Системный администратор», № 7-8, 2016 г. – С. 6-8 (http://samag.ru/archive/article/3229).
7. Силаков Д. Обновление ядра Linux без перезагрузки. // «Системный администратор», № 10, 2016 г. – С. 7-11 (http://samag.ru/archive/article/3285).
8. Flatpak Applications – http://flatpak.org/apps.html.
9. uApp Explorer: Snappy Applications – https://uappexplorer.com/apps?type=snappy.
10. Каталог образов AppImage – https://bintray.com/probono/AppImages.
11. Using Open Build Service to generate AppImages – https://git.io/obs-ai.

Комментарии могут оставлять только зарегистрированные пользователи