Каковы концептуальные и практические различия между контейнерами (например, докер) и инкапсулированными пакетами (например, flatpack, snap)?
Я часто читал, что оба понятия совершенно разные, но я не мог найти хорошее объяснение того, где лежат различия. Обе связывают зависимости и ограничивают общение с внешним миром.
Когда я должен упаковать свое приложение в контейнер для развертывания? Когда инкапсулированные пакеты будут предпочтительнее?
2 ответа
Flatpack предлагает подсказки, в число которых входят:
Является ли Flatpak контейнерной технологией?
Это может быть, но это не должно быть. Поскольку настольное приложение потребовало бы довольно обширных изменений, чтобы его можно было использовать при запуске в контейнере, вы, вероятно, увидите, что Flatpak в основном развернут как удобная технология объединения библиотек на ранних стадиях, причем для большинства приложений со временем вводится песочница или контейнеризация.
В целом, хотя мы стараемся избегать использования термина "контейнер", когда говорим о Flatpak, так как он имеет тенденцию вызывать сравнения с Docker и Rocket, сравнения, которые быстро перестают иметь технический смысл из-за очень разных проблемных пространств, которые пытаются решить эти технологии. И поэтому мы предпочитаем использовать термин "песочница".
Flatpak привязан к Linux?
Да. Мы явно используем многие функции ядра Linux (bind mounts, namespaces, seccomp и т. Д.) Для создания песочницы, в которой работают приложения Flatpak. Возможно, можно использовать эквивалентные технологии в других ядрах, но это было бы не тривиальный объем работы, и мы не считаем это одним из наших приоритетов.
Контейнер призван обеспечить изоляцию в любой системе, которая реализует свой протокол runc / containerd, и скоро будет в Windows и Linux.
Это отличается от формата упаковки программного обеспечения, который довольно привязан к ОС.
Смотрите " Flatpak, Appimage и Snap - Как они складываются?".
Вступление:
Я считаю, что для разработчиков это действительно вопрос о том, чтобы сделать ставку на то, куда движется будущее упаковки их приложений, что-то вроде дебатов VHS против betamax на заре потребительского видео.
Flatpak, AppImage и Snap — все это контейнеры приложений, называемые также «изолированными» приложениями, которые связывают зависимости, создают изоляцию и обещают переносимость.
Если все они делают (примерно) одно и то же, хотя и немного по-разному, то каковы рациональные основания для выбора одного формата пакета над другим? Вот несколько соображений, на которые я обращал внимание, пытаясь принять решение об выборе формата упаковки.
Выбор:
Я исключаю Docker из приведенного ниже списка, поскольку он считается «контейнером процессов», используемым преимущественно для предоставления услуг удаленным подключениям, а не для предоставления локальных услуг.
Flatpak: Это поддерживается RH, поэтому у них есть влияние на рынке, чтобы навязывать стандарты. ОДНАКО: в RHEL 9 RH по-прежнему предупреждает своих клиентов не использовать Flatpak в производственных системах. Flatpak, вероятно, будет жить в будущем, но в него могут быть внесены существенные изменения, прежде чем RH согласится его поддерживать. Кроме того, стандарты Flatpack различаются между Fedora и RHEL . Оказывается, налагая требование использовать RPM, плоские пакеты можно отслеживать вместе с не-плоскими пакетами в базе данных пакетов. Это было бы хорошо.
Snap: это поддерживается Canonical, и Марк Шаттлворт описал Snap как что-то вроде того, что у Docker & apt родился ребенок. У них тоже огромное количество рыночных облаков, и они могут навязывать нам стандарты. И это стандарт, который Canonical в настоящее время готова поддерживать в производственных системах, в отличие от RH в отношении Flatpak. Одна вещь, которую я заметил, однако, проводя некоторое тестирование, заключается в том, что снимки не видны при запросе пакета db:
dpkg -l | grep snapNameничего не возвращает. Кроме того, несмотря на то, что установка снапа также устанавливает зависимости, удаление снапа не приводит к их автоматическому удалению. Таким образом, у нас нет единого источника Истины для состояния упаковки нашей системы, которое не является идеальным. Что касается моментальных снимков, управляемых вне БД системных пакетов, аналогия Марка не работает. Еще одно существенное отличие, которое я обнаружил в Snap, заключалось в том, что, в отличие от стандартного пакета, поддерживались не все архитектуры пакета: « ошибка: snap «slack» недоступен в стабильной версии для этой архитектуры (arm64), но существует в других архитектурах (amd64) » . . Наконец, Snap имеет огромное количество доступных пакетов по сравнению с Flatpak и AppImage.AppImage : у этого нет корпоративной поддержки, что одновременно и хорошо, и плохо. Мне нравится независимость, но в то же время я никогда не вижу полной интеграции ни с RH, ни с базой данных системных пакетов Ubuntu. В идеале я бы хотел, чтобы любое решение контейнера приложений находилось в центральной базе данных пакетов. Так что даже если бы существовала существенная качественная разница, я считаю, что наличие двух отдельных систем управления пакетами не очень хорошая вещь. Вот почему я бы избегал этого в своих целях - не потому, что это "плохо" само по себе, а просто потому, что я не хочу раздельного управления пакетами.
Заключение:
Мой собственный идеологический уклон отдает предпочтение дистрибутивам Debian/Ubuntu, поскольку возможны полноценные обновления на месте, что невозможно для производных RH и RH. Таким образом, даже если бы Flatpak был немного лучше, чем Snap, в качестве контейнера приложений (или «изолированного приложения»), я бы все равно склонялся к Snap, поскольку мне не нужно выплескивать ребенка вместе с водой, если я использую Linux на IoT. или другое устройство Edge, которое я не могу просто стереть безнаказанно.
Я подозреваю, что это вопрос, над которым разработчики коллективно заламывали руки в отношении того, какой лагерь они хотят поддержать. Это лишь некоторые дополнительные, не исчерпывающие соображения, которые следует взвесить при выборе.