У меня есть собственный модуль ядра, который мне нужно собрать для определенного оборудования. Я хочу автоматизировать настройку своей системы, поэтому я контейнеризировал несколько приложений. Одна из вещей, которые мне нужны, это модуль ядра. Предполагая, что заголовки ядра и др. в контейнере Docker и ядро на хосте предназначены для одной и той же версии, возможно ли, чтобы весь мой процесс сборки был контейнеризован и позволял хосту использовать этот модуль?


Многие задачи, связанные с управлением хост-системой, лучше всего выполнять непосредственно на хосте, и я бы не стал использовать здесь Docker.
На уровне инсмод(8) контейнеры Docker обычно работают с ограниченным набором разрешений и не могут вносить чрезвычайно инвазивные изменения, подобные этому, на хосте. Вероятно, есть вариант docker run --cap-add, который теоретически сделал бы это возможным, но важное заявление о дизайне Docker заключается в том, что процессы контейнера не должны иметь возможность влиять на другие контейнеры или хост таким образом.
На еще более широком уровне Linux версия сборки пользовательских модулей ядра должна соответствовать ядру хоста точно. Это означает, что если вы обновляете ядро хоста (например, для обычного обновления безопасности), вам также необходимо пересобрать и переустановить любые пользовательские модули. Основные дистрибутивы Linux поддерживают это, но если вы упаковали управление этим в контейнер, вы должны помнить, как перестроить контейнер с более новыми заголовками ядра и убедиться, что он не перезапустится, пока вы не перезагрузите хост. . Это может быть непросто.
На уровне Docker вы фактически создаете образ, который можно использовать только в одной очень конкретной системе. Обычно концепция состоит в том, чтобы создать образ, который можно повторно использовать в различных контекстах; вы хотите иметь возможность отправить образ в реестр и запустить его в другой системе с минимальной конфигурацией. Это сложно сделать, если образ привязан к очень конкретной версии ядра или другой зависимости на уровне хоста.
Я определенно могу оценить проблемы, о которых вы упомянули, и то, что мое намерение довольно анти-шаблон для использования контейнеров. Общая цель состоит в том, что я хочу изолировать среды сборки. Хотя создаваемый образ, вероятно, не может использоваться во многих системах, моя главная цель — заставить мою собственную систему работать, а не обязательно отправлять ее в Docker Hub. tl; dr Я хочу иметь возможность установить Fedora, docker-ce и иметь все свое программное обеспечение готовым к работе без необходимости делать что-то еще.
Установка, такая как Kickstart, или инструменты автоматизации, такие как Ansible или Chef, вероятно, лучше подходят для этого варианта использования.
Я бы предположил, что с точки зрения ядра не имеет значения, из какого пространства имен загружается модуль, учитывая, что процесс, вызывающий
init_module(2), имеет для этого достаточно прав (например, запускается в привилегированном контейнере). Просто предположение, а не конкретный ответ.