Многие задачи, связанные с управлением хост-системой, лучше всего запускать непосредственно на хосте, и я бы здесь избегал Docker.
На уровне insmod (8) контейнеры Docker обычно запускаютсяс ограниченным набором разрешений и не может делать чрезвычайно инвазивные изменения, такие как это на хосте.Вероятно, существует опция docker run --cap-add, которая теоретически могла бы сделать это возможной, но существенным конструктивным утверждением Docker является то, что процессы контейнеров не должны иметь возможность воздействовать на другие контейнеры или хост, как этот.
Наеще более широкий уровень Linux, версия сборки пользовательских модулей ядра должна соответствовать ядру хоста точно .Это означает, что если вы обновляете ядро хоста (например, для обычного обновления безопасности), вам также необходимо пересобрать и переустановить все пользовательские модули.Основные дистрибутивы Linux имеют поддержку для этого, но если вы упаковали управление этим в контейнер, вы должны помнить, как перестроить контейнер с более новыми заголовками ядра и убедиться, что он не будет перезапущен, пока вы не перезагрузите хост,Это может быть сложно.
На уровне Docker вы фактически создаете образ, который можно использовать только в одной очень специфической системе.Обычно концепция заключается в создании изображения, которое может быть повторно использовано в нескольких контекстах;Вы хотите иметь возможность отправить образ в реестр и запустить его в другой системе с минимальной конфигурацией.Это трудно сделать, если образ привязан к чрезвычайно определенной версии ядра или другой зависимости на уровне хоста.