Zum Hauptinhalt springen

Managed Service Podman

Podman ist eine "daemonless" Container Engine um OCI Containers auf ihrem Linux System zu entwickeln, administrieren und betreiben. Die Container laufen im Kontext des Systembenutzers www-data und sind daher komplett unabhängig vom Root Benutzer.

Der Syntax von Podman ist grösstenteils identisch zu Docker, daher kann bei Bedarf der folgende Bash-Alias genutzt werden, um Docker-Befehle via podman zu starten:

alias docker=podman

Bitte beachten Sie dabei: In Zukunft kann sich der Syntax von Podman verändern und wird eventuell nicht mehr identisch sein mit dem von Docker.

Die komplette Dokumentation des Podman Projektes findet sich hier:

https://podman.readthedocs.io/en/latest/index.html

Die Hilfe und Manual Pages sind wie folgt einsehbar:

podman --help
podman <subcommand> --help

man podman
man podman-<subcommand>

Cleanup-Jobs​

Standardmässig erstellen wir bei der Installation von Podman zwei Cleanup-Jobs. Einer läuft jeweils in der Nacht von Sonntag auf Montag und löscht alle unbenutzten Images. Der Zweite läuft immer in der Nacht zum 1. des Monats und löscht alle unbenutzten Volumes.

Dies sind Sicherheitsmassnahmen, um den Platzbedarf von Podman so gering wie möglich zu halten und so Risiko zu vermindern, dass Ihre Festplatte vollläuft. Wenn Sie diese beiden Cleanup-Jobs ändern möchten, können Sie uns gerne ein Ticket schreiben und wir werden diese gemäss Ihren Bedürfnissen konfigurieren.

Images und Registries​

Suchen nach bestehenden Images auf den gängigen Container Registries:

podman search <search_term>

Filtern nach offiziellen Images:

podman search ghost --filter=is-official

Ein Image lokal verfügbar machen:

podman pull docker.io/library/ghost

Lokal vorhandene Images anzeigen:

podman images
note

Podman sucht in unterschiedlichen Registries. Damit sicherlich das richtige Image verwendet wird, sollte jeweils der vollständigen Image-Namen angegeben werden (z.B.: docker.io/library/ghost anstatt ghost).

Container starten​

In diesem Beispiel starten wir einen Ghost Container, welcher ein simples CMS zur Verfügung stellt.

podman run -dt -p 8080:2368/tcp docker.io/library/ghost
note

Der Container wird im detached mode gestartet, nach dem Start des Containers wird uns die Container ID am Prompt ausgegeben. Die Option -t bewirkt, dass ein Pseudo-TTY kreiert wird, welches uns erlaubt auf eine interaktive Shell zu verbinden.

Port Forwarding/Publishing wird verwendet mit der Option -p 8080:2368/tcp, damit das CMS Ghost über den TCP Port 8080 auf dem Host System erreichbar ist.

Container Übersicht​

Die Übersicht über laufende Container wird mit dem Befehl podman ps -a angezeigt.

$ podman ps -a

CONTAINER ID  IMAGE                           COMMAND               CREATED      STATUS          PORTS                   NAMES
5728ad900bc4  docker.io/library/ghost:latest  node current/inde...  4 hours ago  Up 4 hours ago  0.0.0.0:8080->2368/tcp  gifted_edison

Container verbinden​

Wir können uns mit dem Container über die Container ID verbinden. Die Container ID ist einsehbar über die Ausgabe von podman ps.

$ podman attach b3376ff455a0

[2020-06-10 09:17:15] INFO "GET /" 200 512ms

Container Funktionstest​

Der Ghost CMS Container ist nun erreichbar über den TCP Port 8080 auf dem Hostsystem.

Mittels einem einfacher curl Aufruf kann geprüft werden, ob das CMS im Container läuft:

$ curl localhost:8080| grep "og:site"

    <meta property="og:site_name" content="Ghost" />

Container mit nine-manage-vhosts veröffentlichen​

Die Managed Services Nginx und Apache2 ermöglichen es uns, die Container Applikation mittels nine-manage-vhosts gegenüber dem Internet zu veröffentlichen. Zudem kann damit auch eine Verschlüsselung mittels Let's Encrypt-Zertifikaten vorgenommen werden.

Neuen vHost erstellen:

sudo nine-manage-vhosts virtual-host create testdomain.org --template=proxy --template-variable=PROXYPORT=8080

Let's Encrypt Registrierung vornehmen:

sudo nine-manage-vhosts certificate register-client  --contact-email=contact@yourcompany.org

Neues Let's Encrypt Zertifikat erstellen und auf dem vHost anwenden:

sudo nine-manage-vhosts certificate create --virtual-host=testdomain.org
sudo nine-manage-vhosts virtual-host update testdomain.org --template=proxy_letsencrypt_https --template-variable=PROXYPORT=8080

Nur in Kombination mit dem Apache Webserver notwendig: Um einen automatischen Redirect von http nach https zu erzeugen, können Sie das Template proxy_letsencrypt_https_redirect verwenden.

docker-compose​

Ab Ubuntu 22.04 unterstützt Podman docker-compose nativ und Ihre Installation beinhaltet docker-compose v1.

Installieren Sie die neueste v2 Version von docker-compose.
mkdir -p ~/bin
curl -L $(curl -s https://api.github.com/repos/docker/compose/releases/latest | jq -r '.assets[] | select(.name == "docker-compose-linux-x86_64") | .browser_download_url') -o ~/bin/docker-compose
chmod +x ~/bin/docker-compose

Wenn Sie Podman unter Ubuntu 20.04 verwenden, können Sie das native docker-compose nicht nutzen. Sie können jedoch podman-compose verwenden, das das Verhalten nachbildet:

podman-compose
mkdir -p ~/bin
curl -o ~/bin/podman-compose https://raw.githubusercontent.com/containers/podman-compose/main/podman_compose.py
chmod +x ~/bin/podman-compose
ln -s ~/bin/podman-compose ~/bin/docker-compose # compatibility for the docker-compose command

Beispiel-Konfiguration für docker-compose​

In diesem Beispiel lassen wir unser Ghost CMS mittels einer compose-Datei im Netzwerkmodus slirp4netns laufen. slirp4netns ist Podmans Netwerkstandard und muss nicht explizit angegeben werden. Für die Datenbankanbindung greifen wir auf eine bereits existierende, lokal betriebene MySQL-Datenbank mit dem Namen nmd_ghost zu.

Der Inhalt der docker-compose.yaml Datei:

# Standardmässig nutzt das Ghost Image eine SQLite DB und benötigt daher kein separater Datenbank-Container.
# Die verwendeung der MySQL-Datebank dient hier lediglich als Beispiel,

services:
  ghost:
    image: ghost:3-alpine
    restart: always
    ports:
      - 8080:2368
    environment:
      # see https://docs.ghost.org/docs/config#section-running-ghost-with-config-env-variables
      database__client: mysql
      database__connection__host: localhost
      database__connection__user: nmd_ghost
      database__connection__password: EeNae5xaoapoh5RoDah1muwu
      database__connection__database: nmd_ghost
      # this url value is just an example, and is likely wrong for your environment!
      url: http://testdomain.org

Diese docker-compose.yaml Datei wird nun mit dem docker-compose Befehl verwendet:

docker-compose -f docker-compose.yml up

Container mit dem System automatisch starten​

Wir empfehlen, Systemd User Services zu erstellen, damit Ihre Container automatisch nach einem System-Neustart gestartet werden.

Dazu generieren wir die Unit Files des Pods mit dem Namen examplepod:

podman generate systemd --new --files --name examplepod

HINWEIS: Mittels podman ps und podman pod ps können sie die Namen ihrer Pods und Container einsehen.

Als Nächstes kopieren wir die vorher generierten Service-Dateien in unsere systemd-Verzeichnis:

cp -pv /home/www-data/pod-examplepod.service /home/www-data/container-examplepod_ghost_1.service ~/.config/systemd/user/

Un zum Anschluss aktivieren wir die entsprechenden Services:

systemctl --user enable container-examplepod_ghost_1.service
systemctl --user enable pod-examplepod.service

Netzwerk​

Modus (Host, Bridged)​

Im standardmässig aktivierten Bridged Modus, teilen alle Container im selben Pod den gleichen Netzwerkbereich. Deshalb besitzen alle Container dieselbe IP, MAC Adresse und Port Mappings.

Die Netzwerkkommunikation zwischen den Containern in einem Pod kann hergestellt werden über den localhost.

Es gibt einen zweiten Modus, den sogenannten Host Modus. Dieser kann spezifiziert werden mit dem Parameter network=host.

Im Host-Modus ist der Netzwerkbereich nicht isoliert vom Container-Hostsystem. Der startende Container bekommt keine eigene IP-Adresse zugewiesen. Es ist daher möglich, auf jegliche lokalen Dienste wie z.B. einen MySQL Server auf ihrem Managed Server zu verbinden. Sämtliche lokal laufenden Dienste sind somit aus dem Container heraus erreichbar.

Rootless​

Alle unsere Container starten wir rootless, das Netzwerk wird somit automatisch konfiguriert.

Port Zuweisung​

Nur sogenannte "höhere Ports" können einem rootless Container zugewiesen werden. Alle Ports unter 1024 sind privilegiert und können für die Zuweisung nicht verwendet werden.

Anstatt dass wir den Container auf Port 80 starten, wechseln wir auf einen höheren Port. In diesem Beispiel, ein Ghost Container der auf den Port 2368 hört, veröffentlichen wir mit dem Port 8080 auf dem localhost.

$ podman run -dt -p 8080:2368/tcp docker.io/library/ghost

Mit dem Parameter podman -P kann die Port-Zuweisung automatisch durch Podman getriggert werden.

Überprüfung der verwendeten Ports:

$ podman port -a

c0194f22266c    2368/tcp -> 0.0.0.0:8080

Kommunikation von Container zu Container​

Die Kommunikation zwischen zwei rootless Containern kann über mehrere Wege stattfinden. Am einfachsten ist es aber, die zugewiesenen Ports via dem Hostsystem dafür zu nutzen.

Laufende Container auflisten:

podman ps

Die verwendeten Ports und die eigene Host IP heraussuchen:

podman port <container_id>
ip a

Einen neuen Container laufen lassen, der Kontakt aufnimmt mittels curl auf die Host IP mit dem veröffentlichten Port:

podman run -it --rm fedora curl <HOST_IP_ADDRESS>:8080

Volumes: Speicher in Container mounten​

Um Daten zu persistieren, müssen diese entweder in einem externen System wie einer Datenbank gespeichert werden oder sie mounten den lokalen Speicher mit der -v volumes Flag. Dafür können sie eines der beiden mount typen nutzen:

  • Bind Mounts
  • Named Volumes

Bind Mounts​

Bind Mounts mountet einen Ordner oder eine Datei in den Container.

Bind Mounts, die Dateien und Ordner enthalten, die einer subuid oder subgid gehören und mit dem normalen Benutzer nicht mehr gelöscht werden können, können mit dem folgenden Befehl gelöscht werden:

podman unshare rm -r ${bind_mount_dir}

Named Volumes​

Named Volumes sind managed von Podman and und können über CLI angepasst werden. Die Volumes werden in einem eigenen Ordner in ~/.local/share/containers/storage/volumes/ abgelegt.

Backup​

Alle Daten, auch die von Volumes werden automatisch von uns gesichert. Aber ein separates Backup kann aus folgenden Gründen nötig sein:

  • Es können keine spezifischen Files oder Ordner aus Volumes wiederhergestellt werden.
  • Die Daten sind nicht persistent gespeichert (z.B. bei einer Datenbank).

Darum empfehlen wir ihnen separate Dumps / Exports der Daten anzulegen. Diese werden dann von unserem Backup gesichert.