server:docker

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
server:docker [2022/03/10 17:11] – [Clustering] stserver:docker [2024/04/24 12:02] (aktuell) – podman st
Zeile 12: Zeile 12:
   * Docker zieht eine Abstraktionsebene ein, d.h. die darunterliegende Struktur (LAN, Storage, Distribution und Paketabhängigkeiten) muss bei der Anwendung nicht betrachtet werden. Überall lauffähig, nur die docker-version muss beachtet werden   * Docker zieht eine Abstraktionsebene ein, d.h. die darunterliegende Struktur (LAN, Storage, Distribution und Paketabhängigkeiten) muss bei der Anwendung nicht betrachtet werden. Überall lauffähig, nur die docker-version muss beachtet werden
   * Ressourceneinsatz (Massenhosting)   * Ressourceneinsatz (Massenhosting)
 +    * Disk: VM (Debian): ~500-800MB (je nach installierter Komponenten), Container: je nach Basisimage
 +    * Arbeitsspeicher
 +      * Kernel: VM: ~60MB je VM (incl. rsyslog), Container: kernel vom Betriebssystem wird genutzt
 +      * Applikationsprozess nimmt genauso viel
 +      * Cache: VM -> RAM muss reserviert werden, Virtualisierung kann aber ungenutzen Speicher neu verteilen; Container -> Cache kann gemeinsam von allen Containern benutzt werden  (auf dem gleichen Host)
   * Skalierbarkeit (Lastspitzen abfangen)   * Skalierbarkeit (Lastspitzen abfangen)
-  * Deployment kann schnell und oft erfolgen+  * Deployment kann schnell, häufig und stufenweise erfolgen
  
  
Zeile 50: Zeile 55:
   - cron (logging)   - cron (logging)
   - container bestehen nicht nur aus der app sondern auch die Laufzeit-umgebung: wer anderen Leuten docker-container baut ist auch für das environment (=die base-Images) verantwortlich!   - container bestehen nicht nur aus der app sondern auch die Laufzeit-umgebung: wer anderen Leuten docker-container baut ist auch für das environment (=die base-Images) verantwortlich!
-  - Alpine veröffentlich nur Daten zu bereits zu gefixten Problemen! Updategeschwindigkeit eher schlecht+  - Alpine veröffentlich nur Daten zu bereits zu gefixten Problemen! Updategeschwindigkeit eher schlecht: [[https://gitlab.alpinelinux.org/alpine/aports/-/issues?state=closed&label_name%5B%5D=tag%3Asecurity|Liste]] 
  
 siehe auch [[https://www.youtube.com/watch?v=RqhxphyVL88|DevOps Disasters]]. siehe auch [[https://www.youtube.com/watch?v=RqhxphyVL88|DevOps Disasters]].
Zeile 142: Zeile 147:
  
  
-==== Routingkonflikte mit docker networks ====+==== Routingkonflikte mit docker networks (IPv4) ====
  
-Netze die sich mit Docker überlappen (172.17., 172.18. ...) sind ein Problem.+Netze die sich mit Docker überlappen (172.17., ...) sind ein Problem.
 Die Config "bip": "10.4.0.1/16" in der /etc/docker/daemon.json funktioniert nur auf swarm korrekt. Die Config "bip": "10.4.0.1/16" in der /etc/docker/daemon.json funktioniert nur auf swarm korrekt.
  
Zeile 151: Zeile 156:
 Es gibt nur einen funktionierenden workaround: explizit eine route im System setzen: Es gibt nur einen funktionierenden workaround: explizit eine route im System setzen:
  
-Beispiel Redhat (ens192 mit Standard-GW 172.16.0.1) z.B. mit ''/etc/sysconfig/network-scripts/route-ens192'' (ip-Befehlssyntax)): <file>172.17.0.0/16 via 172.16.0.1 dev ens192</file>+Beispiel Redhat (ens192 mit Standard-GW 172.17.0.1) z.B. mit ''/etc/sysconfig/network-scripts/route-ens192'' (ip-Befehlssyntax)): <file>172.17.0.0/16 via 172.17.0.1 dev ens192</file>
  
 Bei Swarm muss initial die docker_gwbridge  angepasst werden - funktioniert nur wenn docker nicht bereits Teil eines swarm-clusters ist (er behält die Einstellungen bei wenn bereits vorhanden): Bei Swarm muss initial die docker_gwbridge  angepasst werden - funktioniert nur wenn docker nicht bereits Teil eines swarm-clusters ist (er behält die Einstellungen bei wenn bereits vorhanden):
Zeile 158: Zeile 163:
   - neu anlegen mit anderem Netz (muss vor join erfolgen!):<file>   - neu anlegen mit anderem Netz (muss vor join erfolgen!):<file>
 docker network create \ docker network create \
---subnet 172.18.0.0/16 \+--subnet 10.4.0.0/16 \
 --opt com.docker.network.bridge.name=docker_gwbridge \ --opt com.docker.network.bridge.name=docker_gwbridge \
 --opt com.docker.network.bridge.enable_icc=false \ --opt com.docker.network.bridge.enable_icc=false \
Zeile 444: Zeile 449:
   * [[https://docs.docker.com/storage/volumes/#backup-restore-or-migrate-data-volumes|Backup, restore, oder migrieren von data volumes]]   * [[https://docs.docker.com/storage/volumes/#backup-restore-or-migrate-data-volumes|Backup, restore, oder migrieren von data volumes]]
  
 +
 +
 +===== docker vs. podman=====
 +
 +
 +  * docker daemon immer noch als root (-> podman mit systemd unit + port >1024 expose)
 +  * podman -> restart polic via systemd-unit
 +  * ggf. rootless container in einen pod (namespace für ipc, net, cgroups) packen (teilen sich einen network namespace)
 +  * compose files nicht vorhanden, Alternativen:
 +    * https://github.com/containers/podman-compose
 +    * oder minikube, k3d, .k8s, ...
 +  * CNI vs. Netavark/Aardvark-stack (ab podman 4.0) https://www.redhat.com/sysadmin/podman-new-network-stack
 +    * Netavark: A network setup tool that configures network bridges, firewall rules, and system settings to give containers access to external networks
 +    * Aardvark: An authoritative DNS server for A and AAAA container records, enabling containers to resolve connections to other containers by their names or aliases.
 +
 +**networking**:
 +  - bridge (Standard für rootful container) -> internes Interface mit NAT
 +  - macvlan (bridge mit eigener mac + IP auf interface, erfordert rootful
 +  - slirp4netns (Standard für rootless containers) -> Tunnel durch TAP device (containers are completely isolated from each other! no virtual network
 +
 +v4/v6/dualstack: 
 +  - podman macht IPv4, v6 oder Dualstack (v4 + v6)
 +  - docker does ipv4 OR (ipv4 and ipv6), nur v6 geht nicht!
 +
 +==== Links ====
 +
 +  * https://github.com/containers/podman/blob/main/docs/tutorials/basic_networking.md/
 +  * https://www.redhat.com/sysadmin/container-networking-podman
 +  * https://developers.redhat.com/articles/2022/08/10/how-conifgure-podman-40-ipv6
  
  
Zeile 517: Zeile 551:
 ===== IPv6 ===== ===== IPv6 =====
  
-Docker hat beim Design Ipv6 nicht berücksichtigt und daher schlagen dessen Simplifizierungen (Expose durch NAT nach Außen und interne DNS-Auflösung) in Nachteile um. +Docker hat beim Design IPv6 nicht berücksichtigt und daher schlagen dessen Simplifizierungen (Ports durch NAT via iptables nach Außen geben und interne DNS-Auflösung) in Nachteile um. 
-Ob NAT (analog zu v4) jemals offiziell mit IPv6 umgesetzt wirdist unklarMöglich wäre es, dazu würden aus dem Unique Local Addresses (ULA)-Bereich fd00::/8 Adressen ausgewählt werden und per firewall nach außen genattet werden müssen.+**docker unterstützt kein SLAAC oder DHCPv6** und kann daher nicht selbstständig Präfixe beziehend.h. es müssen statische IPs zugewiesen werden und diese via DNS propagiert werden (DNS auf die öffentliche IP des docker-Hosts reicht nicht mehr!). 
 +Hiermit werden jedoch sämtliche Ports öffentlich zugänglich gemacht (nicht nur diese via EXPOSE) und müssen daher via firewall abgesichert werden.
  
-Alternativ kann intern ein öffentliches v6-Netz benutzt werden. Beispiel mit 2001:db8:1::/64: +NAT66 (analog zu v4) mit Adressen aus dem Unique Local Addresses (ULA)-Bereich fd00::/8 Adressen ist eine schlechte Idee und führt zu Problemen, auch der userland-proxy ist Mist. 
-/etc/docker/daemon.json + 
-<code bash>+Funktionierende Lösungen: 
 +  * ein öffentliches /64 v6-Netz mit manueller Zuweisungen von Adressen an Container. Beispiel mit 2001:db8:1::/64: ''/etc/docker/daemon.json'': <code bash>
 { {
   "ipv6": true,   "ipv6": true,
   "fixed-cidr-v6": "2001:db8:1::/64"   "fixed-cidr-v6": "2001:db8:1::/64"
-} +}</code> Quellen: https://docs.docker.com/network/drivers/macvlan/#use-ipv6
-</code>+
  
-Weiterhin unterstützt docker **kein SLAAC oder DHCPv6** und kann daher nicht selbstständig Präfixe beziehen, d.h. es müssen statische IPs zugewiesen werden und diese via DNS propagiert werden (DNS auf die öffentliche IP des docker-Hosts reicht nicht mehr!).  +  Container direct auf die Netzwerkkarte bridgen: [[https://docs.docker.com/network/drivers/macvlan/#use-ipv6|Macvlan]]
-Hiermit werden jedoch sämtliche Ports öffentlich zugänglich gemacht (nicht nur diese via EXPOSE) und müssen daher via firewall abgesichert werden.+
  
 Siehe auch: https://heikorichter.name/post/123/docker-und-ipv6/ Siehe auch: https://heikorichter.name/post/123/docker-und-ipv6/
  
 :!: Für IPv6-only ist dank der Rückständigkeit bei Dritten (Docker registry, Github etc.) Krücken wie DNS64 + NAT64 nötig. :!: Für IPv6-only ist dank der Rückständigkeit bei Dritten (Docker registry, Github etc.) Krücken wie DNS64 + NAT64 nötig.
- 
- 
 ===== Clustering ===== ===== Clustering =====