Как Docker разрешает переносные контейнеры, если библиотеки Kernel меняются

Если моя программа зависит от некоторой функции библиотеки ядра, и эта функция, в свою очередь, имеет цепочку зависимостей, как докеры остаются маленькими и переносимыми, не делая моментальных снимков всех библиотек ядра (и управляя проблемами зависимостей при выполнении функции а не на уровне библиотеки)? Другими словами, как он изолирует себя от изменений в библиотеках ядра от одной версии к другой, и делает ли это это в библиотеке или функции granlarity?

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

функция 1 и 2 зависят и работают с функциями в ядре Lib A версии 1.0

функция 1 работает с Lib A версии 1.1 функция 2 разрывается с Lib A версии 1.1 (функция 2 по-прежнему нуждается в Lib A версии 1.0)

Я не знаю много о Docker, так что это вопрос новичков.

Ответы

Ответ 1

Нет такой вещи, как "библиотека ядра". Ближайшие вещи к тому, что вы описываете:

  • libc, который является частью изображения контейнера и, следовательно, не изменяется.

  • Ядро Linux ABI, которое в основном постоянное. Хотя некоторые изменения иногда происходят с ядром ABI, это делается как можно реже - разработчики ядра делают все возможное, чтобы поддерживать обратную совместимость. В случае внесения изменений чаще всего в компонентах, которые не будут иметь отношения к приложениям, запущенным в контейнере (например, аудио/видеовыход, управление динамическими устройствами и т.д.).