Как узнать, какую версию Debian в какой версии Debian можно запустить Docker?
У меня есть производственные серверы, на которых работают приложения, совместимые с различными версиями Debian (яблочко и книжный червь). Мне хотелось бы переместить все эти приложения на одну машину, и для этого я подумал о их контейнеризации.
Но насколько я понимаю, вы не можете просто запустить любой образ контейнера на любом ядре. В этом посте объясняется, что программное обеспечение, которое вы хотите запустить, должно быть «достаточно совместимым», иначе возникнут проблемы.
Вот почему я ищу какую-то матрицу совместимости, которая бы подсказывала мне, какая версия Debian на каких версиях ядер может нормально работать в качестве гостя.
Поскольку я не могу найти такую матрицу, то, наверное, я что-то упускаю или что-то не понимаю в контейнерах. Это индивидуально для каждого приложения? Неужели то, что я пытаюсь сделать, просто не рекомендуется, и мне следует продолжать использовать один сервер для каждой версии Debian?
Хм, это приложения Django, так что, думаю, не так уж и много. Однако они зависят от postgresql и exim.
Для каждого из них существует множество образов докеров, которые не вызывают каких-либо зависимостей от ядра. Я еще не встречал приложения, которое бы это делало, хотя я уверен, что они существуют.
Ответы 1
TLDR, это не должно беспокоить большинство программ. Не думайте об этом слишком усердно, если только ваша ОС или образ контейнера не являются действительно древними.
Почему может возникнуть проблема?
Программное обеспечение пользовательского пространства зависит от API ядра (т. е. системных вызовов) для выполнения многих задач. Если часть программного обеспечения построена на основе API одного ядра, но затем запускается на другом ядре, она может попытаться выполнить некоторые системные вызовы, которые старое ядро не поддерживает. Или, возможно, в API были серьезные изменения между версиями. В этих случаях вы получите ENOSYS или EINVAL, и ваша программа в пользовательском пространстве, скорее всего, выйдет из строя.
В контексте контейнеризации, поскольку контейнеры используют ядро хоста, может возникнуть несоответствие версий между ядром, на котором было создано программное обеспечение, и ядром, на котором оно фактически работает.
Почему это обычно не вызывает беспокойства?
Чтобы эта проблема проявилась, программа пользовательского пространства должна выполнить недопустимый системный вызов. Но из-за зрелости и политики ядра Linux это на самом деле маловероятное обстоятельство.
Во-первых, ядро Linux имеет заявленную политику «никогда не нарушать пространство пользователя». На практике это означает, что старые API ядра редко (или даже никогда; я не уверен) удаляются или в них вносятся критические изменения. Эта политика настолько важна, что часто намеренно сохраняется «технически ошибочное» поведение. Это означает, что почти гарантировано, что программное обеспечение, созданное на базе более старого ядра, будет работать на более новом. В противном случае это считается ошибкой регрессии.
Во-вторых, Linux как проект на данный момент имеет более чем 30-летнюю историю, а это означает, что наиболее часто используемые API остаются стабильными в течение длительного времени. Поэтому подавляющее большинство программного обеспечения будет прекрасно работать на любом достаточно современном ядре, если только оно не использует совершенно новый API ядра. Разработчики тех немногих программ, которые это делают, часто знают об этом и реализовали безопасные резервные варианты для старых ядер.
Какие зависимости у ваших приложений от версии ядра?