Snap what is it

Ubuntu snap – что это такое и с чем его едят?

Относительно недавно в Ubuntu появился новый инструмент — снапы (от англ. snap), но что это такое и как их использовать знают далеко не все пользователи.

Введение в снапы

Представим вполне реальную ситуацию. Пользователь устанавливает самую новую версию Ubuntu, пусть это будет версия 16.04 — именно в ней и появились впервые снапы по умолчанию. По определенным причинам пользователь отключает обновления. Такая ситуация не надумана. Мы все знаем, что после обновления системы Ubuntu, к сожалению, не всегда работает корректно и даже не всегда загружается.

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

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

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

Обе проблемы настолько обширны, что разработчики Ubuntu изобрели снапы. Все мы знакомы с понятием пакета. Пакет содержит саму программу, а также различные вспомогательные файлы — документацию, ресурсы (картинки, например), файлы локализации, сценарии Но пакет не содержит всего, что нужно для работы этой программы в системе. Например, если программе для работы нужна библиотека GL, то просто в пакете «прописывается» зависимость — нужно установить пакет для работы этого пакета. При установке программы менеджер пакетов (apt) производит разрешение зависимостей — устанавливает все необходимые для работы этой программы пакеты.

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

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

Плоские пакеты и оснастки и почему это не так плохо, как многие думают (Snap, Flatpak, AppImage)

Сегодня речь пойдёт о контейнерных технологиях, Flatpak, AppImage и Snap

Экскурс в историю

Первым появившимся из вышеперечисленных был Appimage, прообраз которой был создан командой Саймона Питера в 2004 году.

В iso-образ с файловой системой SquashFS «зашиты» все необходимые для работы библиотеки и сам бинарный файл. Это плохо сказывается на отзывчивости, однако запуск приложения происходит практически без дополнительных манипуляций. Из минусов такого подхода:

На основе концепции AppImage, Александром Ларссоном был создан Flatpak (изначально называлась xdg-app). Такая концепция предполагала меньшее использование дискового пространства за счёт использования «сред выполнения» — базовых библиотек, необходимых для запуска всем приложениям.

Вместо образов SquashFS Flatpak использует git-подобную файловую систему OSTree, что позволяет более гибко управлять версиями.

У Flathub есть свой центральный репозиторий, также есть возможность создавать дополнительные репозитории, как это, например, делают разработчики дистрибутива elementary.

Snap — технология, придуманная в недрах компании Canonical, разработчика популярного дистрибутива Ubuntu. Также, как и AppImage, snap-пакет является образом диска с файловой системой SquashFS. Однако, за появление в системе такого пакета отвечает демон snapd тесно связанный с системой инициализации systemD и модулем ядра AppArmor.

Статистика распространения пакетов

Скорость использования

Дистрибутив: Ubuntu 21.10

Пакет: Firefox 94

* Нативный пакет: 8 секунд
* AppImage: 10,5 секунд
* Flatpak: 7,5 секунд
* Snap: 21 секунда

* Нативный пакет: 2,9 секунд, 207 МБ RAM
* AppImage: 4,9 секунд, 249 МБ RAM
* Flatpak: 2,9 секунд, 233 МБ RAM
* Snap: 8,5 секунд, 261 МБ RAM

Дистрибутив: Manjaro

* Нативный пакет: 5 секунд
* Flatpak: 6 секунд
* Snap: 18 секунд

* Нативный пакет: 2 секунды
* Flatpak: 3 секунды
* Snap: 3 секунды

Тестовая машина 1

* Kubuntu 18.04
* Kernel 4.15.0-118-generic
* Snapd 2.46.1+18.04
* Пакет: Chromium Stable 85.X
* Сжатие snap-пакета: LZO

* Нативный пакет: 1,7 секунд
* Snap: 3,1 секунд

* Нативный пакет: 0,6 секунда
* Snap: 0,6 секунд

Тестовая машина 2

* Fedora 32 Workstation.
* Kernel 5.8.13-200.fc32
* Snapd version 2.45.3.1-1.fc32
* Пакет: Chromium Stable
* Сжатие snap-пакета: LZO

* Нативный пакет: 15,3 секунд
* Snap: 10,1 секунд

* Нативный пакет: 1,3 секунды
* Snap: 1,3 секунды

Исходя из тестирования выше можно отметить, следующие тенденции:

а) Flatpak по скорости запуска подбирается к нативным пакетам, Appimage проигрывает по скорости использованию ресурсов нативным пакетам и Flatpak (можно сказать, что не очень существенно учитывая, объём среды выполнения и самого пакета у Flatpak), скорость запуска snap сильно отстаёт от скорости запуска Flatpak и AppImage:

Как работают snap, flatpak, appimage

Disclaimer: в этой статье я не буду давать каких-то оценок, пытаться говорить что лучше. Только как это работает. Я предполагаю, что читатель знает что такое контейнеризация и как это примерно работает.

В чем, собственно, проблема?

А проблема в том, как приложение получает свои зависимости.

В мире windows победила идеология, где каждое приложение тащит свои зависимости с собой (за исключением совсем системных). Нередко можно видеть, что приложение кладет в свою папку какой-нибудь gl.dll, sqlite.dll и подобное.

Такой подход имеет свои плюсы и минусы. Из плюсов:

если какой-нибудь QT используется сотней приложений, то он будет установлен не 100 раз, а только 1.

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

Это хорошо сочетается с идеологией линукса «программа должна делать одну вещь и делать её хорошо».

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

А что делать, если двум приложениям требуются разные, несовместимые версии пакетов?

А что делать если приложению нужен пакет, который не предоставляется дистрибутивом?

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

Если дистрибутив обновляется (а вместе с ним все пакеты), нужно проверять работоспособность приложения. При этом хочется верить, что ментейнеры у проекта ещё есть. И да, вам будут присылать баг репорты на старые версии приложения в старых дистрибутивах, то есть нужно ещё поддерживать старые версии продукта, нельзя просто сказать «это починено в новой версии, обновитесь»

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

Appimage

AppImage file structure

Вообще желательно, чтобы AppDir содержал ещё некоторые служебные файлы (.desktop, иконки) для интеграции с хостовой системой, подробнее можно прочитать тут

В целом все довольно просто. Ну почти. Автору пакета нужно следить, чтобы приложение было «relocatable», то есть чтобы оно могло запускаться из любого места и в нем не было захардкоженных абсолютных путей к зависимостям. Это касается как динамических библиотек, так и ресурсов типа картинок. Вот с этим может быть проблема, так как поколения разработчиков на линукс опирались на конкретные захардкоженные пути и вычистить это все может быть не так просто.

Flatpak

При разговоре о flatpak нужно помнить, что он задумывался как контейнер именно для GUI приложений. Это повлияло на некоторые решения в дизайне.

В Flatpak вы точно также собираете свои зависимости с собой (кроме тех, что есть в базовом рантайме, о нем дальше), но запускается это все в изолированном контейнере (да, это больше похоже на то, что делает Docker).

Основные технологии, на которой основана flatpak

Из него видно, что помимо всяких id продукта, мы выбираем «runtime» и что мы хотим использовать из хостовой системы.

Runtime предоставляет базовые системные зависимости, там есть D-Bus, GLib, Gtk3, PulseAudio, X11, Wayland и прочее. Есть 3 стандартных рантайма на flathub: Freedesktop, GNOME и KDE. Также есть разные версии рантайма, для вашего контейнера подключится именно та, которую указали. Также это значит, что скорее всего у вас на диске будет лежать несколько версий (а они не маленькие).

Далее в файле указываются шаги для сборки приложения и всех его зависимостей. Приложение собирается не на хосте, а внутри SDK (это то же самое что и runtime, но с дополнительными сборочными утилитами внутри). Также помимо runtime существуют «BaseApp», базовые приложение которые не нужно собирать и можно просто утянуть себе в контейнер. Обычно это большие фреймворки которые не хочется настраивать самому, наподобие Electron. Но это используется редко, сами авторы просят не создавать их без реальной необходимости.

Кстати говоря, при желании можно войти в контейнер и что-нибудь там поделать. Делается это командой

Подробнее про все это можно посмотреть в этом выступлении автора flatpak.

Чтобы понять разницу, запустим hello-world.evil двумя способами

И глянем в вывод dmesg

Это говорит нам о том, что при запуске snap понимает какое приложение хотели
запустить через него, и запускает его, но только через профайл apparmor (его можно посмотреть в /var/lib/snapd/apparmor/profiles/snap.hello-world.evil ). То есть если в flatpak sandboxing нашего приложение делалось через namespaces (контейнеризацию), то тут оно реализовано через правила apparmor. Посмотреть какие права есть у приложение можно через его манифест. В hello-world никаких дополнительных прав нет

Для сравнения можно посмотреть snap.yaml от firefox. В терминологии snap приложение, которому нужны дополнительные возможности, должны поставить плагины (plugs)

Layouts

В snap есть механизм layout, в котором можно отобразить файлы и папки из доступных snap’у путей в глобальную иерархию. Это настраивается в том же snapcraft.yaml, например

Почему холодный старт долгий?

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

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

Также при старте нужно раскрутить apparmor и проставить все указанные layout, то есть сделать правильные mount namespace. Если layout очень развесистый, это действительно может тормозить запуск, о чем они сами пишут в документации.

По поводу snap нужно также понимать, что изначально эта технология была сделана для IoT, а потом её натянули на десктопы. Насколько была удачна идея, покажет история. Вот тут пользователем popeydc составлен довольно неплохой список почему люди не очень любят snap.

Заключительные мысли

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

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

What’s in a snap?

Igor Ljubuncic

on 26 March 2021

Unpacking the squashFS filesystem

If you want to check the contents of a snap, you can. First, download it, then extract the snap using the unsquashfs tool on the command line. A large number of Linux distributions should have this utility installed, or available in the archives, and should support the compression methods used for snaps (xz and lzo).

The contents of a snap

To allow applications to run independently of the underlying system, snaps create an isolated environment for the contained applications. For strictly confined snaps, the application will see the base snap as its root filesystem, and thus expect to see the traditional layout of folders inside its environment. Typically, the squashfs-root will contain different folders like /bin, /lib, /usr, and others.

Some of the paths will be obvious and familiar. Some, including various files, will be different.

Application entry point

When developers package snaps, they need to declare the application name and command in the snapcraft.yaml file. For the most part, there is no strict requirement how these should be specified, and the developers can use any variation they like. The application command does not have to be identical to what it could look like using the traditional Linux packaging.

Furthermore, snapcraft also helps the developers create some of the necessary application runtime environment elements, including different variables and relative paths. You can inspect what this setup looks like by checking any script available inside the snap.

This folder contains various setup and declarative files that describe the snap’s behavior. It can include several components: snap.yaml file that contains the basic snap details, a list of plugs and slots, any daemons, and more; hooks that are triggered on specific events; GUI elements like icon files and desktop files for the snap.

The snap directory (if present) can contain the command-chain declaration, a list of commands that are run before the actual application(s) bundled inside the snap. This can help set up the environment that snaps need, without having to resort to convoluted use of wrapper scripts.

And more…

Your snap (or a snap) could have only a handful of folders, or a whole range of them, including custom paths and structure. The contents will differ from one application to another, but at the end of the day, there is no great mystery about what snaps are. Anyone can download, unpack and inspect any snap, and see exactly what they do. In many cases, you will have an exact trail of environment variables and commands that run. If you want to learn a bit more about what else to expect inside a snap, you may want to check the snap format documentation for other useful details.

Finally, if you want to experiment, you can try the handy snap try command – to make quick, live changes to snaps, and test modified behavior. This can be quite useful if you want to speed up your development. That’s all we had today. If you have any comments or suggestions, please join our forum for a discussion.

Ubuntu desktop

Learn how the Ubuntu desktop operating system powers millions of PCs and laptops around the world.

Установка и использование Snap-пакетов в Ubuntu 18.04

Введение

Snap (или Snappy) — это система развертывания программ и управления пакетами, созданная Canonical. Эти пакеты чаще называют «снепами». Для работы с ними используется утилита «snapd», встроенная в ряд дистрибутивов Linux и позволяющая дистрибутивно-независимо развертывать программы на более высоком уровне.

Snapd — это REST API демон, служащий для управления snap-пакетами. Пользователи взаимодействуют с ним с помощью клиента snap, который входит в тот же пакет. Вы можете установить любое приложение на Linux-десктоп, сервер, облако или устройство.

Вам понадобится

GNU/Linux дистрибутив u и некоторые базовые знания о работе в командной строке. В данном руководстве вы узнаете, как настроить и использовать snap-команды.

Установка системы Snap

Если у вас установлена Ubuntu 16.04 LTS (Xenial Xerus) или более поздние версии, включая Ubuntu 18.04 LTS (Bionic Beaver), то вам ничего не надо делать. Snap установлен по умолчанию и готов к работе. Соответственно, если у вас установлена более ранняя версия или системы Snap нет по каким-то другим причинам, то сначала установите ее, а затем приступайте к работе.

Установку можно осуществить с помощью следующих команд:

Работа с системой Snap

snapd настроен и готов к использованию!

Поиск snap-приложений/пакетов

Чтобы найти доступные snap-приложения или пакеты выполните следующую команду:

Установка snap-приложений

Вы можете установить любые приложения/пакеты, доступные в формате snap, выполнив следующую команду:

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

Запуск установленных snap-пакетов

Также его можно запустить через команду:

Просмотр списка установленных приложений

Чтобы увидеть все установленные snap-пакеты, выполните следующую команду:

Обновление установленных snap-приложений/пакетов

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

Чтобы посмотреть, какие обновления snap-пакетов готовы к установке, выполните следующую команду:

Возврат к более ранней версии snap-приложений/пакетов

Если по какой-то причине вам не понравилось последнее обновление snap-пакета, вы можете вернуться к предыдущей версии с помощью следующей команды:

Такая команда вернет необходимую версию snap-пакета и данные, соответствующие ПО. Если предыдущая версия snap-пакета получена из другого канала, она все равно установится, и канал останется прежним.

Удаление snap-приложений/пакетов

Если вы хотите избавиться от снепов, удалите snap-пакет с помощью следующей команды:

Эта команда удалит приложение, все ее зависимости во время выполнения и связанные пользовательские данные. Если снеп запущен, команда сначала закроет его и затем удалит.

Включение и выключение snap-приложений/пакетов

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

Список запущенных служб

Перезапуск, запуск и приостановление snap-служб

Все службы, необходимые для работы снепов, будут перезагружены по умолчанию:

Чтобы запустить ранее остановленную службу, используйте следующую команду:

Чтобы остановить запущенную службу, используйте следующую команду:

Конфигурации snap set и get

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

Выставленные параметры конфигурации можно посмотреть с помощью установленного снепа. Введите команду snap get

Чтобы изменить параметры конфигурации, задайте команду «snap set»:

Скачивание и установка snap-приложений offline

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

Заключение

Хотя данная система все еще разрабатывается, и доступно не так много snap-приложений/пакетов, тем не менее, она является одной из лучших систем управления ПО. Snap становится все популярнее, особенно благодаря таким настойчивым методам Canonical.