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
Letzte ÜberarbeitungBeide Seiten der Revision
server:docker [2021/02/01 14:10] – [Welche Software ist geeignet?] stserver:docker [2024/04/24 12:00] – [Was sind Probleme die gelöst werden müssen?] 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]].
 ===== Einrichtung ===== ===== Einrichtung =====
  
Zeile 141: 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 150: 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 157: 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 514: Zeile 520:
  
  
 +===== IPv6 =====
 +
 +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.
 +**docker unterstützt 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!).
 +Hiermit werden jedoch sämtliche Ports öffentlich zugänglich gemacht (nicht nur diese via EXPOSE) und müssen daher via firewall abgesichert werden.
 +
 +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.
 +
 +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,
 +  "fixed-cidr-v6": "2001:db8:1::/64"
 +}</code> Quellen: https://docs.docker.com/network/drivers/macvlan/#use-ipv6
 +
 +  * Container direct auf die Netzwerkkarte bridgen: [[https://docs.docker.com/network/drivers/macvlan/#use-ipv6|Macvlan]]
 +
 +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.
 ===== Clustering ===== ===== Clustering =====