Привязки в ядре Ubuntu
Ядро Ubuntu построено на основе snaps, безопасного, ограниченного, свободного от зависимостей кроссплатформенного формата упаковки Linux.
Привязки являются автономными, что означает, что они, возможно, включают в себя все необходимое для запуска или использования компонентов из других привязок ограниченным и контролируемым образом. Они используются Ubuntu Core как для создания образа, запускаемого на устройстве, так и для доставки последовательных и надежных обновлений программного обеспечения, часто для маломощных, недоступных и удаленно администрируемых встроенных систем и систем интернета вещей.
Будь то обновление для отдельного устройства, определенного подмножества устройств или развертывание десятков тысяч устройств, привязки позволяют ядру Ubuntu поддерживать и проверять целостность системы:
-
Автономные обновления для любого устройства: служба обновлений должна быть надежным и автоматическим процессом, обеспечивающим предсказуемую частоту обновлений и необязательный высокий уровень контроля над тем, когда и как доставляются обновления
-
Неполное и проблемное восстановление обновлений: из-за недоступности многих установок встроенных устройств крайне важно, чтобы обновления были надежными и могли выдерживать сбои, блокировки, частичные и прерываемые обновления
-
Предоставление критических обновлений: в определенных обстоятельствах, когда необходимо выполнить разовое или критическое обновление, система обновлений должна отдать им приоритет и включить обновление обратно в службу регулярных обновлений
-
Непредсказуемые условия работы оборудования и сети: в ситуациях, которые нелегко смоделировать или спрогнозировать, любая система обновления должна иметь достаточную избыточность для обработки отката, начальной загрузки без подключения к сети и автономной повторной подготовки
Типы привязок
Экосистема упаковки snap состоит из следующих частей:
- snap - это одновременно интерфейс командной строки и формат пакета приложений
- snapd - это фоновая служба, которая управляет вашими привязками и поддерживает их
- snapcraft - это команда и фреймворк, используемые для создания ваших собственных привязок
- Snap Store предоставляет место для загрузки ваших снимков, а также для просмотра и установки пользователями
Разработчики могут публиковать снимки в Snap Store или в своем собственном фирменном магазине. Они несут единоличную ответственность за частоту обновления и качество. Хотя привязки обычно известны как формат упаковки приложений, ядро Ubuntu построено из нескольких различных типов привязок:
- ядро: содержит ядро Linux для устройства
Привязка ядра выбирается с помощью утверждения модели, описывающего устройство, которое создается и подписывается перед созданием образа. После создания образа привязка ядра может быть обновлена, но не может быть заменена полностью другой привязкой ядра. - гаджет: определяет свойства устройства
Привязка гаджета отвечает за определение системных свойств и конфигурации и манипулирование ими, специфичных для одного или нескольких устройств, которые обычно будут похожи друг на друга с точки зрения реализации. Он также отвечает за отправку загрузчика устройства и ресурсов загрузчика. Он выбирается с помощью утверждения модели. - база: среда выполнения
Базовая привязка предоставляет среде выполнения минимальный набор библиотек, которые являются общими для большинства приложений. Базовые привязки отражают выпуски Ubuntu LTS и включают core20, созданный на основе Ubuntu 20.04 LTS, core18 на основе Ubuntu 18.04 LTS и core на основе Ubuntu 16.04 LTS. Одна из них, выбранная с помощью утверждения модели, также служит корневой файловой системой для основной системы Ubuntu.
По историческим причинам привязка ядра имеет другой конкретный тип: core. - snapd: демон привязки
Базовые привязки core16, core18 и core20 не включают демона привязки (core, однако, включает). Вместо этого они упаковывают демон как обновляемую привязку этого типа. - приложение: приложения, демоны и инструменты
Упаковывают приложения, извлеченные из нескольких вышестоящих источников с использованием различных систем сборки. Демон snapd сам устанавливается как snap (за исключением старого ядра, куда он включен).
Как и в случае с основной файловой системой, привязки предоставляются системе только для чтения и им предоставляется доступ к любым необходимым ресурсам через набор явных разрешений, известных как интерфейсы. Интерфейсы реализованы с использованием хорошо протестированных функций ограничения ядра Linux.
Документация Snap
Snaps - это пакеты приложений Linux для рабочего стола, облака и Интернета вещей, которые являются автономными, простыми в установке, безопасными, кроссплатформенными и не содержат зависимостей.
Они обновляются автоматически и обычно выполняются в ограниченной среде, основанной на транзакциях. Безопасность и надежность являются их ключевыми характеристиками, наряду с простотой установки, простотой обслуживания и простотой обновления.
Snaps помогают пользователям настольных компьютеров без особых усилий устанавливать и запускать приложения, такие как Spotify или Slack. Они помогают системным администраторам запускать такие серверы, как NextCloud, разработчикам упаковывать и распространять свою работу в глобальном Snap Store, а также помогают всем создавать и развертывать устройства Интернета вещей под управлением Ubuntu Core.
Snap справится с этим - от разработчиков Linux и maker space до робототехники, автомобилестроения и индустрии вывесок; от вашего рабочего стола до тысяч развертываний.
Руководства по объяснению Snap
Наши пояснительные и концептуальные руководства написаны для лучшего понимания того, как работают snap и snap daemon (snapd). Они позволяют вам расширить свои знания и стать лучше как в создании снимков, так и в получении максимальной отдачи от экосистемы snap.
Мгновенное удержание
Ограничение доступа Snap определяет объем доступа приложения к системным ресурсам, таким как файлы, сеть, периферийные устройства и службы. Существует несколько уровней ограничения.
Ограничение доступа гарантирует, что отдельные части программного обеспечения не влияют на надежность системы пользователя и не вызывают проблем с другими приложениями. В результате, когда пользователь запускает snap, предоставляемое им программное обеспечение в некоторой степени изолировано от системы, причем по умолчанию доступ ограничен строгим минимумом функций.
Уровни удержания
Уровень ограничения доступа к snap определяет степень его изоляции от системы пользователя. Разработчики приложений или разработчики пакетов могут настроить уровень ограничения, чтобы в общих чертах указать, какой объем доступа к системным ресурсам требуется приложению либо для обычного использования, либо во время разработки.
Для опубликованных снимков существует два уровня ограничения привязки:
- Строгий режим, используемый большинством снимков. Снимки со строго ограниченным доступом выполняются в полной изоляции, вплоть до минимального уровня доступа, который считается всегда безопасным. Следовательно, строго ограниченные snaps не могут получить доступ к файлам, сети, процессам или любому другому системному ресурсу без запроса специального доступа через интерфейс (см. Ниже).
- Classic Обеспечивает доступ к ресурсам системы во многом так же, как это делают традиционные пакеты. Для защиты от злоупотреблений публикация классической snap требует утверждения вручную, а для установки требуется
--classicаргумент командной строки.
Дополнительный режим полезен в процессе разработки:
- Devmode Специальный режим для создателей snap и разработчиков. В режиме разработки snap выполняется как строго ограниченный snap с полным доступом к системным ресурсам и выдает отладочный вывод для идентификации неуказанных интерфейсов. Для установки требуется
--devmodeаргумент командной строки. Снимки в режиме разработки не могут быть опубликованы на стабильном канале, не отображаются в результатах поиска и не обновляются автоматически.
Строгое ограничение доступа использует функции безопасности ядра Linux, включая AppArmor, seccomp и пространства имен, для предотвращения доступа приложений и служб к более широкой системе.
Получение уровня ограничения доступа
Используйте команду snap, чтобы определить уровень ограничения доступа для привязки:
$ snap info --verbose vlc
[...]
confinement: strict
devmode: false
[...]
Чтобы узнать, в каких установленных привязках используется классическое ограничение, найдите classic в столбце Примечания в выходных данных snap list:
$ snap list
Name Version Rev Tracking Publisher Notes
vlc 3.0.6 770 stable videolan✓ -
code 0dd516dd 5 stable vscode✓ classic
wormhole 0.11.2 112 stable snapcrafters -Интерфейсы и ограничение доступа
Привязки со строгим ограничением доступа должны использовать интерфейсы для доступа к ресурсам в системе пользователя, включая те, которые предоставляются другими привязками.
Обновить информацию
Привязки обновляются автоматически, и по умолчанию демон snapd проверяет наличие обновлений 4 раза в день. Каждая проверка обновления называется обновлением и более подробно описана в разделе Управление обновлениями.
Если обновление происходит во время работы затронутого настольного приложения, обновление информации о приложении помогает устранить любые потенциальные проблемы, используя комбинацию обновлений на месте, отличающихся обновлений и уведомлений на рабочем столе.
Для обновления информации требуется snapd 2.57+
На управление службами это не влияет, поскольку службы запускаются и останавливаются вручную как часть процесса обновления, если только разработчиком snap в snap не было встроено определенное значение endure. Дополнительные сведения см. в разделе Службы и демоны.
Обновления на месте
Если приложение запущено, когда автоматическое обновление обнаруживает обновление, новая версия snap загружается в фоновом режиме, чтобы сократить время обновления. По завершении загрузки пользователь получает уведомление о ожидающем обновлении, и при остановке приложения запускается мгновенное обновление. После обновления snap дополнительное уведомление информирует пользователя о том, что новая версия snap готова к использованию (требуется snapd 2.59.2+). Обновления на месте работают только с автоматическими обновлениями, а не при запуске обновления вручную.
Отложенные обновления
Обновление может быть отложено на срок до 14 дней для запущенного приложения. Обновление будет применено либо при закрытии приложения, при следующем автоматическом обновлении без запуска приложения, либо через 14 дней, даже если приложение остается активным.
После закрытия затронутого приложения обновление может быть запущено вручную с помощью команды snap refresh, либо глобально для всех снимков, либо с использованием определенного имени снимка:
snap refresh <snap-name>
Если при ручном обновлении будет обнаружено, что приложение все еще запущено, вывод ошибки будет включать обнаруженные идентификаторы процессов запущенных приложений:
error: cannot refresh "firefox": snap "firefox" has running apps (firefox), pids:
1639,1854,1912,1932,3514,3632,5814,5870
См. раздел Управление обновлениями для получения более подробной информации об управлении частотой обновлений и сохранении обновлений в течение любого периода времени.
Уведомления на рабочем столе
Пока запущено уязвимое приложение, при каждой попытке обновления на рабочем столе будет появляться уведомление, информирующее пользователя о том, что приложение следует закрыть во избежание сбоев.
На рабочем столе Ubuntu GNOME по умолчанию уведомления можно изменять и отключать, выбрав "Уведомления" в приложении "Настройки" и выбрав приложение "
Каналы
- Треки позволяют разработчикам snap публиковать несколько поддерживаемых выпусков своего приложения под одним и тем же именем snap.
- Уровни риска представляют собой прогрессивный потенциальный компромисс между стабильностью и новыми функциями.
- Ветки являются необязательными и содержат временные выпуски, предназначенные для исправления ошибок.
Полное название канала может состоять из трех отдельных частей, разделенных косой чертой:
<track>/<risk>/<branch>
Значение отслеживания для установленной привязки, показанное в выходных данных snap list команды, показывает, какой канал установлен и отслеживается для этой привязки.
Треки
Все снимки имеют дорожку по умолчанию. Если разработчик snap не укажет иное, дорожка по умолчанию называется последней. Аналогично, если дорожка не указана, snap будет неявно устанавливаться с последней дорожки. Дорожка также может быть указана явно:
snap install vlc --channel=latest/edge
Разработчики могут по желанию выбрать, следует ли дополнять последнюю дорожку по умолчанию дополнительными дорожками. Разработчик также волен назначить одну из них в качестве дорожки по умолчанию для установки, если нет дополнительных предпочтений.
Программа Microsoft Skype snap является хорошим примером того, как можно использовать треки. Он содержит два трека: последний трек по умолчанию для большинства пользователей и внутренний трек для команды Microsoft по контролю качества и пользователей, заинтересованных в тестировании последних разработок Skype перед выпуском стабильного выпуска.
Аналогичным образом, трек также может использоваться для отслеживания незначительных обновлений (2.0.1, 2.0.2), основных обновлений (2.1, 2.2) или выпусков, предназначенных для долгосрочной поддержки (3.2, 4.1).
Треки перечислены в разделе "Каналы" выходных данных snap info команды:
$ snap info skype
[...]
channels:
stable: 8.28.0.41 (51) 148MB classic
candidate: ↑
beta: ↑
edge: ↑
insider/stable: 8.30.76.41 (53) 151MB classic
insider/candidate: ↑
insider/beta: ↑
insider/edge: ↑
[...]
В приведенных выше выходных данных snap для Skype включает пользовательский трек для insider. Вы также можете посмотреть, какие треки поддерживает snap, выбрав Другие версии в разделе "Онлайн-магазин".
Чтобы установить Skype из его внутренней дорожки, например, используйте следующую команду:
snap install skype --channel=insider/stable
Пользователь, у которого уже установлен Skype, может переключать каналы с помощью команды snap refresh:
snap refresh skype --channel=insider/stable
В качестве альтернативы, если используется программное обеспечение GNOME, выберите ‘стабильный’ канал на странице магазина Skype и выберите канал для переключения.
В настоящее время разработчики должны отправить запрос на добавление треков в их snap через категорию форума #store-requests. Релизы проверяются, чтобы гарантировать соответствие разумным ожиданиям пользователей. Например, для трека 3.2 принимаются только версии 3.2.*.
Уровни риска
Существует четыре уровня риска: стабильный, кандидатный, бета-версия и edge. Они представляют собой снижающиеся уровни стабильности для snap, хотя в конечном итоге это решение остается за издателем snap. Установка с менее стабильным уровнем риска обычно означает, что обновления для snap будут выполняться чаще, чем для более стабильного уровня риска.
Уровни риска имеют следующее значение:
-
стабильный: для подавляющего большинства пользователей, работающих в производственных средах.
Выпуски с таким уровнем риска максимально стабильны в соответствии со стандартами проекта. Важное программное обеспечение достигнет этой стадии только после того, как оно будет готово к использованию в производстве и его можно будет использовать в продуктах. Подразумевается обещание избегать любых изменений, которые могли бы нарушить эти обычаи.
-
кандидат: для пользователей, которым необходимо протестировать обновления перед стабильным развертыванием, или для тех, кто проверяет, решена ли конкретная проблема.
Версии-кандидаты считаются почти готовыми к запуску в стабильную версию, но для их дальнейшего продвижения требуются некоторые дополнительные эксперименты в реальном мире. Программное обеспечение, достигающее этой стадии, как правило, прошло все доступные процессы контроля качества и проверки, поскольку пользователи, следующие ему, ожидают высокого уровня стабильности. Оно практически никогда не должно ломаться.
-
бета: для пользователей, желающих протестировать новейшие функции, как правило, вне производственной среды.
Бета-версия - это первый уровень стабилизации того, что было до быстрого потока изменений. В конкретных проектах может немного отличаться терминология для таких выпусков (альфа, бета и т.д.), Но все это приветствуется на данном уровне риска. Эти выпуски почти наверняка прошли какую-либо проверку качества, но могут по-прежнему содержать незавершенные части. Критические изменения здесь все еще относительно распространены.
-
edge: для пользователей, желающих внимательно следить за разработкой.
Выпуски Edge часто включают непрерывный поток изменений без обещаний контроля качества или проверки и обычно создаются автоматически процессом CI из моментального снимка произвольного исходного кода. Часто CI публикует только после прохождения какого-либо автоматического контроля качества, и обзоры кода остаются хорошей практикой, но они зависят от конкретного проекта. Предположим, что выпуски edge могут часто прерываться.
По умолчанию привязки устанавливаются из стабильного уровня риска. Например, следующая команда устанавливает VLC из стабильного канала:
sudo snap install vlc
Используйте опцию --channel, чтобы выбрать другой уровень риска. Следующая команда установит последнюю бета-версию VLC snap:
sudo snap install --channel=beta vlc
Если бета-версия snap недоступна, будет установлена snap с ближайшего канала канал с более стабильным уровнем риска.
Для краткости --stable, --candidate --beta и --edge можно использовать вместо --channel=<risk-level>
После установки отслеживаемый уровень риска может быть изменен с помощью switch командной опции:
sudo snap switch --channel=stable vlc
Этот параметр не будет автоматически обновлять snap для принудительной установки новой snap. Чтобы переключать каналы и обновлять привязку одной командой, добавьте --channel опцию в команду обновить:
sudo snap refresh --channel=stable vlc
Чтобы проверить, какой канал отслеживает привязка, найдите поле отслеживание в выходных данных snap info команды:
$ snap info vlc
[...]
snap-id: RT9mcUhVsRYrDLG8qnvGiy26NKvv6Qkd
tracking: edge
refresh-date: yesterday at 19:54 BST
[...]
Уровни риска могут не соответствовать внутренним соглашениям проекта. Например, в некоторых проектах может использоваться alpha вместо edge. Однако номенклатура выпусков проекта должна быть достаточно близка к уровням риска snap, чтобы вы могли судить об относительной стабильности устанавливаемой вами версии.
Ветки
Ветвь - это необязательное, детализированное подразделение канала для опубликованной привязки, позволяющее создавать кратковременные последовательности привязок, которые могут быть запущены по запросу разработчиками snap для помощи в исправлениях или временных экспериментах.
Названия ветвей передают их назначение, например, fix-for-bug123, но имя не отображается обычным способом, например, с помощью snap info команды. Вместо этого они могут быть установлены только тем, кто знает название ветки, и обычно им делится только разработчик snap для тестирования определенного исправления или выпуска.
По истечении 30 дней без дальнейших обновлений ветка будет автоматически закрыта. Затем будет выбрана сменная привязка, как это было бы с закрытыми каналами (см. Ниже). Например, бета-версия / исправление для bug123 вернется к бета-версии после закрытия ветки с исправлением для bug123.
Смотрите Публикация в ветке для получения более подробной информации о том, как разработчики snap могут использовать ветки для публикации временных выпусков snap.
Закрытие каналов
Канал может быть закрыт издателем snap, если больше нет snap, который соответствовал бы первоначальному назначению или спецификации канала.
Например, когда канал определенного уровня риска закрыт, хранилище snap store выберет снимок с более стабильным уровнем риска на том же треке. Если исходный канал будет открыт повторно, снимки снова будут выбираться из исходного канала.
Этот подход обычно используется для бета-тестирования. Если snap подписывается на канал бета-версии, который затем закрывается, магазин предложит snap с канала-кандидата. Если возможный канал недоступен, будет выбран снимок из стабильного канала. Если бета-версия канала откроется повторно, привязка снова будет выбрана из этого канала.
Интерфейсы
По умолчанию привязки со строгим ограничением доступа могут получать доступ только к ограниченному набору ресурсов за пределами среды, в которой они выполняются. Привязки могут получать доступ только к ресурсам из системы и другим привязкам через интерфейсы, которые описывают предоставляемые ими ресурсы.
Создатель оснастки выбирает интерфейсы, необходимые для правильной работы оснастки. К общим интерфейсам относятся те, которые обеспечивают доступ к сети, функциям рабочего стола и звуковой системе.
Подключаемые интерфейсы
Соединение между привязками осуществляется, когда разъем оснастки, нуждающейся в ресурсе, подключается к разъему в другой оснастке, предоставляющей этот ресурс. Аналогией этому является подключение устройства к электрической розетке, которая обеспечивает его необходимым питанием.
Подключения выполняются либо автоматически во время установки, либо вручную, в зависимости от их функции. Интерфейс рабочего стола подключается автоматически, например, в отличие от интерфейса камеры. В столбце Автоматическое подключение в таблице Поддерживаемые интерфейсы указывается, подключается ли интерфейс автоматически или нет. Смотрите Механизм автоматического подключения интерфейса для получения подробной информации о реализации.
Как и в случае с классическим ограничением, издатель snap может запросить утверждение для автоматического подключения интерфейса, который в противном случае не подключался бы автоматически. Например, guvcview snap запросил автоматическое подключение интерфейса камеры при установке snap.
-
Если snap обновлен и включает новое утверждение, пользователю все равно потребуется подключить интерфейс вручную. Аналогично, если установленная классическая snap обновлена для использования строгого ограничения, ее интерфейсы не будут настроены автоматически.
-
Если snap установлен до того, как интерфейсу было предоставлено разрешение на автоматическое подключение, и впоследствии это разрешение предоставлено и snap обновлен, то при обновлении установленной snap интерфейс будет подключен автоматически.
Получение интерфейсов для оснастки
Используйте команду snap connections, чтобы увидеть, какие интерфейсы необходимы snap и какие подключены в данный момент:
$ snap connections vlc
Interface Plug Slot Notes
camera vlc:camera - -
desktop vlc:desktop :desktop -
desktop-legacy vlc:desktop-legacy :desktop-legacy -
home vlc:home :home -
mount-observe vlc:mount-observe - -
[...]
В приведенном выше примере мы можем видеть, что vlc:camera интерфейс отключен, потому что в нем есть пустой слот.
Дополнительные сведения об интерфейсе см. в разделе Управление интерфейсами, включая инструкции по отключению интерфейсов и выполнению подключений вручную, а также в разделе политика безопасности и "песочница" для получения дополнительной информации о том, как реализовано ограничение доступа.
Изменения
Редакция Snap - это номер, автоматически присваиваемый магазином Snap при каждой загрузке snap, придающий каждому двоичному файлу snap уникальный идентификатор внутри и по всем его каналам.
Номер редакции увеличивается с каждой новой загрузкой. Но это число произвольное и используется только для разграничения загрузок.
Ни номер редакции (ни ее версия) не обеспечивают соблюдения порядка выпуска. Локальная система попытается установить любую версию snap, рекомендованную издателем, в отслеживаемом канале.
Просмотр номеров версий
Выходные данные для snap info <snapname> включают номер редакции для каждой привязки в каждой дорожке и канале в виде числа в скобках после даты публикации:
channels:
latest/stable: 2.59.4 2023-05-31 (19361) 55MB -
latest/candidate: 2.59.5 2023-06-09 (19457) 55MB -
latest/beta: 2.59.5 2023-05-27 (19457) 55MB -
latest/edge: 2.59.5+git955.gc9310cc 2023-06-13 (19535) 42MB -
installed: 2.59.1+git798.g5f761c7 (19131) 42MB snapd
В приведенном выше примере вывода последняя версия / edge snap имеет версию 19535 и является самой последней опубликованной версией snap. Если snap установлена, последняя строка snap info выходных данных включает установленную версию (19131, выше).
Команда snap list включает столбец для номера версии каждой установленной snap, помеченный как Rev:
Name Version Rev Tracking Publisher Notes
alacritty 0.8.0 46 latest/stable snapcrafters✪ classic
blender 3.5.0 3486 latest/stable blenderfoundation✓ classic
chromium 112.0 2424 latest/stable canonical✓ -
ffmpeg 4.3.1 1286 latest/stable snapcrafters✪ -
Управление пакетами версий
Хранилище Snap Store кэширует несколько старых версий каждой snap, как и локальная система. По умолчанию локально хранятся 2 версии, в то время как в системном хранилище Ubuntu Core хранится 3. Эти настройки по умолчанию можно изменить с помощью опции обновить-сохранить system.
Команды snap install, refresh и download могут работать с этими доступными версиями с необязательным --revision аргументом.
snap <command> <snap-name> --revision <revision-number>
Чтобы установить версию под номером 27 hello-world snap, например, выполните следующую команду:
$ snap install hello-world --revision 27
hello-world 6.3 from Canonical✓ installed
Привязку hello-world можно обновить до версии под номером 28 с помощью следующей команды:
$ snap refresh hello-world --revision 28
hello-world 6.3 from Canonical✓ refreshed
Номер версии привязки, с которой выполняется операция, появится в выходных данных во время этих операций.
Управление выпусками описывает, как разработчик snap может публиковать или продвигать определенные версии своей snap.
Управление данными
Идентификатор редакции используется в качестве ссылки для данных, относящихся к конкретной редакции. Как описано в разделе Расположения данных, данные, относящиеся к конкретной версии для snap, хранятся либо в общесистемном расположении, либо в домашнем расположении конкретного пользователя:
-
SNAP_DATA:
/var/snap/<snap name>/<revision number>
Это хранилище также используется для хранения данных, в основном информации, используемой фоновыми приложениями и службами, для ведения журнала и других задач, требующих сохранения данных между запусками snap. -
SNAP_USER_DATA :
/home/<username>/snap/<snap name>/<revision>
В этом расположении содержатся любые пользовательские данные, которые snap записывает в свой собственный домашний файл. Это в отличие от того, что пользователь Linux считает своим домом, хотя само местоположение будет находиться в домашнем каталоге пользователя.Важно отметить это различие, поскольку оно может быть полезным и даже важным, когда пользователи решают выполнить операции обслуживания своих снимков (например, удаление). По умолчанию в каждой snap будет использоваться символическая ссылка current , указывающая на последнюю доступную версию.
При переходе от одной редакции к следующей содержимое SNAP_DATA и SNAP_USER_DATA, зависящее от конкретной редакции, копируется в новые каталоги для новой редакции. Это включает в себя переход от более высокого номера редакции к более низкому номеру редакции (поскольку номера редакций произвольны).
Каталоги, относящиеся к конкретной редакции, сохраняются в соответствии с системной опцией обновить-сохранить.
Помимо содержимого общих каталогов, в моментальном снимке хранятся только данные, связанные с текущей установленной версией. Подробнее см. в разделе Что хранит моментальный снимок.
Обновления транзакций
Транзакционное обновление - это операция установки или обновления набора привязок, которая либо завершается успешно для всех привязок, либо, если хотя бы одна привязка обнаруживает ошибку, завершается сбоем для всего набора. В случае сбоя процесса все затронутые снимки возвращаются к состоянию, в котором они находились до запуска процесса, даже снимки, которые были успешно обновлены.
Это может помочь, когда тестируется набор снимков с определенными ревизиями, чтобы убедиться в их совместной работе, и когда поведение может стать непредсказуемым, если набор не будет установлен или обновлен одновременно.
Транзакционные обновления также могут помочь, когда вы знаете, что одна привязка зависит от конкретной версии другой, или когда вам нужно обновить несколько привязок одновременно. Например, в прошивке для устройства под управлением Ubuntu Core это может помочь обновить как snap ядра, так и snap гаджета одновременно. Транзакционные обновления позволяют это.
Транзакционное обновление или установка могут быть созданы либо с помощью команды snap, либо с помощью POST /v2/snaps Snapd REST API.
Требуется snapd 2.55.
Обновления транзакций с помощью команды snap
Команды snap install и snap refresh принимают дополнительный --transaction= аргумент с all-snaps либо для создания экземпляра процесса как отдельной транзакции, либо per-snap, что используется по умолчанию, для отдельной транзакции для каждой указанной snap:
Чтобы установить привязки hello и hello-world как единую транзакцию, например, выполните следующую команду:
$ snap install hello hello-world --transaction=all-snaps
hello-world 6.4 from Canonical✓ installed
hello 2.10 from Canonical✓ installed
В настоящее время не выводится никаких изменений, журналов или сообщений, показывающих, был ли установлен набор привязок как одна транзакция.
Утверждения
Утверждение - это документ с цифровой подписью, который либо подтверждает действительность процесса, подтвержденного подписывающим лицом, либо содержит информацию о политике, сформулированную подписывающим лицом.
Snapcraft, snapd, Snap Store и фирменные магазины используют утверждения для обработки различных функций и процессов, включая аутентификацию, настройку политики, идентификацию и валидацию.
Утверждения основаны на тексте и принимают контекстно-зависимый формат, который всегда включает один или несколько заголовков, необязательный основной текст и закодированную подпись.
Типы утверждений
Это используемые в настоящее время типы утверждений:
- учетная запись: связывает имя учетной записи с ее идентификатором и другими свойствами
- ключ учетной записи: содержит общедоступную часть ключа, принадлежащего учетной записи
- модель: свойства, определяемые брендом устройства, используемые для создания образа ядра Ubuntu
- серийный номер: привязывает идентификатор устройства к ключу устройства, перенося общедоступную часть
- snap-build: основные свойства snap на момент его создания разработчиком
- объявление snap: определяет различные свойства snap, такие как
snap-id, его имя и издателя, а также политику, связанную с доступом к привилегированным интерфейсам. - snap-revision: подтверждение сохранения при получении сборки snap, помеченной версией
- хранилище: определяет конфигурацию, необходимую для подключения устройства к хранилищу
- системный пользователь: обычно авторизация бренда для создания локальных системных пользователей на указанных устройствах.
- проверка: проверяет конкретную ревизию snap для данной серии
- набор для проверки: группа привязок, которые либо установлены, либо разрешено устанавливать вместе.
Формат утверждения
Типичный формат утверждения с общими заголовками выглядит следующим образом:
type: <type> # For example, “account” or “model”
authority-id: <account id> # On whose authority this assertion is made
<key field 1>: <value> # Fields identifying the object of the assertion
...
<key field N>: <value>
<other field>: <value>
...
revision: <int> # Assertions can be updated with a higher revision
format: <int> # Assertion types can have backward incompatible format changes signaled by a higher format
body-length: <int> # Present if a body is provided with this assertion
sign-key-sha3-384: <key id> # Encoded key id of signing key
<body> # Optional type-dependent body of length `body-length` bytes
<signature> # Encoded signature
- каждое утверждение имеет
type,sign-key-sha3-384и подпись - большинство утверждений содержат
authority-id - значениями являются скаляры (строки, целые числа, логические значения), списки или карты
- некоторые заголовки используются в качестве уникального индекса для указания контекста данного утверждения, вместе они образуют так называемый первичный ключ утверждения
- большинство утверждений также имеют редакцию, позволяющую обновлять конкретное утверждение путем выдачи другого утверждения того же типа и индекса с более высокой редакцией.
Для определенного типа и индекса существует только одно “последнее” действительное утверждение, которое должным образом определяет политику для системы - утверждение с наивысшей редакцией. Для данного утверждения должны быть определены все заголовки индекса.
Просмотр утверждений
Команда snap known <type> [<header>=<value>...] может использоваться для просмотра утверждений или определенного типа:
$ snap known account account-id=generic
type: account
authority-id: canonical
account-id: generic
display-name: Generic
timestamp: 2017-07-27T00:00:00.0Z
username: generic
validation: certified
sign-key-sha3-384: [...]
Аналогично, утверждения snap загружаются вместе с snap с помощью команды snap download:
$ snap download gnome-calculator
Fetching snap "gnome-calculator"
Fetching assertions for "gnome-calculator"
Install the snap with:
snap ack gnome-calculator_945.assert
snap install gnome-calculator_945.snap
Кодировка sha3-384 отличия
Утверждения включают snap-sha3-384 хэш-значение для обеспечения их целостности:
snap-sha3-384: j73cFx0pIMoX4U[...]
Однако эти хэш-значения будут выглядеть по-разному в зависимости от того, были ли они загружены из Snap Store, например, с помощью snap download команды, или извлечены с помощью snapd REST API.
Это различие связано с тем, что Хранилище использует массивы байтов в шестнадцатеричном кодировании, в то время как snapd REST API кодирует хэши с помощью base64.
Разработчики обычно могут использовать значения в хэш-кодировке непосредственно в своем коде, тогда как значения base64 необходимо будет сначала расшифровать, например, с помощью команды base64.
Механизм автоматического подключения интерфейса
Интерфейсы разрешают (или запрещают) доступ к ресурсу за пределами привязки, но они также разработаны таким образом, чтобы быть удобными для пользователей.
Частью этого удобства является то, разрешено ли автоматическое подключение интерфейса при установке snap или snap может запросить включение определенных сверхпривилегированных интерфейсов для начала. Это механизм автоматического подключения.
Автоматические подключения
Механизм автоматического подключения интерфейса snapd был разработан для устранения необходимости ручного подключения при:
- Интерфейс обычно требуется и не имеет никаких или незначительных последствий для безопасности
- Snap предоставляет библиотеки или другой контент, жизненно важный для работы snap, или обращается к ним
- Необходимо подключить снимки, предназначенные для совместной работы
- Политика настройки хранилища применяется для разрешения данной snap использовать интерфейс, который обычно не подключается автоматически.
Смотрите Процесс получения псевдонимов, автоматических подключений и дорожек для получения подробной информации о том, как отправить запрос на автоматическое подключение .
Если snap установлен до того, как интерфейсу было предоставлено разрешение на автоматическое подключение, и впоследствии это разрешение предоставлено и snap обновлен, то при обновлении установленной snap интерфейс будет подключен автоматически.
Процесс автоматического подключения
Всякий раз, когда snap устанавливается или обновляется, snapd проверяет его неподключенные разъемы и их возможные гнезда на предмет возможности автоматического подключения. То же самое он делает для своих слотов и возможных разъемов.
Если имеется только один слот-кандидат для подключения штекера, то подключение интерфейса выполняется автоматически. Требование только к одному кандидату может быть изменено.
Для интерфейса подходящие пары разъемов и слотов определяются с использованием правил, основанных на ограничениях. Язык правил может либо разрешать, либо запрещать автоматическое подключение, причем последнее имеет приоритет.
Правила либо встроены в snapd, либо передаются через утверждения (подписанные документы), которые соответствуют данной snap (snap-декларации). Область действия правил ограничена и они прикреплены к разъему или штекеру интерфейса на любом из этих двух уровней:
- встроенный уровень
- уровень привязки
Чтобы упростить рассуждения об их эффекте, правила из разных уровней / областей не объединены, а скорее расставлены по приоритетам в соответствии с уровнем:
- разъем snap (из snap-описания оснастки со штекером)
- слот для привязки (из описания оснастки с таким слотом)
- уровень встроенных подключаемых модулей
- уровень встроенных слотов
От snap plug до уровня встроенного слота - это уровень, который в первую очередь предоставляет любые правила, определяющие используемые и учитываемые правила. Этот порядок отражает масштаб с точки зрения наиболее конкретного использования, потребления со стороны snap plug, до самых общих правил встроенного разъема.
Встроенные правила воплощают общую политику в отношении того, следует ли подключать интерфейс автоматически и когда именно, и, как таковые, они документируются вместе с интерфейсом. Следовательно, правила объявления snap выражают политику, установленную хранилищем.
Пользователь также может выполнять команды “snap connect” и “snap disconnect”. В частности, ручное “мгновенное отключение” автоматического подключения не позволит последующему обновлению восстановить автоматическое подключение (если только ручное отключение не переопределит это поведение по умолчанию с помощью опции “–забыть”).
Ограничения автоматического подключения
Ниже приведен пример встроенного правила автоматического подключения (прикрепленного к слоту) для интерфейса содержимого:
slots:
content:
allow-auto-connection:
plug-publisher-id:
- $SLOT_PUBLISHER_ID
plug-attributes:
content: $SLOT(content)
Приведенный выше пример разрешает автоматическое подключение, если:
- издатель защелок со стороны гнезда и заглушки один и тот же
- атрибут “содержимое” на штекере и слоте совпадает
Язык правил позволяет нам запрещать или разрешать автоматические подключения со следующими ограничениями:
- значения атрибутов для подключения и слота (на основе регулярных выражений или специальных выражений, таких как $SLOT(content) в примере)
- тип привязки или идентификатор привязки штекера или гнезда для привязки
- издатель слота или штекерной оснастки
- действительные названия штекера или гнезда
- независимо от того, является ли устройство классической системой или нет
- фактическое используемое хранилище или модель устройства (для вариантов использования Интернета вещей)
Дополнительные списки ограничений или значений могут использоваться на языке правил для выражения чередования (логическое ИЛИ). Те же языковые правила можно использовать для определения правил, отличных от автоматических подключений интерфейса, включая политику по умолчанию для обычных подключений и установок, и для переопределения политики для более чувствительных интерфейсов.
Автоматическое подключение к поставщику по умолчанию
Подключаемый модуль интерфейса контента может указывать поставщика по умолчанию. Это название оснастки, которая может быть установлена для удовлетворения потребностей подключаемого модуля. Если в системе нет слота с меткой содержимого разъема, указанный snap будет установлен до snap с разъемом. Однако, если в системе есть слот, в котором уже есть метка содержимого, любой поставщик по умолчанию, указанный подключаемым модулем интерфейса содержимого, игнорируется. Если указанная привязка уже установлена, но в ней нет слота с меткой содержимого, вместо этого указанная привязка будет обновлена при условии, что более новая версия может начать предоставлять метку.
Механизм поставщика по умолчанию запускает установку или обновление snap поставщика, как описано, но он не включает подразумеваемое подключение. Автоматическое подключение произойдет только с помощью общего механизма автоматического подключения и если это разрешено им.
Политика безопасности и "песочница"
Без пользовательских флагов при установке или последующих подключениях к интерфейсу snaps ограничены ограниченной изолированной средой безопасности без доступа к системным ресурсам за пределами snap.
Разработчики Snap должны быть осведомлены о возможностях своих приложений в snap.
Политики безопасности и хранилища работают вместе, позволяя разработчикам быстро обновлять свои приложения и обеспечивать безопасность конечных пользователей, и в этом документе описывается изолированная среда, а также способы настройки политик безопасности для публикуемых вами снимков и работы с ними.
Для получения более общих сведений о том, что влечет за собой ограничение доступа, см. Ограничение доступа к Snap, а также подробности реализации см. Ниже:
- Обзор политики безопасности
- Разрешения для AppArmor, Seccomp и устройств
- Обновите информацию о политике безопасности
- Политики безопасности интерфейса
Для получения справки по устранению проблем, которые могут возникнуть из-за политики безопасности snap, см. раздел Отладка snaps.
Обзор политики безопасности
Разработчикам приложений не обязательно знать или понимать низкоуровневые детали реализации того, как применяется политика безопасности.
Каждая команда, объявленная с помощью apps метаданных snap, отслеживается системой, присваивающей команде метку безопасности.
Этот ярлык безопасности имеет форму, snap.<snap>.<app> где <snap> - название оснастки, а <app> - название приложения.
Например, ниже приведено объявление приложения из snap.yaml:
name: foo
version: 1.0
apps:
bar:
command: bar
baz:
command: baz
daemon: simple
plugs: [network]
- метка безопасности для
bar- этоsnap.foo.bar. В нем используется только политика по умолчанию. - метка безопасности для
bazявляетсяsnap.foo.baz. В нем используетсяdefaultполитика плюсnetworkполитика безопасности интерфейса, предоставляемая базовой программой snap.
Этот ярлык безопасности используется во всей системе, в том числе на этапе ограничения процесса при запуске приложения.
По сути, программа запуска приложений выполняет следующее:
-
Настраивает различные переменные среды:
HOME: установить значениеSNAP_USER_DATAдля всех командSNAP: каталог установки, доступный только для чтенияSNAP_ARCH: архитектура устройства (например, amd64, arm64, armhf, i386 и т.д.)SNAP_DATA: область, доступная для записи, для конкретной версии snapSNAP_COMMON: доступная для записи область, общая для всех редакций snapSNAP_LIBRARY_PATH: дополнительные каталоги, которые следует добавить вLD_LIBRARY_PATHSNAP_NAME: имя привязкиSNAP_INSTANCE_NAME: имя экземпляра snap, включая. ключ экземпляра, если он установлен (snapd 2.36+)SNAP_INSTANCE_KEY: ключ экземпляра, если таковой имеется (snapd 2.36+)SNAP_REVISION: сохраненная версия snapSNAP_USER_DATA: область, доступная для записи каждому пользователю для конкретной версии snapSNAP_USER_COMMON: доступная для каждого пользователя область, общая для всех редакций snapSNAP_VERSION: версия snap (отsnap.yaml)
-
Когда аппаратное обеспечение назначается snap, настраивается группа устройств с устройствами по умолчанию (например, /dev /null, /dev /urandom и т.д.) и любыми устройствами, назначенными этой snap. Аппаратному обеспечению назначаются интерфейсные подключения.
-
Настраивает частное пространство имен mount, общее для всех команд в snap.
-
Настраивает частный
/tmpкаталог, используя пространство имен частного монтирования для каждой привязки и монтируя каталог для каждой привязки в /tmp. -
Настраивает новый экземпляр devpts для каждой команды.
-
Настраивает фильтр seccomp для команды.
-
Выполняет команду в профиле AppArmor для конкретной команды со значением nice по умолчанию.
Разрешения для AppArmor, Seccomp и устройств
При установке snap проверяются его метаданные, которые используются для получения профилей AppArmor, фильтров Seccomp и правил cgroup устройств, наряду с традиционными разрешениями. Такое сочетание обеспечивает надежную локализацию приложений:
-
AppArmor
Профили AppArmor создаются для каждой команды. Они имеют соответствующую метку безопасности и правила AppArmor для конкретных команд для обеспечения доступа к файлам, выполнения приложений, возможностей Linux, монтирования, ptrace, IPC, сигналов, крупномасштабной сети.
Как уже упоминалось, каждая команда выполняется в соответствии с политикой по умолчанию для конкретного приложения, которая может быть расширена через объявленные интерфейсы, которые выражены в метаданных как
plugsиslots. При нарушениях политики AppArmor в snaps в строгом режиме будет отказано в доступе, и обычно для параметра errno установлено значениеEACCES. Обычно нарушение регистрируется в журнале.См. раздел Нарушения AppArmor для получения справки об отслеживании проблем AppArmor.
-
Seccomp
Для каждой команды в snap для запуска создается фильтр seccomp, позволяющий выполнять фильтрацию системных вызовов allowlist, которая затем может быть расширена с помощью объявленных интерфейсов, выраженных в метаданных как
plugsиslots.Процессам, нарушающим политику seccomp, будет отказано в доступе к системному вызову с установленным значением errno
EPERM(snapd выпускается до версии 2.32SIGSYS), и нарушение будет зарегистрировано в журнале.Смотрите Нарушения Seccomp для получения справки об отслеживании проблем Seccomp.
-
Группа устройств
правила udev генерируются для каждой команды для пометки устройств, чтобы их можно было добавлять / удалять в группу устройств команды. Однако по умолчанию устройства не помечены, и cgroup устройств не используется, а AppArmor используется для обеспечения доступа.
Согласно определению snapd, группа устройств может использоваться в дополнение к AppArmor, когда объявлен зависимый интерфейс, выраженный через
plugsиslotsв метаданных.Процессам, обращающимся к устройствам, не входящим в группу устройств, специфичную для snap, будет отказано в доступе, если значение errno равно
EPERM. Нарушения доступа не регистрируются. -
Традиционные разрешения
Традиционные разрешения для файлов (владелец, группа, списки управления доступом к файлам и другие) также применяются с помощью snaps.
Процессам, пытающимся получить доступ к ресурсам, которые не разрешены традиционными разрешениями на доступ к файлам, отказано в доступе, для параметра errno обычно установлено значение
EACCES(подробности см. На странице руководства по операции). Нарушения доступа не регистрируются.
Следовательно, все привязки выполняются в соответствии с политикой безопасности по умолчанию, которая может быть расширена за счет использования интерфейсов.
Обновите информацию
По умолчанию службу, запущенную из snap, необходимо перезапускать при каждом обновлении snap (подробнее см. в разделе Службы и демоны).
Остановка и запуск службы необходимы для поддержки snap revert и копирования системных данных snap из текущей версии в новую.
Системные данные обычно включают базы данных, файлы данных и файлы конфигурации (см. Расположение данных), хотя все это зависит от разработчика snap.
Возврат snap с помощью snap revert восстанавливает системные данные snap до их предыдущего состояния, и службы, получающие доступ к этим данным, должны быть остановлены для защиты целостности данных, а также для облегчения внесения изменений в политику безопасности, которые требуются, когда snap обновляет местоположение системных данных.
Чтобы устранить любые потенциальные проблемы при необходимости перезапуска, snapd будет проверять наличие запущенных процессов, связанных с snap, перед каждым обновлением:
- если никакие процессы не запущены, выполняется обновление.
- при обнаружении процессов, инициированных systemd, сначала останавливаются связанные с ними модули, обновляется snap, и эти модули запускаются снова.
- при обнаружении других процессов, инициированных snap, для выполнения обновления используется функция обновления информации.
Обновить политику безопасности
Демон snap использует AppArmor и Seccomp для создания политики безопасности, связанной с конкретной версией snap. Это определяет, к чему snap может получить доступ в вашей системе. Профили AppArmor и фильтры Seccomp создаются для каждой команды, и хотя профили AppArmor можно изменять и перезагружать во время выполнения процесса, фильтры Seccomp - нет.
Политика безопасности Snap разрешает доступ на чтение и запись для текущей версии и доступ только для чтения для других версий, чтобы сохранить возможности snap revert. Более конкретно, если 123 это текущая редакция, для политики AppArmor установлено значение разрешить rw вкл SNAP_DATA=/var/snap/foo/123.
До того, как стала доступна информация об обновлении, если обновление происходило во время работы snap, его политика AppArmor была обновлена, чтобы разрешить w (запись) в новой версии и r (чтение) в старых версиях, включая текущую версию. Политика была применена немедленно, что означало, что операции записи для запущенных процессов начнут завершаться сбоями.
Политики безопасности интерфейса
Интерфейсы реализованы в виде подключаемых модулей и слотов. Подключаемый модуль в одном snap может подключаться к разъему в другом, и это обеспечивает доступ к необходимым ресурсам.
Команда snap connections может использоваться для просмотра доступных интерфейсов вместе с их слотами и разъемами.
$ snap connections
Interface Plug Slot Notes
home wormhole:home :home -
log-observe gnome-logs:log-observe :log-observe -
mount-observe gnome-system-monitor:mount-observe :mount-observe -
[...]
В приведенном выше примере вывода gnome-logs привязка подключена к log-observe интерфейсу, что означает, что политика безопасности из log-observe была добавлена в gnome-logs.
Интерфейсы могут быть объявлены как для каждой привязки, так и для каждой команды:
- если она объявлена для каждой оснастки, то при подключении интерфейса ко всем командам в оснастке политика безопасности интерфейса добавляется к политике безопасности каждой команды
- если она объявлена для каждой команды, только для команд в snap, которые объявляют использование интерфейса, к ним добавляется указанная политика безопасности интерфейса
Интерфейс может подключаться автоматически при установке или требовать, чтобы пользователь подключал их вручную. Подключения и разъединения интерфейса выполняются с помощью команд snap connect и snap disconnect. Подробнее см. в разделе Интерфейсы.
Производительность Snap
Среда snap не должна влиять на производительность запущенного приложения, и любой инструмент мониторинга производительности или системы будет работать с процессами snap точно так же, как и с другими приложениями и процессами.
Однако мониторинг конкретных операций snap, наряду с производительностью установки и распространения, может помочь как при принятии решений о упаковке, так и при настройке snap, а также выявить потенциальные проблемы с производительностью, неподконтрольные приложению. Ниже описаны несколько таких подходов.
На устройствах под управлением Ubuntu Core системный параметр можно использовать для создания загрузочной диаграммы, показывающей время запуска системы и производительность:
Время отладки Snap
Синхронизация выходных данных snap может быть полезным показателем общей производительности, но она также может выявить узкие места в производительности и цели для улучшения. Команда snap debug включает в себя несколько опций для получения выходных данных синхронизации времени выполнения, внутренних действий по обеспечению и времени запуска подсистемы.
Время выполнения
По умолчанию snap debug timings команда будет выдавать временные выходные данные для определенного изменения, которое само по себе представляет набор операций, выполняемых демоном snap.
Синтаксис команды следующий:
snap debug timings <change-id>
Идентификаторы изменений (<change-id>) перечислены под ID столбцом в выходных данных для snap changes:
ID Status Spawn Ready Summary
8302 Done yesterday at 18:24 BST yesterday at 18:24 BST Install "chromium" snap
8303 Done today at 11:46 BST today at 11:46 BST Remove hotplug connections and slots of device /dev/ttyACM0 (100 Series/C230 …; serial: 6564B3891339) with interface "serial-port"
8304 Done today at 11:50 BST today at 11:50 BST Add hotplug slot of interface "/dev/ttyACM0 (100 Series/C230 …; serial: 6564B3891339)" for device serial-port with hotplug key "056a4e841487…"
Вместо идентификатора изменения, --last аргумент может использоваться с четко определенным именем для изменения, таким как auto-refresh, install, refresh, remove или try.
С аргументом --verbose выходные данные также будут содержать метку для изменения:
ID Status Doing Undoing Label Summary
160162 Done 750ms - prerequisites Ensure prerequisites for "chromium" are available
^ 681ms - install-prereq install "cups"
ИДЕНТИФИКАТОР представляет собой числовой идентификатор для задач, порожденных логикой изменений, при этом вложенные задачи обозначаются символом ^ под их родительским элементом.
Следующие диаграммы были созданы на основе Doing выходных данных столбца snap debug timings --last=install после установки chromium snap, сначала из кэша, а затем после новой установки:
Данные времени отладки для кэшированной установки Chromium snap
Данные о времени отладки для холодной установки Chromium snap
Внутренняя деятельность
Наряду со временем выполнения изменения, также отслеживается время a, затраченное на обработку внутренних действий snapd, называемых "действиями по обеспечению". Убедитесь, что действия выполняются на регулярной основе и что они время от времени генерируют новые задачи в виде изменений для продолжения первоначального действия. Они включают следующее:
auto-refreshbecome-operational(только для ядра Ubuntu)install-system(только для ядра Ubuntu)refresh-catalogsrefresh-hintsseed(только для ядра Ubuntu)
Отслеживание времени выполнения таких действий по обеспечению безопасности может быть полезным. Например, автоматическое обновление включает в себя несколько процессов для различных уже установленных snaps, включая подключение к Snap Store. Таким образом, информация о сроках может помочь в устранении неполадок с обновлением.
Используйте --ensure= аргумент, чтобы просмотреть сведения о времени выполнения последнего указанного действия обеспечения, или с необязательным --all аргументом, чтобы отобразить данные о времени выполнения каждого действия обеспечения.
$ snap debug timings --ensure=refresh-catalogs
ID Status Doing Undoing Summary
refresh-catalogs 309ms -
^ 69ms - query store for sections
^ 170ms - query store for catalogs
Время запуска подсистемы
Данные о времени запуска для двух подсистем, load-state и ifacemgr, также отслеживаются и могут выводиться с --startup аргументом:
$ snap debug timings --startup=ifacemgr
ID Status Doing Undoing Summary
ifacemgr - -
^ 8ms - setup security backend "apparmor" for snap "core"
^ 7ms - setup security backend "mount" for snap "lxd"
^ 16ms - setup security backend "apparmor" for snap "lxd"
^ 12ms - load unchanged security profiles of snap "lxd"
^ 7ms - setup security backend "apparmor" for snap "vlc"
^ 5ms - load unchanged security profiles of snap "vlc"
В приведенном выше примере показано время выполнения, связанное с менеджером интерфейсов snapd, которое включает время настройки профилей безопасности для всех установленных snaps и их интерфейсов до того, как snapd начнет функционировать.
Производительность SquashFS
SquashFS - это стандартная файловая система Linux, которая заключает операционную структуру каталогов в один сжатый файл. Обычно используется для предоставления загрузочных операционных сред Linux на USB-накопителе, но также используется для упаковки snap.
Snap - это файл SquashFS, который содержит библиотеку и двоичную среду для snap, а также метаданные, описывающие доступ к нему и возможности. Файл SquashFS монтируется systemd либо при первой установке snap, либо на ранних этапах загрузки системы, такой как Ubuntu Core, в которой уже установлены snaps.
Распаковка SquashFS происходит при первом запуске snap в системе и тщательном мониторинге ее производительности. В частности, производительность распаковки может отличаться в зависимости от используемого алгоритма сжатия, размера архива SquashFS, количества содержащихся в нем файлов, осуществляется ли к нему доступ в первый раз (холодный кэш) или к нему обращаются повторно (теплый кэш).
Снимки могут использовать один из двух различных типов сжатия, либо xz, либо lzo, при этом для большинства снимков по умолчанию используется значение xz. Эти алгоритмы были выбраны из-за их степени сжатия и скорости при использовании со снимками, которые отличаются количеством содержащихся в них файлов и их размером.
Chromium, например, содержит более 300 МБ почти 1000 файлов, и доступ к каждому файлу занимает значительно больше времени, чем запуск приложения. В этом случае формат сжатия xz является самым медленным, более чем в два раза превышая следующий по скорости формат, gzip. Это показано на следующей “диаграмме блоков”, где каждый тест был запущен 10 раз с использованием 6 различных вариантов сжатия. Каждый тест сам по себе представляет собой совокупность затрат времени на установку, двукратный запуск приложения и хэширование каждого файла в архиве SquashFS:
Также была протестирована скорость распаковки как для доступа к холодному кэшу (1), так и для доступа к теплому кэшу (2) с использованием целого ряда алгоритмов сжатия. Опять же, для Chromium измерение скорости запуска показывает, что xz изначально работает очень плохо при первом запуске, но значительно улучшается при последующих запусках:
На коэффициенты сжатия для различных алгоритмов сжатия также влияет размер файлов внутри snap:
Эти сравнения в конечном итоге привели к добавлению lzo в качестве дополнительного алгоритма сжатия, но его использование со snaps полностью зависит от типа и структуры файлов в архиве SquashFS.
Процесс выпуска Snapd
snapd - это фоновая служба, которая управляет вашими снимками и поддерживает их. Сама она поставляется либо как snap, либо как традиционный пакет Linux, такой как deb или RPM.
Существует два типа выпуска; основной и второстепенный выпуски, обозначаемые числовым статусом для их номеров версий с дополнительным периодом и номером, зарезервированным для второстепенных выпусков:
- основные версии: 2.53, 2.54, 2.55
- выпуски второстепенных версий: 2.53.1, 2.53.2
Разница между основным и второстепенным выпуском заключается в его планировании, подготовке и мотивации. Цикл выпуска основного выпуска происходит каждые несколько недель, но иногда нам нужен промежуточный выпуск второстепенной версии, содержащий меньшие изменения и исправления.
Различия между основным выпуском и последующим второстепенным выпуском (например, 2.53 -> 2.53.1) настолько малы и целенаправленны, насколько это возможно, при этом основной рефакторинг кода и новые функции опущены. Это не всегда возможно, потому что иногда ошибки или функции являются сложными, но это наша главная цель.
Крупные выпуски модулей, например, между snapd 2.x и 3.x, происходят крайне редко, и в настоящее время никаких дальнейших выпусков модулей не планируется.
Пошаговый процесс выпуска
Ниже приведен типичный процесс выпуска для snapd, начинающийся с создания ветки выпуска и пометки ее для выпуска:
-
Код, предназначенный для следующей версии snapd, объединен с основной веткой на GitHub.
-
Для основного выпуска мы создаем новую ветку от master с именем
release/<VERSION>, где<VERSION>всегда указан номер основной версии. Тег окончательной основной версии для данного выпуска всегда находится в этой ветке, и там же мы будем помечать последующие второстепенные выпуски для этой основной версии. -
Если в ветку "Новая версия" добавляется дополнительный код, мы сначала проверяем, что все необходимые материалы находятся в
release/VERSIONветке, прежде чем помечать и подписывать тег ключом GPG одного из сопровождающих snapd, у которого есть разрешение на создание релиза. -
Затем на основе тега выпуска мы создаем несколько артефактов для snapd в разных местах, включая:
- Пакеты Debian для минимально необходимых дистрибутивов Ubuntu в PPA snappy-dev image. Это потому, что мы создаем как ядро snap, так и initrd для UC20 + на основе этого PPA. В настоящее время этот список дистрибутивов содержит просто Ubuntu 16.04 LTS (Xenial Xerus) и Ubuntu 20.04 LTS (Focal Fossa).
- Оснастка snapd.
- Основная оснастка.
- Исходные архивы содержат i) код Go от производителя, ii) без кода Go от производителя и iii) только с кодом Go от производителя. В основном они используются другими дистрибутивами для создания своих пакетов snapd.
- Другие традиционные форматы пакетов Linux, такие как debs для Debian upstream, RPM для Fedora и все их производные и т.д.
-
Затем мы выпускаем core snap и snapd snap на соответствующих бета-каналах.
Мы не выпускаем эти снимки на соответствующие пограничные каналы и не выпускаем версии с пограничного канала на бета-версии или более поздние каналы. Для наших выпусков каналы имеют особое назначение, так что версия snap, которая попадает в канал edge, никогда не попадет в каналы beta / candidate / stable, и наоборот.
-
Теперь запущены автоматические тесты, и мы отправим внутренний запрос Canonical для тестирования новой версии snapd.
-
Если в результате автоматического тестирования не обнаружено проблем, мы оставляем snapd и основные снимки в бета-версии как минимум на 2 недели.
-
После периода бета-тестирования мы перемещаем snap на канал-кандидат.
-
Если сообщество и команды положительно отзываются о готовящемся выпуске, он постепенно переходит на стабильный канал.
Выпуск почти всегда завершается для выпуска в понедельник или вторник. Это оптимизирует пропускную способность и позволяет остановить развертывание, если у пользователей, которые получают snap раньше, возникают проблемы.
-
Теперь мы запускаем процесс SRU для выпуска обновленной версии пакета Debian от snapd до выпусков Ubuntu в основном архиве, включая выполнение сборок / загрузок ESM по мере необходимости.
Сопоставление номеров версий
Номер версии snapd snap в его стабильном канале всегда будет соответствовать номеру версии выпущенной версии snapd или core snap в соотношении 1:1.
Например, в теге git 2.51.1 на стабильном канале будет опубликована только одна редакция с этим номером версии.
Эта политика с одной ревизией для каждого номера версии помогает упростить отладку, когда выходные данные команды snap version позволяют нам изолировать ревизию snapd или основных снимков, которые соответствуют выпущенной версии.
Однако номер версии пограничного канала snapd snap не соответствует соотношению 1: 1 для одной редакции. Вместо этого номер версии включает git-коммит, из которого была собрана snap, например 2.53.1+git563.g5297d66, что упрощает отслеживание выпуска до git-коммита, из которого была собрана редакция edge.
Номер версии core snap, выпущенной на канале edge, немного сложнее, поскольку git-коммит, который он отображает, является коммитом проекта snapd-vendor в launchpad, который включает исходный код snapd и зависимости Go от поставщика.
Стабильность и планирование выпуска
Для производственного использования пограничный канал не рекомендуется. Функциональность может работать нестабильно, и ее невозможно будет обновить между выпусками. Для сравнения, стабильный выпуск канала будет оставаться обратно совместимым с предыдущим выпуском в той степени, в какой это технически возможно, при этом все еще будут исправлены ошибки или проблемы безопасности.
Иногда, когда мы не готовы к выпуску основного или второстепенного выпуска, но нам необходимо внедрить исправление для конкретной проблемы, мы создаем конкретный выпуск ветки и делимся им со всеми, кого это может затронуть. Этот выпуск ветки обычно закрывается после подтверждения исправления, его загрузки в master и выпуска по стабильному каналу.
В отличие от некоторых проектов, у нас нет специальной “заморозки кода”, когда в релизе нельзя добавлять или удалять ничего незапланированного. Вместо этого запросы на извлечение, предназначенные для следующего выпуска, помечаются соответствующим этапом и как заблокированные. Это предотвращает их случайное объединение в неправильную ветку выпуска или до создания следующей основной ветки выпуска.
После создания ветки выпуска мы обычно стараемся пометить выпуск как можно скорее. Как упоминалось ранее, иногда требуется исправить новые ошибки или добавить функции. После объединения с master они переносятся обратно в ветку release. Мы можем добавлять коммиты из master в ветку release, прежде чем помечать релиз в ветке release.
Однако после того, как релиз был помечен, мы никогда не будем помечать его повторно. Вместо этого, если будет обнаружена проблема, препятствующая его фактическому стабильному выпуску, мы создадим новый тег для последующего второстепенного выпуска. Например, если ошибка была обнаружена в бета-версии 2.54, она никогда не попадет на стабильный канал. Вместо этого версия 2.54.1 станет первой версией 2.54 на стабильном канале.
Если вам интересно, какие новые функции будут включены в следующий крупный выпуск snapd, вы можете ознакомиться со страницей дорожной карты здесь: https://snapcraft.io/docs/snapd-roadmap 4. На сроки будущих выпусков на этой странице ни в чем не следует полагаться, это просто оценки. Даты, указанные для уже выпущенных версий snapd, должны быть точными и относиться к основной версии, а не к каким-либо связанным с ней второстепенным версиям (поскольку второстепенные выпуски обычно не включают новых функций, только исправления ошибок или очень маленькие и целевые функции).
Лучший способ определить, когда будет выпущена следующая версия snapd, - это связаться с нами через IRC или форум, и мы предоставим вам наилучшую оценку, какую сможем на данный момент.