Podman Installationsanweisungen

Suchen Sie nach einer GUI? Sie finden Podman Desktop hier.

Installation auf Mac & Windows

Obwohl "Container Linux sind", läuft Podman auch auf Mac und Windows, wo es eine native Podman CLI bereitstellt und ein Gast-Linux-System einbettet, um Ihre Container zu starten. Dieser Gast wird als Podman Machine bezeichnet und wird mit dem Befehl podman machine verwaltet. Podman auf Mac und Windows lauscht auch auf Docker API-Clients und unterstützt die direkte Verwendung von Docker-basierten Tools und den programmatischen Zugriff aus Ihrer bevorzugten Sprache.

macOS

Auf Mac wird jede Podman Machine von einer virtuellen Maschine unterstützt. Nach der Installation kann der podman-Befehl direkt von der Unix-Shell im Terminal ausgeführt werden, wo er remote mit dem podman- Service kommuniziert, der in der Machine VM läuft.

Podman Installer herunterladen (Empfohlen)

Podman kann von der Podman.io Website heruntergeladen werden.

Wir laden auch die Installer und andere Binärdateien auf unsere GitHub Release-Seite hoch.

Obwohl nicht empfohlen, kann Podman auch über Homebrew, den Paketmanager, bezogen werden.

Installation über Brew

Da Brew ein von der Community gepflegter Paketmanager ist, können wir die Stabilität von Brew-Installationen von Podman nicht garantieren. Daher wird die Installation über Brew nicht empfohlen.

Wenn Sie jedoch Brew verwenden möchten, müssen Sie zuerst Homebrew installieren. Sobald Sie Brew eingerichtet haben, können Sie den Befehl brew install verwenden, um Podman zu installieren:

brew install podman

Nach der Installation müssen Sie Ihre erste Podman Machine erstellen und starten:

podman machine init
podman machine start

Sie können dann die Installationsinformationen überprüfen mit:

podman info

Wir stellen auch Binärdateien und einen pkginstaller auf unserer GitHub Release-Seite bereit

Windows

Unter Windows wird jede Podman Machine von einer virtualisierten Windows Subsystem for Linux (WSLv2) Distribution unterstützt. Nach der Installation kann der podman-Befehl direkt von Ihrer Windows PowerShell (oder CMD) Eingabeaufforderung ausgeführt werden, wo er remote mit dem podman-Service kommuniziert, der in der WSL-Umgebung läuft. Alternativ können Sie direkt von der WSL-Instanz auf Podman zugreifen, wenn Sie eine Linux-Eingabeaufforderung und Linux-Tools bevorzugen.

Siehe den Podman for Windows Leitfaden für Einrichtungs- und Nutzungsanweisungen.

Installation auf Linux

Linux-Distributionen

Arch Linux & Manjaro Linux

sudo pacman -S podman

Wenn Sie Probleme beim Ausführen von Podman im rootless Modus haben, folgen Sie den Anweisungen hier

Für weitere Informationen zu Podman auf ArchLinux klicken Sie hier

Alpine Linux

sudo apk add podman

Für weitere Details beziehen Sie sich bitte auf die Anweisungen im Alpine Linux Wiki.

CentOS Stream

Podman ist standardmäßig im AppStream Repository für CentOS Stream 9+ verfügbar.

sudo dnf -y install podman

Debian

Das podman-Paket ist in den Debian 11 (Bullseye) Repositories und später verfügbar.

sudo apt-get -y install podman

Fedora

sudo dnf -y install podman

Um podman machine ... Befehle auszuführen

sudo dnf -y install podman-machine

slirp4netns ist nicht mehr der Standard für rootless Networking bei neuen podman-Installationen, wurde zugunsten von passt abgelöst. Wenn Sie Container haben, die slirp4netns verwenden, stellen Sie sicher, dass slirp4netns installiert ist:

sudo dnf -y install slirp4netns

Fedora CoreOS, Fedora Silverblue

Eingebaut, keine Installation erforderlich

Gentoo

sudo emerge app-containers/podman

OpenEmbedded

Bitbake-Rezepte für Podman und seine Abhängigkeiten sind im meta-virtualization Layer verfügbar. Fügen Sie den Layer zu Ihrer OpenEmbedded Build-Umgebung hinzu und erstellen Sie Podman mit:

bitbake podman

openSUSE

sudo zypper install podman

openSUSE Kubic

Eingebaut, keine Installation erforderlich

Raspberry Pi OS arm64 (beta)

Raspberry Pi OS verwendet die Standard-Debian-Repositories, daher ist es vollständig kompatibel mit Debians arm64-Repository. Sie können einfach den Schritten für Debian folgen, um Podman zu installieren.

RHEL

Folgen Sie der offiziellen Dokumentation.

Ubuntu

Das podman-Paket ist in den offiziellen Repositories für Ubuntu 20.10 und neuer verfügbar.

# Ubuntu 20.10 und neuer
sudo apt-get update
sudo apt-get -y install podman

Linux Mint

Folgen Sie den Schritten für Ubuntu (oder Debian, wenn Sie LMDE verwenden).

Installation von Entwicklungsversionen von Podman

Fedora

Sie können das allerneueste Podman in Fedoras updates-testing Repository testen, bevor es an alle Fedora-Benutzer geht.

sudo dnf update --refresh --enablerepo=updates-testing podman

Wenn Sie ein neueres Podman-Paket aus Fedoras updates-testing verwenden, würden wir Ihr +1 Feedback in Bodhi, Fedoras Update-Management- System schätzen.

Installation von Bleeding-Edge-Versionen von Podman

Wenn Sie Gefahr mögen und daran interessiert sind, die neuesten unveröffentlichten Bits von Podman auf Fedora, CentOS Stream 9+ und RHEL9+ zu testen, haben wir ein Copr Repository.

VORSICHT: Dieses Repository enthält RPM-Builds, die mit dem main Branch der Upstream-Container-Tools-Repositories generiert wurden, und kann einfach NICHT für den Produktionseinsatz empfohlen werden.

Aktivieren Sie das Copr und installieren Sie podman.

sudo dnf copr enable rhcontainerbot/podman-next -y
sudo dnf install podman

Installation auf FreeBSD 14.0

[!WARNING] Der FreeBSD-Port der Podman Container Engine ist experimentell und sollte nur für Evaluierungs- und Testzwecke verwendet werden.

Sie können Podman auf FreeBSD mit pkg installieren:

pkg install podman

Es gibt auch ein podman-suite Meta-Paket, das zusätzliche Pakete für Sie holt (buildah, skopeo).

Anfangskonfiguration

Um Podmans Container-Restart-Policy ordnungsgemäß zu unterstützen, benötigt conmon fdescfs(5), das auf /dev/fd gemountet ist.

Wenn /dev/fd noch nicht gemountet ist:

mount -t fdescfs fdesc /dev/fd

Um es dauerhaft zu machen, fügen Sie die folgende Zeile zu /etc/fstab hinzu:

fdesc   /dev/fd         fdescfs         rw      0       0

Um Podman nach einem Neustart zu starten:

service podman enable

Netzwerk

Container-Netzwerk stützt sich auf NAT, um Container-Netzwerkpakete an das Netzwerk des Hosts weiterzuleiten. Dies erfordert eine PF-Firewall zur Durchführung der Übersetzung. Ein einfaches Beispiel ist enthalten - um es zu verwenden:

cp /usr/local/etc/containers/pf.conf.sample /etc/pf.conf

Bearbeiten Sie /etc/pf.conf und setzen Sie die Variablen v4egress_if, v6egress_if auf Ihre Netzwerkschnittstelle(n)

Aktivieren und starten Sie pf:

service pf enable
service pf start

Die Beispiel-PF-Konfiguration enthält Unterstützung für Port-Umleitungen. Diese sind als Redirect-Regeln in Anchors implementiert, die unter cni-rdr verschachtelt sind.

Unterstützung für die Umleitung von Verbindungen vom Container-Host zu Services, die innerhalb eines Containers laufen, ist für FreeBSD 13.3 und später enthalten. Um dies zu aktivieren, laden Sie zuerst das pf-Kernel-Modul und aktivieren Sie PF-Unterstützung für diese Umleitungen mit sysctl:

echo 'pf_load="YES"' >> /boot/loader.conf
kldload pf
sysctl net.pf.filter_local=1
echo 'net.pf.filter_local=1' >> /etc/sysctl.conf.local
service pf restart

Redirect-Regeln funktionieren, wenn die Zieladresse localhost ist (z.B. 127.0.0.1 oder ::1) - um dies zu aktivieren, muss die folgende Zeile in Ihrer /etc/pf.conf enthalten sein:

nat-anchor "cni-rdr/*"

Bei einem Upgrade von einer älteren Version muss dies zu /etc/pf.conf hinzugefügt werden.

Zum Beispiel, wenn Host-Port 1234 zu einem HTTP-Service umgeleitet wird, der in einem Container läuft, können Sie sich damit verbinden:

fetch -o- http://$(hostname):1234

oder

fetch -o- http://localhost:1234

Speicher

Container-Images und zugehörige Zustände werden in /var/db/containers gespeichert. Es wird empfohlen, dafür ZFS zu verwenden:

zfs create -o mountpoint=/var/db/containers zroot/containers

Wenn Ihr System ZFS nicht verwenden kann, ändern Sie storage.conf, um den vfs Storage-Treiber zu verwenden:

sed -I .bak -e 's/driver = "zfs"/driver = "vfs"/' /usr/local/etc/containers/storage.conf

Überprüfung

Nach dem Befolgen dieser Schritte sollten Sie native Images ausführen können:

podman run --rm docker.io/dougrabson/hello

Linux-Emulation

Es ist möglich, viele Linux-Container-Images mit FreeBSDs Linux-Emulation auszuführen:

sudo sysrc linux_enable=YES
sudo service linux start
sudo podman run --rm --os=linux docker.io/library/alpine cat /etc/os-release | head -1
NAME="Alpine Linux"

Erstellen aus dem Quellcode

Build- und Laufzeit-Abhängigkeiten

Erforderlich

Auf Fedora:

# Build-Abhängigkeiten installieren
sudo dnf -y builddep rpm/podman.spec

# Laufzeit-Abhängigkeiten installieren
sudo dnf -y install catatonit conmon containers-common-extra

Auf allen RHEL und CentOS Stream installieren Sie zuerst dnf-builddep:

sudo dnf -y install 'dnf-command(builddep)'

Build-Abhängigkeiten installieren:

# CentOS Stream 9+
sudo dnf -y builddep rpm/podman.spec --enablerepo=crb

# RHEL 9+
sudo dnf -y builddep rpm/podman.spec --enablerepo=codeready-builder-for-rhel-$(rpm --eval %{?rhel})-$(uname -m)-rpms

Laufzeit-Abhängigkeiten installieren:

sudo dnf -y install \
  conmon \
  containers-common \
  crun \
  iptables \
  netavark \
  nftables \
  slirp4netns

Debian, Ubuntu und verwandte Distributionen:

sudo apt-get install \
  btrfs-progs \
  gcc \
  git \
  golang-go \
  go-md2man \
  iptables \
  libassuan-dev \
  libbtrfs-dev \
  libc6-dev \
  libdevmapper-dev \
  libglib2.0-dev \
  libgpgme-dev \
  libgpg-error-dev \
  libprotobuf-dev \
  libprotobuf-c-dev \
  libseccomp-dev \
  libselinux1-dev \
  libsystemd-dev \
  make \
  netavark \
  passt \
  pkg-config \
  runc \
  uidmap

Das netavark-Paket ist möglicherweise nicht auf älteren Debian / Ubuntu Versionen verfügbar. Installieren Sie stattdessen das containernetworking-plugins-Paket.

Auf openSUSE Leap 15.x und Tumbleweed:

sudo zypper -n in libseccomp-devel libgpgme-devel

Auf Manjaro (und möglicherweise anderen Linux-Distributionen):

Stellen Sie sicher, dass der Linux-Kernel User-Namespaces unterstützt:

> zgrep CONFIG_USER_NS /proc/config.gz
CONFIG_USER_NS=y

Falls nicht, aktualisieren Sie bitte den Kernel. Für Manjaro Linux finden Sie die Anweisungen hier: https://wiki.manjaro.org/index.php/Manjaro_Kernels

Danach aktivieren Sie User-Namespaces:

sudo sysctl kernel.unprivileged_userns_clone=1

Um die User-Namespaces dauerhaft zu aktivieren:

echo 'kernel.unprivileged_userns_clone=1' > /etc/sysctl.d/userns.conf

Fehlende Abhängigkeiten erstellen

Wenn Abhängigkeiten nicht installiert werden können oder nicht ausreichend aktuell sind, müssen sie aus dem Quellcode erstellt werden. Dies betrifft hauptsächlich Debian, Ubuntu und verwandte Distributionen oder RHEL, wo kein Abonnement aktiv ist (z.B. Cloud-VMs).

golang

Achten Sie darauf, dass die Version von golang neu genug ist (d.h. go version), seit Januar 2022 ist Version 1.16.x oder höher erforderlich. Die aktuelle minimal erforderliche Version kann immer in der go.mod Datei gefunden werden. Falls benötigt, sind golang-Kits unter https://golang.org/dl/ verfügbar. Alternativ kann go wie folgt aus dem Quellcode erstellt werden (es ist hilfreich, das System-go installiert zu lassen, um das Bootstrapping von go zu vermeiden):

export GOPATH=~/go
git clone https://go.googlesource.com/go $GOPATH
cd $GOPATH
cd src
./all.bash
export PATH=$GOPATH/bin:$PATH

conmon

Die neueste Version von conmon wird auf dem System erwartet. Conmon wird verwendet, um OCI-Runtimes zu überwachen. Um aus dem Quellcode zu erstellen, verwenden Sie folgendes:

git clone https://github.com/containers/conmon
cd conmon
export GOCACHE="$(mktemp -d)"
make
sudo make podman

crun / runc

Die neueste Version von mindestens einer Container-Runtime wird auf dem System erwartet. crun oder runc sind einige der Möglichkeiten, und eine wird als Standard-Runtime von Podman ausgewählt (crun hat Priorität vor runc). Unterstützte Versionen von crun oder runc sind beispielsweise auf Ubuntu 22.04 verfügbar. runc Version 1.0.0-rc4 ist die Mindestanforderung, die seit Ubuntu 18.04 verfügbar ist.

Zur Überprüfung sollte runc --version mindestens spec: 1.0.1 ausgeben, andernfalls erstellen Sie Ihre eigene:

git clone https://github.com/opencontainers/runc.git $GOPATH/src/github.com/opencontainers/runc
cd $GOPATH/src/github.com/opencontainers/runc
make BUILDTAGS="selinux seccomp"
sudo cp runc /usr/bin/runc

Konfiguration hinzufügen

sudo mkdir -p /etc/containers
sudo curl -L -o /etc/containers/registries.conf https://raw.githubusercontent.com/containers/image/main/registries.conf
sudo curl -L -o /etc/containers/policy.json https://raw.githubusercontent.com/containers/image/main/default-policy.json

Optionale Pakete

Fedora, CentOS, RHEL und verwandte Distributionen:

(keine optionalen Pakete)

Debian, Ubuntu und verwandte Distributionen:

apt-get install -y \
  libapparmor-dev

Quellcode holen

Stellen Sie zunächst sicher, dass die go version, die zuerst im $PATH gefunden wird, 1.16.x oder höher ist. Die Anweisungen oben helfen Ihnen dabei, eine neuere Version von Go zu kompilieren, falls erforderlich. Dann können wir Podman erstellen:

git clone https://github.com/containers/podman/
cd podman
make BUILDTAGS="selinux seccomp" PREFIX=/usr
sudo env PATH=$PATH make install PREFIX=/usr

Build Tags

Andernfalls, wenn Sie Podman nicht mit seccomp- oder selinux-Unterstützung erstellen möchten, können Sie BUILDTAGS="" beim Ausführen von make hinzufügen.

make BUILDTAGS=""
sudo make install

Podman unterstützt optionale Build-Tags für die Kompilierung der Unterstützung verschiedener Features. Um Build-Tags zur make-Option hinzuzufügen, muss die Variable BUILDTAGS gesetzt werden, zum Beispiel:

make BUILDTAGS='seccomp apparmor'

Wenn Sie auf RHEL8 erstellen, müssen Sie ohne btrfs-Unterstützung erstellen, da es entfernt wurde:

make BUILDTAGS="btrfs_noversion exclude_graphdriver_btrfs"

Build Tag	Feature	Abhängigkeit
apparmor	apparmor-Unterstützung	libapparmor
cni	CNI-Networking
exclude_graphdriver_btrfs	btrfs ausschließen	libbtrfs
exclude_graphdriver_devicemapper	device-mapper ausschließen	libdm
libdm_no_deferred_remove	verzögerte Entfernung in libdm ausschließen	libdm
seccomp	Syscall-Filterung	libseccomp
selinux	selinux Prozess- und Mount-Labeling
systemd	journald-Logging	libsystemd

Beachten Sie, dass Podman device-mapper nicht offiziell unterstützt. Daher ist das Tag exclude_graphdriver_devicemapper obligatorisch.

Vendoring - Abhängigkeitsverwaltung

Dieses Projekt verwendet go modules für die Abhängigkeitsverwaltung. Wenn die CI sich über einen Pull Request beschwert, der einen unsauberen Zustand hinterlässt, hat sie wahrscheinlich recht. Nach Änderungen an Abhängigkeiten stellen Sie sicher, dass Sie make vendor ausführen, um den Code mit dem go-Modul zu synchronisieren und das ./vendor-Verzeichnis neu zu füllen.

Ansible

Eine Ansible Role ist auch verfügbar, um die Installation der oben genannten statisch verlinkten Binärdatei auf unterstützten Betriebssystemen zu automatisieren:

sudo su -
mkdir -p ~/.ansible/roles
cd ~/.ansible/roles
git clone https://github.com/alvistack/ansible-role-podman.git podman
cd ~/.ansible/roles/podman
pip3 install --upgrade --ignore-installed --requirement requirements.txt
molecule converge
molecule verify

Konfigurationsdateien

registries.conf

Man Page: registries.conf.5

/etc/containers/registries.conf

registries.conf ist die Konfigurationsdatei, die angibt, welche Container-Registries konsultiert werden sollen, wenn Image-Namen vervollständigt werden, die keinen Registry- oder Domain-Teil enthalten.

HINWEIS: Auf macOS oder Windows führen Sie bitte den Befehl podman machine ssh aus, um die Machine VM zu betreten und die /etc/containers/registries.conf Datei mit demselben Konfigurationsinhalt zu bearbeiten. Wenn Sie Berechtigungsprobleme haben, führen Sie podman machine set --rootful aus und versuchen Sie es erneut.

Beispiel aus dem Fedora containers-common Paket

$ cat /etc/containers/registries.conf
# Für weitere Informationen zu dieser Konfigurationsdatei siehe containers-registries.conf(5).
#
# HINWEIS: RISIKO BEI DER VERWENDUNG VON UNQUALIFIZIERTEN IMAGE-NAMEN
# Wir empfehlen, immer vollqualifizierte Image-Namen zu verwenden, einschließlich des Registry-
# Servers (vollständiger DNS-Name), Namespace, Image-Name und Tag
# (z.B. registry.redhat.io/ubi8/ubi:latest). Das Pullen über Digest (d.h.
# quay.io/repository/name@digest) eliminiert zusätzlich die Mehrdeutigkeit von Tags.
# Bei der Verwendung von Kurznamen besteht immer ein inhärentes Risiko, dass das zu pullende
# Image gefälscht werden könnte. Zum Beispiel möchte ein Benutzer ein Image namens
# `foobar` von einer Registry pullen und erwartet, dass es von myregistry.com kommt. Wenn
# myregistry.com nicht an erster Stelle in der Suchliste steht, könnte ein Angreifer ein
# anderes `foobar` Image in einer Registry weiter oben in der Suchliste platzieren. Der Benutzer
# würde versehentlich das Image und den Code des Angreifers pullen und ausführen anstatt des
# beabsichtigten Inhalts. Wir empfehlen, nur Registries hinzuzufügen, die vollständig
# vertrauenswürdig sind (d.h. Registries, die unbekannten oder anonymen Benutzern nicht erlauben,
# Konten mit beliebigen Namen zu erstellen). Dies verhindert, dass ein Image gefälscht,
# besetzt oder anderweitig unsicher gemacht wird. Wenn es notwendig ist, eine
# dieser Registries zu verwenden, sollte sie am Ende der Liste hinzugefügt werden.
#
# # Ein Array von host[:port] Registries, die beim Pullen eines unqualifizierten Images ausprobiert werden sollen, in Reihenfolge.
unqualified-search-registries = ["registry.fedoraproject.org", "registry.access.redhat.com", "docker.io"]
#
# [[registry]]
# # The "prefix" field is used to choose the relevant [[registry]] TOML table;
# # (only) the TOML table with the longest match for the input image name
# # (taking into account namespace/repo/tag/digest separators) is used.
# #
# # If the prefix field is missing, it defaults to be the same as the "location" field.
# prefix = "example.com/foo"
#
# # If true, unencrypted HTTP as well as TLS connections with untrusted
# # certificates are allowed.
# insecure = false
#
# # If true, pulling images with matching names is forbidden.
# blocked = false
#
# # The physical location of the "prefix"-rooted namespace.
# #
# # By default, this equal to "prefix" (in which case "prefix" can be omitted
# # and the [[registry]] TOML table can only specify "location").
# #
# # Example: Given
# #   prefix = "example.com/foo"
# #   location = "internal-registry-for-example.net/bar"
# # requests for the image example.com/foo/myimage:latest will actually work with the
# # internal-registry-for-example.net/bar/myimage:latest image.
# location = "internal-registry-for-example.com/bar"
#
# # (Possibly-partial) mirrors for the "prefix"-rooted namespace.
# #
# # The mirrors are attempted in the specified order; the first one that can be
# # contacted and contains the image will be used (and if none of the mirrors contains the image,
# # the primary location specified by the "registry.location" field, or using the unmodified
# # user-specified reference, is tried last).
# #
# # Each TOML table in the "mirror" array can contain the following fields, with the same semantics
# # as if specified in the [[registry]] TOML table directly:
# # - location
# # - insecure
# [[registry.mirror]]
# location = "example-mirror-0.local/mirror-for-foo"
# [[registry.mirror]]
# location = "example-mirror-1.local/mirrors/foo"
# insecure = true
# # Given the above, a pull of example.com/foo/image:latest will try:
# # 1. example-mirror-0.local/mirror-for-foo/image:latest
# # 2. example-mirror-1.local/mirrors/foo/image:latest
# # 3. internal-registry-for-example.net/bar/image:latest
# # in order, and use the first one that exists.
#
# short-name-mode="enforcing"

[[registry]]
location="localhost:5000"
insecure=true

mounts.conf

/usr/share/containers/mounts.conf und optional /etc/containers/mounts.conf

Die mounts.conf Dateien spezifizieren Volume-Mount-Verzeichnisse, die automatisch in Container eingebunden werden, wenn die Befehle podman run oder podman build ausgeführt werden. Container-Prozesse können dann diesen Inhalt verwenden. Der Volume-Mount-Inhalt wird nicht in das finale Image committet.

Normalerweise werden diese Verzeichnisse verwendet, um Secrets oder Credentials zu übergeben, die von der Paket-Software benötigt werden, um auf entfernte Paket-Repositories zuzugreifen.

Zum Beispiel, bei einer mounts.conf mit der Zeile "/usr/share/rhel/secrets:/run/secrets", wird der Inhalt des /usr/share/rhel/secrets Verzeichnisses auf /run/secrets innerhalb des Containers gemountet. Dieser Mountpoint ermöglicht es, Red Hat Enterprise Linux Abonnements vom Host innerhalb des Containers zu verwenden.

Beachten Sie, dass dies kein Volume-Mount ist. Der Inhalt der Volumes wird in den Container-Speicher kopiert, nicht direkt vom Host bind-gemountet.

Beispiel aus dem Fedora containers-common Paket:

cat /usr/share/containers/mounts.conf
/usr/share/rhel/secrets:/run/secrets

seccomp.json

/usr/share/containers/seccomp.json

seccomp.json enthält die Whitelist von seccomp-Regeln, die innerhalb von Containern erlaubt sein sollen. Diese Datei wird normalerweise vom containers-common Paket bereitgestellt.

Der obige Link führt Sie zur seccomp.json

policy.json

/etc/containers/policy.json

Man Page: policy.json.5

Beispiel aus dem Fedora containers-common Paket:

cat /etc/containers/policy.json
{
    "default": [
        {
            "type": "insecureAcceptAnything"
        }
    ],
    "transports":
        {
            "docker-daemon":
                {
                    "": [{"type":"insecureAcceptAnything"}]
                }
        }
}