Seite wählen

Podman vs Docker

von | Mai 31, 2019 | NETWAYS

Als ich über Podman las, habe ich mir immer die Frage gestellt, wieso hat Redhat ihr eigenes Projekt gestartet, das im Grunde wie Docker ist, anstatt Pull Requests mit Verbesserungen an das Docker Projekt zu schicken? Die Antwort erhielt ich mit der Geschichte von Skopeo.

Skopeo :

Skopeo ist die Inspiration und der Anfang von Podman. Skopeo bedeutet „Remote-Suchen“ in der griechischen Sprache. Das Redhat-Team hat sich gefragt, wieso zuerst ein Image mit hunderten von MB von der Registery heruntergeladen werden muss, um nachschauen zu können, ob man das gewollte Image hat? Wenn ja, behält man es und wenn nein, schmeißt man es weg. Aufgrund dessen hat Redhat ein Pull Request an das Docker-Project geschickt. Das Docker-Team sich geweigert die Pull Request anzunehmen und hat gemeint, das schadet der API und dem CLI von Docker. Deshalb hat das Redhat-Team sein eigenes Tool entwickelt. So kamen Skopeo und die nachträglichen Gedanken vom Podman-Project zur Welt. Skopeo bot am Anfang die Möglichkeit die JSON Datei von einem Image herunterzuladen. Scopeo kann mittlerweile folgendes: Images pullen, pushen, kopieren zwischen Registeries ohne dazwischen lokal pullen zu müssen. Alles passiert ohne Root-Rechte.

$ mkdir fedora-24
$ skopeo copy docker://fedora:24 dir:fedora-24
$ tree fedora-24
fedora-24
├── 7c91a140e7a1025c3bc3aace4c80c0d9933ac4ee24b8630a6b0b5d8b9ce6b9d4.tar
├── f9873d530588316311ac1d3d15e95487b947f5d8b560e72bdd6eb73a7831b2c4.tar
└── manifest.json

Woher kommt der Name

Der Name Podman ist ein Kürzel für Pod Manager. Die Container-Orchestrierung Kubernetes hat den Begriff Pod geprägt. Er beschreibt eine Gruppe von Containern, die sich bestimmte Ressourcen teilen und nicht völlig isoliert voneinander laufen. Während Docker Pods nur indirekt über Kubernetes unterstützt wird, sind sie ein integraler Bestandteil von Podman. Eine Gruppe von – bedeutet „pod“, deshalb hat sich Redhat für drei Robben als Logo für Podman entschieden.

Ein Infra-Container verrichtet keine Arbeit, sorgt aber dafür, dass bestimmte Ressourcen des Pods wie Namespaces, CGroups und Netzwerk-Ports am Leben bleiben. Obwohl Podman dem Fork-Exec-Modell folgt und damit nicht als Server läuft, benötigen wir dennoch einen Prozess, der Container überwacht, um etwa Logs- und Exit-Codes zu sichern. Dies ist die Aufgabe von Conmon, ein kleines, in C geschriebenes Monitoring-Werkzeug, dass jedem Container angehängt wird. Neben dem Monitoring hält Conmon das Terminal des Containers offen, um per podman exec zu einem späteren Zeitpunkt das Terminal verwenden zu können.

Aus der Grafik ist ebenfalls die runc zu entnehmen. Runc ist für die Ausführung eines Container-Prozesses zuständig und implementiert die Runtime-Spezifikation der OCI (Open Containers Initiative). Redhat, IBM, Google, Microsoft, Docker und andere Unternehmen haben sich 2015 ausgetauscht und definiert “ was ein Image eines Containers bedeutet und wie dies ausschauen soll“. Den Konsens haben sie als Standards für den Image-Aufbau für die Industrie genommen und OCI (Open Containers Initiative) genannt.

# yum install podman
$ sudo podman pod create --name podtest
$ sudo podman pod ps
$ sudo podman create --pod podtest -d fedora sleep 600
$ sudo podman create --pod podtest -d fedora  sleep 600
$ sudo podman ps
CONTAINER ID  IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES

$ sudo podman pod start podtest
$ sudo podman ps -ap
CONTAINER ID  IMAGE                            COMMAND    CREATED        STATUS             PORTS  NAMES               POD
5f41beccf4d7  docker.io/library/fedora:latest  sleep 600  3 minutes ago  Up 34 seconds ago         awesome_sinoussi    74b9151c37cc
657ce4a71207  docker.io/library/fedora:latest  sleep 600  3 minutes ago  Up 34 seconds ago         romantic_bell       74b9151c37cc
f0d8ce498347  k8s.gcr.io/pause:3.1                        3 minutes ago  Up 3 minutes ago          74b9151c37cc-infra  74b9151c37cc
## Löschen
$ sudo podman stop Container1 Container2 .....
$ sudo podman rm Container1 Container2 .....
$ sudo podman rm podtest

Wie unterscheidet sich Podman von Docker ?

 01- Mehr Sicherheit mit rootless-Feature:

Der Container kann ohne root-Rechte ausgeführt werden, allerdings werden Befehle innerhalb des Containers vom root-Benutzer gesteuert. Das heißt im Endeffekt, einem Benutzer bzw. Entwickler müssen keine root-Rechte vergeben werden,um ein Container starten oder ein Image aufbauen zu können. Das schützt den Host vor Angriffen. Ohne dies können Angriffe durch Ausführen der Container-Images gelingen. Es könnte aus dem Container ausgebrochen und beliebiger Code auf dem Host als Root-Benutzer ausgeführt werden.

$ sudo podman pull docker.io/library/alpine:latest
$ sudo podman run -d alpine top
$ sudo podman exec b53c74f9d2d7 ps -ef
PID   USER     TIME  COMMAND
    1 root      0:00 top
   35 root      0:00 ps -ef
$ ps -ef | grep top
root      3859  3850  0 10:05 ?        00:00:00 top
training  4514  3551  0 10:30 pts/0    00:00:00 grep --color=auto top

02- Podman folgt dem Ausführenden einer Aktion nach dem Fork-Exec-Modell ,Docker jedoch nicht

Bei Podman bleibt die UID das Gleiche auch innerhalb des Containers. Dies ermöglicht dem Benutzer zu folgen.

[training@agent ~]$ cat /proc/self/loginuid
1000
[training@agent ~]$ sudo -i
[root@agent ~]# cat /proc/self/loginuid
1000						 
[training@agent ~]$ sudo podman run -ti fedora bash -c "cat /proc/self/loginuid; echo"
1000
[training@agent ~]$ sudo docker run -ti fedora bash -c "cat /proc/self/loginuid; echo"
4294967295                                  
[training@agent ~]$ sudo auditctl -w /etc/shadow      
[training@agent ~]$ sudo podman run --privileged -v /:/host fedora touch /host/etc/shadow
[training@agent ~]$ sudo ausearch -m path -ts recent -i | grep touch | grep --color=auto 'auid=[^ ]*'
type=SYSCALL msg=audit(05/23/2019 08:46:33.174:1189) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7ffd3963ef3a 
a2=O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK a3=0x1b6 items=2 ppid=15917 pid=15926 auid=training uid=root gid=root euid=root suid=root
fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=21 comm=touch exe=/usr/bin/touch subj=unconfined_u:system_r:spc_t:s0 key=(null)

[training@agent ~]$ sudo docker run --privileged -v /:/host fedora touch /host/etc/shadow
[training@agent ~]$ sudo ausearch -m path -ts recent -i | grep touch | grep --color=auto 'auid=[^ ]*'
type=SYSCALL msg=audit(05/23/2019 08:55:51.905:1224) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7ffe3699ef56
a2=O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK a3=0x1b6 items=2 ppid=16023 pid=16036 auid=unset uid=root gid=root euid=root suid=root
fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=touch exe=/usr/bin/touch subj=system_u:system_r:spc_t:s0 key=(null) 

Fazit: Wenn ein Benutzer mit Sudo-Rechten irgendetwas auf dem System macht, wird dies vom auditd-System aufgezeichnet. Mit einem Zugang zu Docker-Socket, ist dies nicht der Fall.

03- Steuerung und Struktur:

Auf der Docker-Seite: In der Tat wird alles von daemon gemanaged z.B registries, images, containers, und kernel. Das Docker command-line interface (CLI) schickt die Befehle zum daemon zur Bearbeitung und bekommt eine Antwort zurück.

Von dem Modell können wir entnehmen, dass wenn ein Fehler den Daemon trifft, funktioniert Docker nicht mehr plus es wird verwaiste Prozesse hinterlassen.

Von Podman Seite: Alles wird von runc gesteuert anstatt vom daemon, welcher oben schon erklärt ist

 

04 – Integration mit systemd

  • Podman kann Sytemd innerhalb des Containers zum laufen bringen
  • Unterstützt sd_notify
  • Socket aktivation

Remote Api für Podman

  • Unterstützt Varlink
  • Socket aktivation für den podman-API
[Unit]
Description=Podman Remote Api Service
Requires=io.podman.socket
After=io.podman.socket
Documentation=man:podman-varlink(1)

[Service]
Type=simple
ExecStart=/usr/bin/podman varlink unix:/run/podman/io.podman

[Install]
WantedBy=multi-user.target
Also=io.podman.socket

 

Afeef Ghannam
Afeef Ghannam
Systems Engineer

Afeef hat seine Ausbildung Als Fachinformatiker in Richtung Systemintegration im Juli 2020 bei NETWAYS absolviert, seitdem unterstützt er die Kolleg:innen im Operations Team der NETWAYS Professional Services bei der Betriebsunterstützung. Nach der Arbeit macht er gerne Sport, trifft Freunde oder mag es Filme zu schauen.

3 Kommentare

  1. Jonas

    Alle Grafiken liegen auf wiki.netways.de und sind durch eine Authentifizierung geschützt („protected-area“). Das ist wirklich sehr schade.

    Antworten
  2. Schmid

    Inhaltlich guter Artikel, aber bitte Rechtschreibprüfung drüber laufen lassen.

    Antworten
    • Afeef Ghannm

      Ich werde mich bemühen, nächstes mal ohne Fehler zu veröffentlichen. Danke für den Hinweis.

      Antworten

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mehr Beiträge zum Thema NETWAYS

Monthly Snap Februar 2024

Der Februar war ein ereignisreicher Monat bei NETWAYS! Neben dem normalen Alltag gab es auch unser Jahresmeeting, ein Spieleabend im Büro, und viele Kollegen waren auf Konferenzen und der Jobmesse in Nürnberg unterwegs. Und natürlich wurden viele Blogposts zu...