Re: Virtualisierungslösung
Hallo,
> > Eine weitere moeglichkeit is einfach ein container.
> > apt install debootstrap systemd-container
> > Das hat kein Overhead
>
> Na, es hat Overhead, vermutlich nicht weniger als Docker und LXC.
> Denn ich denke, diese Namespaces gibt es nicht für umsonst.
Alle drei genannten Lösungen haben Overhead. Dabei ist der Anteil von
Namespaces und Cgroups gering; auch "normale" Systemd Service Units
machen davon Gebrauch (z.B. hat der Apache Webserver, wenn er mit
Systemd gestartet wird, ein privates /tmp).
Bei LXC und anderen Betriebssystem-Containern besteht der Overhead darin,
dass im Normalfall der Container ein vollständiges Linux ist, in dem
auch z.B. Systemd, Cron, SSHD und Rsyslogd laufen.
In einem Anwendungscontainer (Docker, RKT etc.) läuft nur die Anwendung.
Dafür haben diese Lösungen Overhead durch die Filesystem-Layer (i.d.R.
realisiert mit overlayfs2 oder aufs).
Alle genannten Lösungen benötigen eine Netzwerkabstraktion, typischerweise
mit einer eigenen Bridge und dem TAP Device.
> Ich bevorzuge für unbekannte Dinge tatsächlich Systemd-nspawn, es kommt
> mir politisch korrekter vor als Docker.
Ist Systemd inzwischen politisch korrekt? ;-)
Im Ernst, Docker ist seit buster offiziell in Debian. Ich wüsste nicht, was
daran inkorrekt sein soll.
> Gibt es eigentlich noch das RKT-Projekt? Das schien mir vergleichbar mit
> der Abstraktion, die Docker für die Container bietet, aber etwas offener
> als Docker.
Jein. RKT ist zusammen mit CoreOS an Red Hat / IBM übergegangen. Die setzen
aber mehr auf ihr eigenes Produkt Podman. RKT hat auf Github seit einem
halben Jahr keinen Commit mehr. Ich würde es für neue Projekte nicht mehr
in Betracht ziehen.
https://github.com/rkt/rkt
Die Docker Community Edition ist vollständig offen. Sie besteht aber im Kern
aus dem Projekt Moby, was historisch gewachsen, aber etwas verwirrend ist.
https://github.com/docker/docker-ce
https://github.com/moby/moby
> Allerdings sei zu nspawn noch bemerkt, daß es nicht als
> Sicherheitslösung gedacht war/ist.
Das gilt für Docker, LXC etc. genauso. Wenn man eine Sandbox bauen will,
muss man selber Hand anlegen und hat mit seccomp, eBPF, Netfilter, AppArmor,
SElinux, Kata, gVisor, Wireguard u.v.a. reichlich Werkzeuge zur Verfügung.
Spätestens hier würde ich aber zu Kubernetes und Rancher übergehen, damit das
ganze noch halbwegs beherrschbar bleibt.
Gruß, Harald
Reply to: