Erste Schritte mit podman unter Arch Linux und Manjaro

Die Welt der Container-Technologien ändert sich rasant, daher ist es oft schwierig am Ball zu bleiben. Aber wie schon Charles Darwin meinte, ist das einzig Beständige der Wandel.

In diesem Beitrag soll es darum gehen, wie man Container mit Hilfe von Podman per systemd bei jedem Booten startet, um auf Docker verzichten zu können.

Einer der großen Vorteile von Docker ist nämlich der Docker-Daemon, der sich darum kümmert, dass Container, die als Daemon gestartet wurden, nach dem Reboot des Hostsystems wieder automatisch hochgefahren werden.

Allerdings ist dieser große Vorteil von Docker gleichzeitig auch eine seiner größten Schwächen, da man auf diesem Daemon angewiesen ist, und dieser mit root Rechten auf dem Hostsystem läuft.

Podman ist angetreten die Nachfolge für Docker zu übernehmen, um die Nachteile zu überwinden und gleichzeitig eine bessere Unterstützung für die Orchestrierung mit Kubernetes zu ermöglichen (hier eine möglich Ursache, warum Red Hat sich entschieden hat, podman zu unterstützen). Daher wäre es hilfreich, wenn man mit podman auch Container starten könnte, die einen Reboot des Hosts überleben.

Podman installieren

Für meine Tests verwende ich Arch Linux (weil das das System meiner Wahl ist) und Manjaro in einer VM. In den Arch Community Repositories ist podman bereits verfügbar

sudo pacman -S podman podman-docker

Nach der Installation prüft man mit folgendem Befehl, ob alles soweit funktioniert:

podman version

Unter Arch Linux wird dieser Befehl vermutlich folgenden Fehler ausgeben:

ERRO[0000] cannot find mappings for user andreas: open /etc/subuid: no such file or directory

Der Grund für diesen Fehler ist eine fehlende Konfiguration der Subordinate Users/Groups in Arch.

Einrichten der Subordinate User/Groups

Podman muss zum Betrieb von Containern neue temporäre Benutzer/Gruppen anlegen, die dem Benutzer, der den Container gestartet hat, untergeordnet sind. Alle diese neuen Benutzer verfügen also über die selben Berechtigungen, wie der Hauptbenutzer.

Die Konfiguration erfolgt in zwei Dateien (/etc/subuid für Benutzer und /etc/subgid für Gruppen), die beide demselben Schema folgen. Genauere Details zu diesen Dateien, kann den man-pages entnommen werden.

andreas:10000:70000

In der ersten Spalte wird der Benutzer angegeben, der Subordinates anlegen darf (hier im Beispiel: andreas). In der zweiten Spalte wird die erste UID angegeben (hier im Beispiel 10000). In der letzten Spalte folgt dann noch die Anzahl, wie viele Subordinates der Benutzer anlegen kann (hier im Beispiel 70000)

andreas:10000:70000

Analog muss die Datei /etc/subgid die Daten zu den Subordinate Gruppen enthalten.

Installieren eines nginx-Container vom docker-hub

Als einfaches Beispiel will ich einen nginx-Container ausführen, der eine statische HTML Seite anzeigt.

Dazu lege ich im Home-Verzeichnis ein neues Verzeichnis mit dem Namen nginx an:

cd ~
mkdir nginx

In diesem Verzeichnis muss dann lediglich eine HTML Datei mit dem Namen index.html erzeugt werden. Für mein kleines Beispiel, habe ich folgende Datei erzeugt:

<html>
<head><title>Podman</title></head>
<body>
Hallo <strong>podman</string>
</body>
</html>

Anschließend hole ich das aktuellste Image für nginx aus dem Docker-Hub:

podman pull nginx
podman run -d -p 8080:80 -v ~/nginx:/usr/share/nginx/html:ro –name nginx nginx

Die Parameter des podman run Befehls:

Parameter Beschreibung
-d

Startet den Container im Hintergrund

-p Bildet den lokalen Port 8080 auf den internen Container Port 80 ab
-v Bildet das lokale Verzeichnis ~/nginx auf das Container-Verzeichnis /usr/share/nginx/html als Readonly (ro) ab
–name Gibt dem Container einen eindeutigen Namen. Dies ist notwendig, damit wir im Anschluss einfacher auf den Container verweisen können, ohne die Container-ID direkt verwenden zu müssen

Nachdem der Container so gestartet wurde, kann mit dem Browser auf http://localhost:8080 die index.html angesehen werden.

Container als System-Dienst

Im Gegensatz zu docker, überlebt der mit podman gestartete Container allerdings keinen Neustart des Hosts.

Aber gemäß der Unix-Philosophie ist es vernünftig diese Aufgabe jenen zu überlassen, die dafür vorgesehen sind. Im Falle von Arch Linux ist das systemd

Podman kann eine systemd Unit Datei erzeugen, indem man folgenden Befehl ausführt:

podman generate systemd --restart-policy=always --name nginx > nginx/nginx.service

Der Befehl gibt das Ergebnis auf stdout aus, daher leiten wir das Ergebnis in eine Datei um (nginx/nginx.service)

# container-nginx.service
# autogenerated by Podman 1.6.2
# Sun Dec  8 13:20:59 CET 2019

[Unit]
Description=Podman container-nginx.service
Documentation=man:podman-generate-systemd(1)

[Service]
Restart=always
ExecStart=/usr/bin/podman start nginx
ExecStop=/usr/bin/podman stop -t 10 nginx
KillMode=none
Type=forking
PIDFile=/run/user/1000/vfs-containers/5d907eae25e449f06b28c3bae0a61ff1ad1bd4870811af20599569980dc0d1b9/userdata/conmon.pid

[Install]
WantedBy=multi-user.target

Diese generierte Datei funktioniert zumindest auf meinen getesteten Systemen überhaupt nicht. Nach der Installation kam es zu diversen Fehler, dass der Dienst nicht gestartet werden kann. Nach ein paar Experimenten und der Lektüre eines Artikels zum Aufsetzen eines rootless Containers, habe ich die Unit-Datei wie folgt angepasst:

[Unit]
Description=Podman container-nginx.service
Documentation=man:podman-generate-systemd(1)

Requires=user@1000.service
After=user@1000.service

[Service]
User=andreas
Group=andreas
Restart=always
ExecStart=/usr/bin/podman start nginx
ExecStop=/usr/bin/podman stop -t 10 nginx

KillMode=none
Type=forking

[Install]
WantedBy=multi-user.target

Änderungen an der Unit-Datei

  • [Unit]

    • Requires=user@1000.service

    • After=user@1000.service

  • [Service]

    • User=andreas

    • Group=andreas

    • Entfernen der Variable PIDFile

Alle Änderungen an der Unit Datei dienen dem Zweck, den Dienst als Benutzer (hier im Beispiel: andreas) auszuführen.

Nachdem diese Anpassungen vorgenommen wurden, kann der Dienst installiert und gestartet werden:

sudo cp nginx/nginx.service /etc/systemd/system
sudo systemctl enable nginx.service
sudo systemctl start nginx.service

Post to Twitter

Veröffentlicht unter Allgemein | Verschlagwortet mit , , , , , | Schreib einen Kommentar

Chrome 20 und der Flashplayer Fullscreen Mode bei NVidia TwinView Dual Screen unter Linux

Was für eine Überschrift! Dass Adobes Flashplayer nicht besonders gut ist, dürfte jedem Linux-Benutzer schon aufgefallen sein. Nun hat auch Adobe das erkannt und die Konsequenzen gezogen: Flash für Linux wird es einfach nicht mehr geben. Google bietet jedoch den Flashplayer seit der Version 20 ihres Browsers Chrome selbst an.

Wenn man nun eine NVidia Grafikkarte mit zwei Monitoren mit TwinView betreibt (meines Wissens nach die einzige sinnvolle Lösung), dann gab es schon immer Probleme bei manchen Videos im Fullscreen. Das Problem ist alt, und auf dieser Seite hervorragend beschrieben. Es gibt sogar einen Workaround, den ich aber bisher noch nicht angewandt habe, da er mir zu aufwendig ist.

Seit gestern aber ist der Flashplayer in Chrome integriert und zeigt im Fullscreen ein ganz neues Verhalten. Jetzt werden Videos nicht mehr auf die doppelte Größe aufgeblasen und dann in die Größe eines Monitors skaliert, sondern sie erhalten die Größe der Auflösung beider Monitore, werden aber nur auf einem Monitor angezeigt. Das führt dazu, dass die Videos nur zur Hälfte (oder sogar weniger) dargestellt werden. Das ist ja noch schlechter als die Verkleinerung.

Aber immerhin kann man wieder auf das „alte“ Problem wechseln, das einem zumindest erlaubt hat, das ganze Video zu sehen. Wenn man den Adobe Flashplayer noch installiert hat, kann man diesen verwenden, statt den integrierten Flashplayer von Chrome. Wie das geht, ist auf den Hilfeseiten von Google beschrieben: Adobe Flash Player-Plug-in

  1. Auf die Seite chrome:plugins wechseln
  2. Auf Details klicken (um die beiden Flash-Plugins) zu sehen
  3. Den integrierten Flashplayer (/opt/google/chrome/PepperFlash/libpepflashplayer.so) deaktivieren

Ab nun sollte dann wieder der Adobe Flashplayer verwendet werden, und man hat wieder die alten Probleme, statt der neuen.

Adobe Flash Player-Plug-in

Post to Twitter

Veröffentlicht unter linux | Schreib einen Kommentar

KDE: Join the game

Seit heute bin ich nun ein KDE Supporting Member. Eigentlich wollte ich das ja schon letztes Jahr machen, aber irgendwie ist damals etwas bei der Registrierung schief gelaufen. Aber heute hat es dann endlich geklappt, und nun unterstütze ich KDE mit einem Jahresbeitrag von 100€

Wenn du auch KDE finanziell unterstützen möchtest, kannst du hier am Spiel teilnehmen!

Post to Twitter

Veröffentlicht unter KDE, Open Source | Schreib einen Kommentar