запустить службу systemd в контейнере OCI (runc)

529
Alex Bidnichenko

В настоящее время я пытаюсь запустить службу systemd (avahi-daemon) в контейнере RUNC, и все мои попытки провалились. Я столкнулся с несколькими статьями для одной и той же задачи, но для решения докера и еще одной . У кого-нибудь есть успешный опыт с той же задачей?

Это мой config.json:

{ "ociVersion": "1.0.0-rc1", "platform": { "os": "linux", "arch": "arm" }, "process": { "terminal": false, "user": { "uid": 0, "gid": 0 }, "args": [ "/bin/systemctl", "start", "avahi-daemon" ], "env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "TERM=xterm" ], "cwd": "/", "capabilities": { "bounding": [ "CAP_AUDIT_WRITE", "CAP_KILL", "CAP_NET_RAW", "CAP_SYS_ADMIN", "CAP_NET_BIND_SERVICE" ], "effective": [ "CAP_AUDIT_WRITE", "CAP_KILL", "CAP_NET_RAW", "CAP_SYS_ADMIN", "CAP_NET_BIND_SERVICE" ], "inheritable": [ "CAP_AUDIT_WRITE", "CAP_KILL", "CAP_NET_RAW", "CAP_SYS_ADMIN", "CAP_NET_BIND_SERVICE" ], "permitted": [ "CAP_AUDIT_WRITE", "CAP_KILL", "CAP_NET_RAW", "CAP_SYS_ADMIN", "CAP_NET_BIND_SERVICE" ], "ambient": [ "CAP_AUDIT_WRITE", "CAP_KILL", "CAP_NET_RAW", "CAP_SYS_ADMIN", "CAP_NET_BIND_SERVICE" ] }, "rlimits": [ { "type": "RLIMIT_NOFILE", "hard": 1024, "soft": 1024 } ], "noNewPrivileges": true }, "root": { "path": "rootfs", "readonly": false }, "hostname": "runc", "mounts": [ { "destination": "/proc", "type": "proc", "source": "proc" }, { "destination": "/dev", "type": "tmpfs", "source": "tmpfs", "options": [ "nosuid", "strictatime", "mode=755", "size=65536k" ] }, { "destination": "/dev/pts", "type": "devpts", "source": "devpts", "options": [ "nosuid", "noexec", "newinstance", "ptmxmode=0666", "mode=0620", "gid=5" ] }, { "destination": "/dev/shm", "type": "tmpfs", "source": "shm", "options": [ "nosuid", "noexec", "nodev", "mode=1777", "size=65536k" ] }, { "destination": "/dev/mqueue", "type": "mqueue", "source": "mqueue", "options": [ "nosuid", "noexec", "nodev" ] }, { "destination": "/sys", "type": "sysfs", "source": "sysfs", "options": [ "nosuid", "noexec", "nodev", "ro" ] }, { "destination": "/sys/fs/cgroup", "type": "cgroup", "source": "cgroup", "options": [ "ro" ] } ], "linux": { "resources": { "devices": [ { "allow": false, "access": "rwm" } ] }, "namespaces": [ { "type": "network" }, { "type": "ipc" }, { "type": "uts" }, { "type": "mount" } ], "maskedPaths": [ "/proc/kcore", "/proc/latency_stats", "/proc/timer_stats", "/proc/sched_debug" ], "readonlyPaths": [ "/proc/asound", "/proc/bus", "/proc/fs", "/proc/irq", "/proc/sys", "/proc/sysrq-trigger" ] } 

Этот файл конфигурации выдает ошибку: «Не удалось подключиться к шине: нет такого файла или каталога» .

Во время моих попыток я пытался:

  1. Назначьте возможности CAP_SYS_ADMIN контейнеру;
  2. Выполните двоичный файл «/ sbin / init» при запуске контейнера и получил ошибку: «Не удалось найти альтернативную реализацию telinit для spawn». ;
  3. Файл инициализации является символической ссылкой на «/ lib / systemd / systemd», поэтому я также попытался использовать этот сценарий напрямую и также получил сообщение об ошибке: «Попытка запустить как пользовательский экземпляр, но система не была загружена с помощью systemd «. ,
0

2 ответа на вопрос

0
grawity

Сервисы systemd не работают автономно - вы можете запустить их, только если ваш pid 1 (init) - systemd. В контейнерах это требует использования пространства имен pid в дополнение к тому, что у вас уже есть.

(Другими словами, systemctl фактически не читать и выполнять эти .Service файлы на всех . - это только спрашивает PID 1, чтобы запустить соответствующий демон)

В общем, я бы сказал, что ваша установка RunC уже дублирует Systemd встроенный в особенности (ProtectHome =, CapabilityBoundingSet = и т.д.) Но если вы действительно хотите, чтобы запустить демон в специальном контейнере, у вас есть только два варианта:

  1. Запуск контейнера с новым пространством имен PID, с Systemd в качестве основного процесса, и есть, что Systemd экземпляр начать Avahi-демона. (systemd-nspawn может работать лучше, чем runC.)

  2. Сконфигурируйте контейнер для запуска / usr / bin / avahi-daemon напрямую, без участия файлов systemctl или avahi-daemon.service.

Хорошо, я попробую первый вариант (с выделенным пространством имен pid) и сообщу вам через 12 часов. Насчет nspawn, я с тобой абсолютно согласен, но мне приходится использовать runc. Alex Bidnichenko 6 лет назад 0
0
Alex Bidnichenko

Моя версия файла config.json для systemd в runc:

{ "ociVersion": "1.0.0-rc1", "platform": { "os": "linux", "arch": "arm" }, "process": { "terminal": false, "user": { "uid": 0, "gid": 0 }, "args": [ "/sbin/init" ], "env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "TERM=xterm" ], "cwd": "/", "capabilities": { "bounding": [ "CAP_KILL", "CAP_CHOWN", "CAP_SETGID", "CAP_SETUID", "CAP_NET_RAW", "CAP_MAC_ADMIN", "CAP_SYS_ADMIN", "CAP_SYS_CHROOT", "CAP_AUDIT_WRITE", "CAP_NET_BIND_SERVICE" ], "effective": [ "CAP_KILL", "CAP_CHOWN", "CAP_SETGID", "CAP_SETUID", "CAP_NET_RAW", "CAP_MAC_ADMIN", "CAP_SYS_ADMIN", "CAP_SYS_CHROOT", "CAP_AUDIT_WRITE", "CAP_NET_BIND_SERVICE" ], "inheritable": [ "CAP_KILL", "CAP_CHOWN", "CAP_SETGID", "CAP_SETUID", "CAP_NET_RAW", "CAP_MAC_ADMIN", "CAP_SYS_ADMIN", "CAP_SYS_CHROOT", "CAP_AUDIT_WRITE", "CAP_NET_BIND_SERVICE" ], "permitted": [ "CAP_KILL", "CAP_CHOWN", "CAP_SETGID", "CAP_SETUID", "CAP_NET_RAW", "CAP_MAC_ADMIN", "CAP_SYS_ADMIN", "CAP_SYS_CHROOT", "CAP_AUDIT_WRITE", "CAP_NET_BIND_SERVICE" ], "ambient": [ "CAP_KILL", "CAP_CHOWN", "CAP_SETGID", "CAP_SETUID", "CAP_NET_RAW", "CAP_MAC_ADMIN", "CAP_SYS_ADMIN", "CAP_SYS_CHROOT", "CAP_AUDIT_WRITE", "CAP_NET_BIND_SERVICE" ] }, "rlimits": [ { "type": "RLIMIT_NOFILE", "hard": 1024, "soft": 1024 } ], "noNewPrivileges": true }, "root": { "path": "rootfs", "readonly": false }, "hostname": "runc", "mounts": [ { "destination": "/proc", "type": "proc", "source": "proc", "options": [ "nosuid", "noexec", "nodev" ] }, { "destination": "/dev", "type": "tmpfs", "source": "tmpfs", "options": [ "nosuid", "strictatime", "mode=755" ] }, { "destination": "/dev/pts", "type": "devpts", "source": "devpts", "options": [ "nosuid", "noexec", "newinstance", "ptmxmode=0666", "mode=0620", "gid=5" ] }, { "destination": "/dev/shm", "type": "tmpfs", "source": "shm", "options": [ "nosuid", "noexec", "nodev", "mode=1777", "size=65536k" ] }, { "destination": "/dev/mqueue", "type": "mqueue", "source": "mqueue", "options": [ "nosuid", "noexec", "nodev" ] }, { "destination": "/sys", "type": "sysfs", "source": "sysfs", "options": [ "nosuid", "noexec", "nodev" ] }, { "destination": "/sys/fs/cgroup", "type": "bind", "source": "/sys/fs/cgroup", "options": [ "rbind", "ro" ] } ], "linux": { "resources": { "devices": [ { "allow": false, "access": "rwm" } ] }, "namespaces": [ { "type": "pid" }, { "type": "network" }, { "type": "ipc" }, { "type": "uts" }, { "type": "mount" } ], "maskedPaths": [ "/proc/kcore", "/proc/latency_stats", "/proc/timer_stats", "/proc/sched_debug" ], "readonlyPaths": [ "/proc/asound", "/proc/bus", "/proc/fs", "/proc/irq", "/proc/sys", "/proc/sysrq-trigger" ] } 

Похожие вопросы