Docker IPv6 killt IPv6 SLAAC auf dem LXC host

Y

YoSiJo

Active Member
Aug 16, 2018
11
2
43
40
Ich habe seid einigen Tagen ein sehr interessantes Verhalten.
Sobald ich im Debain 13 (Trixie) LXC Container bei `docker.io` IPv6 aktiviere, kann der LXC Container kein SLAAC mehr beziehen.

Ich konnte schon durch Test Festellen, das wenn ich das gleiche mit Debian 12 (Bookworm) aktuell mache laufe ich in den bekannten net.ipv4.ip_unprivileged_port_start error
Fehler und kann den mit den Workarounds fixen, und habe dann auch meine IPv6 SLAAC IP im LXC Container wieder.

Da ich zudem schon einige Systeme die Wochen vorher mit Debian 13 (Trixie) aufgesetzt hatte und und denen auch Docker mit IPv6 eingerichtet hatte, ohne das es Probleme gab, werde ich das Gefühl nicht los, das hier, auch wenn gleich es ein ganz anderes Symptom ist, ein Zusammenhang besteht.

# Setup

## Server

Es sind mehrere Debian 12 mit Proxmox Nodes im Einsatz.
Storage ist Ceph via CephADM, und Proxmox verwaltet dieses nicht.
Die WAN Gateway macht SLAAC für das Provider Netzwerk und die LXC Container kommen via VLAN an dieses ran.
Aktuell sind grob 100 Container via LXC im Einsatz und davon ca. die Hälfte mit Docker intern und einer ULA für die default docker compose Bridge im Einsatz.

# Log

Code: 
Nov 11 23:21:58 autopulse systemd-networkd[209]: docker0: Link UP
Nov 11 23:21:58 autopulse info[159]: executing /bin/ip -6 addr show eth0
Nov 11 23:21:58 autopulse info[159]: executing /sbin/dhclient -6 -pf /run/dhclient6.eth0.pid -lf /var/lib/dhcp/dhclient6.eth0.leases eth0
Nov 11 23:21:58 autopulse dhclient[446]: Can't bind to dhcp address: Cannot assign requested address
Nov 11 23:21:58 autopulse dhclient[446]: Please make sure there is no other dhcp server
Nov 11 23:21:58 autopulse dhclient[446]: running and that there's no entry for dhcp or
Nov 11 23:21:58 autopulse dhclient[446]: bootp in /etc/inetd.conf.   Also make sure you
Nov 11 23:21:58 autopulse dhclient[446]: are not running HP JetAdmin software, which
Nov 11 23:21:58 autopulse dhclient[446]: includes a bootp server.
Nov 11 23:21:58 autopulse dhclient[446]:
Nov 11 23:21:58 autopulse dhclient[446]: If you think you have received this message due to a bug rather
Nov 11 23:21:58 autopulse networking[159]: error: eth0: cmd '/sbin/dhclient -6 -pf /run/dhclient6.eth0.pid -lf /var/lib/dhcp/dhclient6.eth0.leases eth0' failed: returned 1
Nov 11 23:21:58 autopulse dhclient[446]: than a configuration issue please read the section on submitting
Nov 11 23:21:58 autopulse dhclient[446]: bugs on either our web page at www.isc.org or in the README file
Nov 11 23:21:58 autopulse dhclient[446]: before submitting a bug.  These pages explain the proper
Nov 11 23:21:58 autopulse dhclient[446]: process and the information we find helpful for debugging.
Nov 11 23:21:58 autopulse dhclient[446]:
Nov 11 23:21:58 autopulse dhclient[446]: exiting.
Nov 11 23:21:58 autopulse error[159]: eth0: cmd '/sbin/dhclient -6 -pf /run/dhclient6.eth0.pid -lf /var/lib/dhcp/dhclient6.eth0.leases eth0' failed: returned 1
Nov 11 23:21:58 autopulse systemd[1]: Finished networking.service - Network initialization.


# Weitere anmerkungen

Ich kann das Problem auch mit den durch net.ipv4.ip_unprivileged_port_start error bekannten Workaround nicht beseitigen.
Sobald ich die IPv6 Configurationen für Docker wieder Entferne, ist das Problem nicht mehr gegeben:

Code: 
# cat /etc/docker/daemon.json 
{
        "ipv6": true,
        "fixed-cidr-v6": "2001:db8:1::/64",
        "registry-mirrors": ["https://mirror.gcr.io"]
}

Nur sollte jemand auf die Idee kommen: Ja, IPv6 in Docker ist ein Muss, eher könnte ich noch auf IPv4 Verzichten. ;)
 
Nein noch nicht und ich werde mal bei Zeit schauen das ich das Teste.
Ein Lösung bzw. Workaround ist es aber eh nicht für mich.
 
YoSiJo said:
Nein noch nicht und ich werde mal bei Zeit schauen das ich das Teste.
Ein Lösung bzw. Workaround ist es aber eh nicht für mich.
Click to expand...
Warum? Ich finde docker in lxcs zu betreiben extrem frickelig, zum einen muss man für Netzwerkfreigaben mit bind mounts o.ä. arbeiten, zum anderen geht das gerne mal nach Updates kaputt, einige Beispiele:
Meistens gab es dann irgendwann dann einen Bugfix oder einen (mehr oder weniger häßlichen) Workaround (meistens lief das auf das Deaktivieren von Sicherheitsmechanismen hinaus, so eine "Lösung" ist keine), womit es dann wieder geht. Sprich die Proxmox-Entwickler haben sich schon was dabei gedacht, warum sie das nicht unterstützen (siehe auch hier: https://forum.proxmox.com/threads/docker-integration.175870/post-815694 ), da muss man schon sehr gute Gründe haben, das nicht zu tun.

Dagegen sind docker-/podman-Container in einer VM deutlich stressfreier. Und wenn man alle docker/podman Container zusammen in einer schlanken VM betreibt, benötigt das auch nicht zwingend mehr Ressourcen als lxcs. Hier im Forum haben Leute von Docker VMs mit 1 oder 2 GB zugewiesenen RAM berichtet, die völlig problemlos laufen. Selbst ein gebrauchter Mini-PC dürfte das im Allgemeinen noch über haben. Im Vergleich zum RAM-Verbrauch eines Geräts, dass eh ständig angeschaltet ist, ist mir meine Lebenszeit zum Reparieren von nicht unterstützten Setups zu schade ;)

Wenn man (warum auch immer) lieber einen Linux-Container benutzen will, sollte man schauen ob die Anleitung der zu betreibenden Software beschreibt, wie man das ganze ohne docker zum Fliegen kriegt, bei pihole oder jellyfin klappt das zum Beispiel ganz gut.

Selbst wenn am Ende Anwendungen überbleiben, wo man wirklich docker in lxcs benutzen muss (weil die Entwickler z.B. keinen anderen Weg zur Verfügung stellen, man aber z.B gerne die IGPU mitnutzen möchte), halte ich es für ein kluges Vorgehen, dass dann wirklich nur für diese Anwendungen zu machen, dann gehen im Falle eines Falles nämlich nur die kaputt.
 
  • Like
Reactions: UdoB
Naja ich nutzte Docker eigentlich auch nur, wenn es halt keine nachhaltige oder gute Anleitung gibt.
Sind halt so inzwischen doch um die 20-30 LXC Container von 100 geworden.
Da ich der Einzige "Kunde" auf der Hardware bin, brauche ich nicht die Zusätzliche Isolierung, Unpreviligiere Container reichen mir hier aus.
Außerdem will ich ja garnicht das jede VM ihr eigenen FS Cacheing usw. macht, das soll die Hardware bitte gebündelt übernehmen.
Und Grob geschätzt, würde mein Resourcenverbrauch sich min. Verdoppeln, wenn nicht gar vervierfachen wenn ich alles auf VMs umstellen, worauf ich wirklich wenig Lust hätte.
 
You must log in or register to reply here.
Top Bottom