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 [2023/06/11 13:39] – [Docker Einsatz] stserver:docker [2024/04/24 12:02] (aktuell) – podman st
Zeile 55: 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 449: 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 522: 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 wird, ist unklar. Mö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 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.
  
-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 =====