Select Page

Podman vs Docker

by | May 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
Support Engineer

Afeef hat seine Ausbildung Als Fachinformatiker in Richtung Systemintegration im Juli 2020 bei NETWAYS absolviert, seitdem unterstützt er die Kollegen im Support und bei der Betriebsunterstützung. Nach der Arbeit macht er gerne Sport, trifft Freunde oder mag es Filme zu schauen.
Mehr Beiträge zum Thema NETWAYS

NETWAYS stellt sich vor – Katja Kotschenreuther

Name: Katja Kotschenreuther Alter: 23 Ausbildung: Studium Business Administration & Economics Position bei NETWAYS: Online Marketing Manager Bei NETWAYS seit: Oktober 2020 Wie bist Du zu NETWAYS gekommen und was genau gehört zu Deinem Aufgabenbereich? Nach meinem...

Five Nextcloud Do’s and Don’ts

Five Nextcloud Do's and Don'ts Here are a five Do's and Don'ts you should consider when using Nextcloud. These are examples that have of course already happened a few times in the past. Do’s 1. When you activate an app, make sure you read the instructions first. Not...

Jitsi vs Zoom vs BigBlueButton

Because of Covid-19 there are a lot of precautions right now. Many companies are now forced to work remotely and this has caused a huge increase in digital work over the last few months. The classic office job naturally also includes meetings, which now have to take...

Monthly Snap September 2020

September is always an exciting month at the NETWAYS HQ since our new apprentices start then. It always feels like a fresh start, as you see the company and the office through fresh eyes. And within a few days it feels as if they have been here forever. Here`s what we...

Veranstaltungen

Tue 27

GitLab Training | Online

October 27 @ 09:00 - October 28 @ 17:00
Tue 27

Graylog Training | Online

October 27 @ 09:00 - October 28 @ 17:00
NETWAYS Headquarter | Nürnberg
Nov 04

Vorstellung der Monitoring Lösung Icinga 2

November 4 @ 10:30 - 11:30
NETWAYS Headquarter | Nürnberg
Nov 24

Elastic Stack Training | Online

November 24 @ 09:00 - November 26 @ 17:00
Dec 01

Foreman Training | Nürnberg

December 1 @ 09:00 - December 2 @ 17:00
NETWAYS Headquarter | Nürnberg