Starten Sie den systemd-Dienst im OCI-Container (runc).

660
Alex Bidnichenko

Derzeit versuche ich, den systemd-Dienst (avahi-daemon) im RUNC-Container zu starten, und alle meine Versuche waren fehlgeschlagen. Ich hatte mehrere Artikel für dieselbe Aufgabe, aber für die Docker-Lösung und noch einen . Hat jemand eine erfolgreiche Erfahrung mit der gleichen Aufgabe?

Das ist meine 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" ] }

Diese Konfigurationsdatei gibt einen Fehler aus: "Verbindung zum Bus fehlgeschlagen: Keine solche Datei oder Verzeichnis" .

Während meiner Versuche habe ich versucht,

  1. Weisen Sie dem Container die Fähigkeiten CAP_SYS_ADMIN zu.
  2. Führen Sie beim Start des Containers die Binärdatei "/ sbin / init" aus. Es wurde ein Fehler angezeigt : "Es konnte keine alternative Telinit-Implementierung zum Spawn gefunden werden." ;
  3. Die init-Datei ist eine symbolische Verknüpfung zu "/ lib / systemd / systemd", daher habe ich auch versucht, dieses Skript direkt zu verwenden, und es wurde ein Fehler angezeigt : "Versuch, als Benutzerinstanz auszuführen, aber das System wurde nicht mit systemd gebootet . " .
0

2 Antworten auf die Frage

0
grawity

systemd-Dienste werden nicht eigenständig ausgeführt. Sie können sie nur starten, wenn PID 1 (init) systemd ist. In Containern erfordert dies die Verwendung eines PID-Namespaces zusätzlich zu dem, was Sie bereits haben.

(Mit anderen Worten, systemctl nicht wirklich lesen und ausführen, diese .service Dateien überhaupt -. Sie fragt 1 nur pid den entsprechenden Daemon zu starten)

Im Allgemeinen würde ich sagen, dass Ihr runC-Setup bereits die integrierten Funktionen von systemd dupliziert (ProtectHome =, CapabilityBoundingSet = usw.). Wenn Sie jedoch den Dämon in einem dedizierten Container ausführen möchten, haben Sie nur zwei Optionen:

  1. Führen Sie den Behälter mit einem neuen PID - Namensraum, mit systemd als Hauptprozess und hat, dass systemd Instanz avahi-Daemon starten. (systemd-nspawn funktioniert möglicherweise besser als runC.)

  2. Konfigurieren Sie den Container so, dass er / usr / bin / avahi-daemon direkt startet, ohne systemctl oder die avahi-daemon.service-Dateien zu verwenden.

Okay, ich werde den ersten Varian (mit dediziertem PID-Namespace) ausprobieren und Ihnen in 12 Stunden Bericht erstatten. In Bezug auf nspawn stimme ich dir absolut zu, aber ich muss runc verwenden. Alex Bidnichenko vor 6 Jahren 0
0
Alex Bidnichenko

Meine Version der Datei config.json für das systemd in 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" ] }

Verwandte Probleme