linux-system-roles.podman

podman

Diese Rolle verwaltet die Konfiguration von podman, Container und systemd-Dienste, die podman-Container ausführen.

Anforderungen

Die Rolle benötigt podman Version 4.2 oder höher.
Die Rolle benötigt podman Version 4.4 oder höher für Quadlet- und Geheimnisunterstützung.
Die Rolle benötigt podman Version 4.5 oder höher für die Unterstützung von Gesundheitsprüfungen (nur unterstützt bei Verwendung von Quadlet-Containertypen).

Sammlungsanforderungen

Die Rolle benötigt die folgenden Sammlungen:

containers.podman
fedora.linux_system_roles

Verwenden Sie dies, um die Sammlungen zu installieren:

ansible-galaxy collection install -vv -r meta/collection-requirements.yml

Benutzer, Gruppen, SubUID, SubGID

Benutzer und Gruppen, die in podman_run_as_user, podman_run_as_group angegeben sind, sowie in einer Kube-Spezifikation als run_as_user und run_as_group, unterliegen den folgenden Einschränkungen:

Sie müssen bereits im System vorhanden sein - die Rolle wird die Benutzer oder Gruppen nicht erstellen - die Rolle wird mit einem Fehler beendet, wenn ein nicht vorhandener Benutzer oder eine nicht vorhandene Gruppe angegeben wird.
Sie müssen bereits in /etc/subuid und /etc/subgid vorhanden sein oder durch Ihr Identitätsmanagementsystem bereitgestellt werden - die Rolle wird mit einem Fehler beendet, wenn ein angegebener Benutzer nicht in /etc/subuid vorhanden ist oder eine angegebene Gruppe nicht in /etc/subgid vorhanden ist. Die Rolle verwendet getsubids, um den Benutzer und die Gruppe zu überprüfen, wenn verfügbar, oder prüft die Dateien direkt, wenn getsubids nicht verfügbar ist.

Rollenvariablen

podman_kube_specs

Dies ist eine Liste. Jedes Element der Liste ist ein dict, das ein Podman-Pod und die entsprechende systemd-Einheit beschreibt, die verwaltet werden soll. Das Format des dict ist größtenteils wie das podman_play-Modul, mit folgenden Ausnahmen:

state - Standard ist created. Es nimmt 3 Werte an:
- started - Erstellen Sie die Pods und systemd-Dienste und starten Sie sie.
- created - Erstellen Sie die Pods und systemd-Dienste, starten Sie diese jedoch nicht.
- absent - Entfernen Sie die Pods und systemd-Dienste.
run_as_user - Verwenden Sie dies, um einen benutzerspezifischen Pod anzugeben. Wenn Sie dies nicht angeben, wird der globale Standardwert podman_run_as_user verwendet. Andernfalls wird root verwendet. HINWEIS: Der Benutzer muss bereits vorhanden sein - die Rolle wird keinen erstellen. Der Benutzer muss in /etc/subuid vorhanden sein.
run_as_group - Verwenden Sie dies, um eine benutzerspezifische Gruppe anzugeben. Wenn Sie dies nicht angeben, wird der globale Standardwert podman_run_as_group verwendet. Andernfalls wird root verwendet. HINWEIS: Die Gruppe muss bereits vorhanden sein - die Rolle wird keine erstellen. Die Gruppe muss in /etc/subgid vorhanden sein.
systemd_unit_scope - Der Anwendungsbereich, der für die systemd-Einheit verwendet werden soll. Wenn Sie dies nicht angeben, wird der globale Standardwert podman_systemd_unit_scope verwendet. Andernfalls wird der Anwendungsbereich system für Root-Container und user für Benutzercontainer verwendet.
activate_systemd_unit - Ob die systemd-Einheit aktiviert werden soll, wenn sie erstellt wird. Wenn Sie dies nicht angeben, wird der globale Standardwert podman_activate_systemd_unit verwendet, der standardmäßig true ist.
pull_image - Stellen Sie sicher, dass das Bild vor der Verwendung heruntergeladen wird. Wenn Sie dies nicht angeben, wird der globale Standardwert podman_pull_image verwendet, der standardmäßig true ist.
continue_if_pull_fails - Wenn das Herunterladen des Bildes fehlschlägt, behandeln Sie dies nicht als kritischer Fehler und fahren Sie mit der Rolle fort. Wenn Sie dies nicht angeben, wird der globale Standardwert podman_continue_if_pull_fails verwendet, der standardmäßig false ist.
kube_file_src - Dies ist der Name einer Datei auf dem Steuerknoten, die in kube_file auf dem verwalteten Knoten kopiert wird. Dies ist eine Datei im YAML-Format von Kubernetes. Geben Sie dies nicht an, wenn Sie kube_file_content angeben. kube_file_content hat Vorrang vor kube_file_src.
kube_file_content - Dies ist entweder ein String im YAML-Format von Kubernetes oder ein dict im YAML-Format von Kubernetes. Es wird als Inhalt von kube_file auf dem verwalteten Knoten verwendet. Geben Sie dies nicht an, wenn Sie kube_file_src angeben. kube_file_content hat Vorrang vor kube_file_src.
kube_file - Dies ist der Name einer Datei auf dem verwalteten Knoten, die die Kubernetes-Spezifikation des Containers/Pods enthält. Im Allgemeinen müssen Sie dies nicht angeben, es sei denn, Sie müssen diese Datei auf andere Weise auf den verwalteten Knoten kopieren. Wenn Sie entweder kube_file_src oder kube_file_content angeben, müssen Sie dies nicht angeben. Es wird dringend empfohlen, kube_file wegzulassen und stattdessen entweder kube_file_src oder kube_file_content anzugeben und die Rolle den Dateipfad und den Namen verwalten zu lassen.
- Der Dateiname wird der Wert metadata.name aus dem K8s YAML sein, mit einer .yml-Erweiterung.
- Das Verzeichnis wird /etc/containers/ansible-kubernetes.d für Systemdienste sein.
- Das Verzeichnis wird $HOME/.config/containers/ansible-kubernetes.d für Benutzerdienste sein.

Zum Beispiel, wenn Sie haben

    podman_kube_specs:
      - state: started
        kube_file_content:
          apiVersion: v1
          kind: Pod
          metadata:
            name: myappname

Dies wird in die Datei /etc/containers/ansible-kubernetes.d/myappname.yml auf dem verwalteten Knoten kopiert.

podman_quadlet_specs

Liste von Quadlet-Spezifikationen. Eine Quadlet-Spezifikation wird eindeutig durch einen Namen und einen Typ identifiziert, wobei der Typ einer der Einheitstypen wie Container, Kube, Netzwerk, Volumen usw. ist. Sie können entweder name und type ausdrücklich angeben oder der name und type wird aus dem Dateinamen abgeleitet, der in file, file_src oder template_src angegeben ist.

Standardmäßig werden die Dateien auf dem verwalteten Knoten in /etc/containers/systemd/$name.$type für Root-Container und in $HOME/.config/containers/systemd/$name.$type für rootlose Container kopiert oder erstellt. Sie können einen anderen Speicherort angeben, indem Sie file verwenden, müssen jedoch wahrscheinlich die systemd-Konfiguration ändern, um die Datei zu finden, was von dieser Rolle nicht unterstützt wird.

Wenn eine Quadlet-Spezifikation von einer anderen Datei abhängt, z. B. einer quadlet.kube, die von der YAML-Datei oder einem ConfigMap abhängt, muss diese Datei in der Liste podman_quadlet_specs vor der Datei angegeben werden, die sie verwendet. Zum Beispiel, wenn Sie eine Datei my-app.kube haben:

[Kube]
ConfigMap=my-app-config.yml
Yaml=my-app.yml
...

Dann müssen Sie my-app-config.yml und my-app.yml vor my-app.kube angeben:

podman_quadlet_specs:
  - file_src: my-app-config.yml
  - file_src: my-app.yml
  - file_src: my-app.kube

Die meisten Parameter für jede Quadlet-Spezifikation sind die gleichen wie für die oben genannten podman_kube_spec, mit der Ausnahme, dass die *kube*-Parameter nicht unterstützt werden, und den folgenden:

name - Der Name der Einheit. Wenn nicht angegeben, wird er aus file, file_src oder template_src abgeleitet. Zum Beispiel, wenn Sie file_src: /path/to/my-container.container angeben, wird der name my-container sein.
type - Der Typ der Einheit (Container, Kube, Volumen usw.). Wenn nicht angegeben, wird er aus file, file_src oder template_src abgeleitet. Zum Beispiel, wenn Sie file_src: /path/to/my-container.container angeben, wird der type container sein. Wenn der abgeleitete Typ nicht als gültiger Quadlet-Typ anerkannt wird, z. B. wenn Sie file_src: my-kube.yml angeben, wird er einfach kopiert und nicht als Quadlet-Spezifikation verarbeitet.
file_src - Der Name der Datei auf dem Steuerknoten, die in den verwalteten Knoten kopiert werden soll, um als Quelle der Quadlet-Einheit verwendet zu werden. Wenn diese Datei im Quadlet-Einheitsformat vorliegt und eine gültige Quadlet-Einheitserweiterung hat, wird sie als Quadlet-Einheit verwendet, andernfalls wird sie einfach kopiert.
file - Der Name der Datei auf dem verwalteten Knoten, die als Quelle der Quadlet-Einheit verwendet werden soll. Wenn diese Datei im Quadlet-Einheitsformat vorliegt und eine gültige Quadlet-Einheitserweiterung hat, wird sie als Quadlet-Einheit verwendet, andernfalls wird sie als normale Datei behandelt.
file_content - Der Inhalt einer Datei, die auf den verwalteten Knoten kopiert wird, im String-Format. Dies ist nützlich, um kurze Dateien zu übergeben, die leicht inline angegeben werden können. Sie müssen auch name und type angeben.
template_src - Der Name der Datei auf dem Steuerknoten, die als Jinja template-Datei verarbeitet und dann auf den verwalteten Knoten kopiert wird, um als Quelle der Quadlet-Einheit verwendet zu werden. Wenn diese Datei im Quadlet-Einheitsformat vorliegt und eine gültige Quadlet-Einheitserweiterung hat, wird sie als Quadlet-Einheit verwendet, andernfalls wird sie einfach kopiert. Wenn die Datei eine .j2-Erweiterung hat, wird diese entfernt, um den Quadlet-Dateityp zu bestimmen.

Zum Beispiel, wenn Sie angeben:

podman_quadlet_specs:
  - template_src: my-app.container.j2

Dann wird die lokale Datei templates/my-app.container.j2 als Jinja-Vorlagendatei verarbeitet und dann als Quadlet-Container-Einheitsspezifikation nach /etc/containers/systemd/my-app.container auf dem verwalteten Knoten kopiert.

HINWEIS: Beim Entfernen von Quadlets müssen Sie Netzwerke zuletzt entfernen. Sie können ein Netzwerk, das von einem Container verwendet wird, nicht entfernen.

podman_secrets

Dies ist eine Liste von Geheimnisspezifikationen im nahezu gleichen Format wie bei podman_secret. Es gibt ein zusätzliches Feld:

run_as_user - Verwenden Sie dies, um ein Geheimnis für einen bestimmten Benutzer anzugeben. Wenn Sie dies nicht angeben, wird der globale Standardwert podman_run_as_user verwendet. Andernfalls wird root verwendet. HINWEIS: Der Benutzer muss bereits vorhanden sein - die Rolle wird keinen erstellen.

Es wird dringend empfohlen, Ansible Vault zu verwenden, um den Wert des Felds data zu verschlüsseln.

podman_create_host_directories

Dies ist ein boolescher Wert, der standardmäßig false ist. Wenn true, stellt die Rolle sicher, dass die auf dem Host in den Host-Mounts in den volumes.hostPath-Spezifikationen im Kubernetes-YAML angegebenen Verzeichnisse erstellt werden. HINWEIS: Verzeichnisse müssen als absolute Pfade (für Root-Container) oder als Pfade relativ zum Home-Verzeichnis (für nicht-root Container) angegeben werden, damit die Rolle sie verwalten kann. Andernfalls wird davon ausgegangen, dass es sich um eine andere Art von Volumen handelt, und ignoriert. Die Rolle wendet ihre standardmäßigen Eigentums-/Berechtigungen auf die Verzeichnisse an. Wenn Sie die Eigentums-/Berechtigungen festlegen müssen, siehe podman_host_directories.

podman_host_directories

Dies ist ein dict. Wenn podman_create_host_directories verwendet wird, sagt dies der Rolle, welche Berechtigungen/Eigentumsverhältnisse auf die automatisch erstellten Hostverzeichnisse angewendet werden sollen. Jeder Schlüssel ist der absolute Pfad des Hostverzeichnisses, das verwaltet werden soll. Der Wert hat das Format der Parameter des File-Moduls. Wenn Sie kein Wert angeben, verwendet die Rolle ihre eingebauten Standardwerte. Wenn Sie einen Wert für alle Hostverzeichnisse angeben möchten, verwenden Sie den speziellen Schlüssel DEFAULT.

podman_host_directories:
  "/var/lib/data":
    owner: dbuser
    group: dbgroup
    mode: "0600"
  DEFAULT:
    owner: root
    group: root
    mode: "0644"

Die Rolle wird dbuser:dbgroup 0600 für /var/lib/data und root:root 0644 für alle anderen vom der Rolle erstellten Hostverzeichnisse verwenden.

podman_firewall

Dies ist eine Liste von dict im gleichen Format wie bei der Rolle fedora.linux_system_roles.firewall. Verwenden Sie dies, um Ports anzugeben, die von der Rolle in der Firewall verwaltet werden sollen.

podman_firewall:
  - port: 8080/tcp

podman_selinux_ports

Dies ist eine Liste von dict im gleichen Format wie bei der Rolle fedora.linux_system_roles.selinux. Verwenden Sie dies, wenn Sie möchten, dass die Rolle die SELinux-Richtlinie für von der Rolle verwendete Ports verwaltet.

podman_selinux_ports:
  - ports: 8080
    protocol: tcp
    setype: http_port_t

podman_run_as_user

Dies ist der Name des Benutzers, der für alle rootlosen Container verwendet werden soll. Sie können auch einen spezifischen Benutzernamen pro Container mit run_as_user in podman_kube_specs angeben. HINWEIS: Der Benutzer muss bereits vorhanden sein - die Rolle wird keinen erstellen. Der Benutzer muss in /etc/subuid vorhanden sein.

podman_run_as_group

Dies ist der Name der Gruppe, die für alle rootlosen Container verwendet werden soll. Sie können auch einen spezifischen Gruppennamen pro Container mit run_as_group in podman_kube_specs angeben. HINWEIS: Die Gruppe muss bereits vorhanden sein - die Rolle wird keine erstellen. Die Gruppe muss in /etc/subgid vorhanden sein.

podman_systemd_unit_scope

Dies ist der systemd-Anwendungsbereich, der standardmäßig für alle systemd-Einheiten verwendet wird. Sie können auch den Anwendungsbereich pro Container mit systemd_unit_scope in podman_kube_specs angeben. Standardmäßig verwenden rootlose Container user und Root-Container verwenden system.

podman_activate_systemd_units

Aktivieren Sie jede systemd-Einheit sofort nach deren Erstellung. Standard ist true. Sie können dies auch pro Einheit tun, indem Sie activate_systemd_units in der Spezifikation für jede Einheit verwenden. Wenn Sie beispielsweise mehrere Spezifikationen bereitstellen und nur die letzte in der Liste aktivieren möchten, die die anderen über Abhängigkeiten aktiviert, setzen Sie activate_systemd_unit: false für jede außer der letzten, die activate_systemd_unit: true verwendet. HINWEIS: Quadlet-Einheiten werden beim Erstellen implizit aktiviert - derzeit können Sie activate_systemd_unit nicht verwenden, um diese Einheiten zu deaktivieren - Sie können activate_systemd_unit verwenden, um Einheiten zu erstellen, die gestoppt oder gestartet sind.

podman_pull_image

Stellen Sie sicher, dass jedes Bild, das in einer Kube- oder Quadlet-Spezifikation erwähnt wird, vorhanden ist, indem Sie das Bild vor der Verwendung herunterladen. Standardmäßig ist dies true. Verwenden Sie false, wenn der verwaltete Knoten bereits die richtige Version hat oder keine Bilder herunterladen kann. Sie können dies auch pro Einheit mit pull_image angeben.

podman_continue_if_pull_fails

Wenn der Versuch, ein Bild herunterzuladen, fehlschlägt, behandeln Sie dies nicht als kritischen Fehler, und fahren Sie mit dem Ausführen der Rolle fort. Standardmäßig ist dies false - ein Fehlschlag beim Herunterladen ist ein kritischer Fehler. Sie können dies pro Einheit mit continue_if_pull_fails festlegen.

podman_containers_conf

Dies sind die Einstellungen in der Datei containers.conf(5), bereitgestellt als dict. Diese Einstellungen werden in einer Drop-in-Datei im Verzeichnis containers.conf.d bereitgestellt. Wenn als Root ausgeführt (siehe podman_run_as_user), werden die Systemeinstellungen verwaltet, andernfalls werden die Benutzereinstellungen verwaltet. Siehe die Man-Seite für die Verzeichnisspeicherorte.

podman_containers_conf:
  containers:
    default_sysctls:
      - net.ipv4.ping_group_range=0 1000
      - user.max_ipc_namespaces=125052

podman_registries_conf

Dies sind die Einstellungen in der Datei containers-registries.conf(5), bereitgestellt als dict. Diese Einstellungen werden in einer Drop-in-Datei im Verzeichnis registries.conf.d bereitgestellt. Wenn als Root ausgeführt (siehe podman_run_as_user), werden die Systemeinstellungen verwaltet, andernfalls werden die Benutzereinstellungen verwaltet. Siehe die Man-Seite für die Verzeichnisspeicherorte.

podman_registries_conf:
  aliases:
    myregistry: registry.example.com

podman_storage_conf

Dies sind die Einstellungen in der Datei containers-storage.conf(5), bereitgestellt als dict. Wenn als Root ausgeführt (siehe podman_run_as_user), werden die Systemeinstellungen verwaltet, andernfalls werden die Benutzereinstellungen verwaltet. Siehe die Man-Seite für die Dateispeicherorte.

podman_storage_conf:
  storage:
    runroot: /var/big/partition/container/storage

podman_policy_json

Dies sind die Einstellungen in der Datei containers-policy.json(5), bereitgestellt als dict. Wenn als Root ausgeführt (siehe podman_run_as_user), werden die Systemeinstellungen verwaltet, andernfalls werden die Benutzereinstellungen verwaltet. Siehe die Man-Seite für die Dateispeicherorte.

podman_policy_json:
  default:
    type: insecureAcceptAnything

podman_use_copr (EXPERIMENTAL)

Boolean - Standard ist nicht gesetzt - wenn Sie das copr-Repository aktivieren möchten, um die neueste Entwicklungsversion von Podman zu verwenden, verwenden Sie podman_use_copr: true.

podman_fail_if_too_old (EXPERIMENTAL)

Boolean - Standard ist nicht gesetzt - standardmäßig schlägt die Rolle mit einem Fehler fehl, wenn Sie eine ältere Version von Podman verwenden und versuchen, eine Funktion zu verwenden, die nur von einer neueren Version unterstützt wird. Zum Beispiel, wenn Sie versuchen, Quadlet oder Geheimnisse mit Podman 4.3 oder älter zu verwalten, schlägt die Rolle mit einem Fehler fehl. Wenn Sie möchten, dass die Rolle übersprungen wird, verwenden Sie podman_fail_if_too_old: false.

podman_registry_username

String - Standard ist nicht gesetzt - Benutzername zur Authentifizierung im Repository. Sie müssen auch podman_registry_password festlegen. Sie können dies pro Spezifikation mit registry_username überschreiben. Die Verwendung von container_image_user wurde nicht unterstützt und ist veraltet.

podman_registry_password

String - Standard ist nicht gesetzt - Passwort zur Authentifizierung im Repository. Sie müssen auch podman_registry_username festlegen. Sie können dies pro Spezifikation mit registry_password überschreiben. Die Verwendung von container_image_password wurde nicht unterstützt und ist veraltet.

podman_credential_files

Dies ist eine Liste. Jedes Element der Liste ist ein dict, das eine Podman-Authentifizierungsdatei beschreibt, die zur Authentifizierung bei Repositories verwendet wird. Weitere Informationen über das Format dieser Dateien und den standardmäßigen Verzeichnissuchpfad finden Sie in man containers-auth.json und man containers-registries.conf:credential-helpers.
HINWEIS: Diese Dateien enthalten Authentifizierungsdaten. Bitte seien Sie vorsichtig damit. Es wird dringend empfohlen, Ansible Vault zu verwenden, um sie zu verschlüsseln. Die Schlüssel jedes dict sind wie folgt:

state - Standard ist present. Verwenden Sie absent, um Dateien zu entfernen.
file_src - Dies ist der Name einer Datei auf dem Steuerknoten, die in file auf dem verwalteten Knoten kopiert wird. Geben Sie dies nicht an, wenn Sie file_content oder template_src angeben, die Vorrang vor file_src haben.
template_src - Dies ist der Name einer Datei auf dem Steuerknoten, die mit dem Modul template verarbeitet und dann in file auf dem verwalteten Knoten kopiert wird. Geben Sie dies nicht an, wenn Sie file_content oder file_src angeben.
file_content - Dies ist ein String im Format containers-auth.json. Es wird als Inhalt von file auf dem verwalteten Knoten verwendet. Geben Sie dies nicht an, wenn Sie file_src oder template_src angeben.
file - Dies ist der Name einer Datei auf dem verwalteten Knoten, die die auth.json-Inhalte enthalten wird. Der Standardwert ist $HOME/.config/containers/auth.json. Wenn Sie einen relativen Pfad angeben, ist er relativ zu $HOME/.config/containers. Wenn Sie etwas anderes als die oben genannten Standards in man containers-auth.json angeben, müssen Sie auch credential-helpers in containers-registries.conf mit podman_registries_conf konfigurieren. Fehlende übergeordnete Verzeichnisse werden erstellt.
run_as_user - Verwenden Sie dies, um einen Eigentümer der Anmeldeinformationen pro Datei anzugeben. Wenn Sie dies nicht angeben, wird der globale Standardwert podman_run_as_user verwendet. Andernfalls wird root verwendet. HINWEIS: Der Benutzer muss bereits vorhanden sein - die Rolle wird keinen erstellen. Der Benutzer muss in /etc/subuid vorhanden sein. HINWEIS: Dies wird als Benutzer für das $HOME-Verzeichnis verwendet, wenn file nicht angegeben ist, und als Eigentümer der Datei. Wenn Sie möchten, dass der Eigentümer der Datei anders ist als der Benutzer, der für $HOME verwendet wird, geben Sie file als absoluten Pfad an.
run_as_group - Verwenden Sie dies, um eine Gruppe für die Anmeldeinformationen pro Datei anzugeben. Wenn Sie dies nicht angeben, wird der globale Standardwert podman_run_as_group verwendet. Andernfalls wird root verwendet. HINWEIS: Die Gruppe muss bereits vorhanden sein - die Rolle wird keine erstellen. Die Gruppe muss in /etc/subgid vorhanden sein.
mode - Der Modus der Datei - Standard ist "0600".

Zum Beispiel, wenn Sie haben

    podman_credential_files:
      - file_src: auth.json
        run_as_user: my_user

Die lokale Datei auth.json wird im gewohnten Ansible-Dateisuchpfad gesucht und nach /home/my_user/.config/containers/auth.json auf dem verwalteten Knoten kopiert. Der Dateieigentümer wird my_user sein und der Modus wird "0600" sein. Die Verzeichnisse /home/my_user/.config und /home/my_user/.config/containers werden erstellt, falls sie nicht vorhanden sind.

podman_registry_certificates

Diese Variable ist eine Liste von dict-Elementen, die es Ihnen ermöglicht, TLS-Zertifikate und -Schlüssel zu verwalten, die zur Verbindung mit Repositories verwendet werden. Die Verzeichnisse, Formate und Dateien sind in man containers-certs.d beschrieben. Die Namen der für TLS-Zertifikate und -Schlüssel verwendeten Schlüssel folgen den Benennungskonventionen für TLS in Systemrollen. HINWEIS: Das Präfix client_ wurde hier für cert und private_key entfernt, da es in diesem Kontext nur Clients gibt.

HINWEIS: Es wird dringend empfohlen, Ansible Vault zu verwenden, um private Schlüssel und andere sensible Werte zu verschlüsseln.

Die Schlüssel jedes dict sind wie folgt:

state - Standard ist present. Verwenden Sie absent, um Dateien zu entfernen.
run_as_user - Dies ist der Benutzer, der Eigentümer der Dateien sein wird und verwendet wird, um das $HOME-Verzeichnis für die Dateien zu finden. Wenn Sie dies nicht angeben, wird der globale Standardwert podman_run_as_user verwendet. Andernfalls wird root verwendet.
run_as_group - Dies ist die Gruppe, die Eigentümer der Dateien sein wird. Wenn Sie dies nicht angeben, wird der globale Standardwert podman_run_as_group verwendet. Andernfalls wird root verwendet.
registry_host - Erforderlich - der Hostname oder der hostname:port des Repositories. Dies wird als Name des Verzeichnisses unter $HOME/.config/containers/certs.d (für rootlose Container) oder /etc/containers/certs.d (für Systemcontainer) verwendet, in dem die Zertifikate und Schlüssel abgelegt werden. Wenn state: absent verwendet wird und alle Dateien entfernt werden, wird das Verzeichnis entfernt.
cert - Name der Datei im certs.d-Verzeichnis, die das TLS-Clientzertifikat enthält. Wenn nicht angegeben, wird der Basename von cert_src verwendet. Wenn dieser nicht angegeben ist, wird client.cert verwendet.
private_key - Name der Datei im certs.d-Verzeichnis, die den TLS-Clientprivatschlüssel enthält. Wenn nicht angegeben, wird der Basename von private_key_src verwendet. Wenn dieser nicht angegeben ist, wird client.key verwendet.
ca_cert - Name der Datei im certs.d-Verzeichnis, die das TLS-CA-Zertifikat enthält. Wenn nicht angegeben, wird der Basename von ca_cert_src verwendet. Wenn dieser nicht angegeben ist, wird ca.crt verwendet.
cert_src - Name der Datei auf dem Steuerknoten, die in cert kopiert werden soll.
private_key_src - Name der Datei auf dem Steuerknoten, die in private_key kopiert werden soll.
ca_cert_src - Name der Datei auf dem Steuerknoten, die in ca_cert kopiert werden soll.
cert_content - Inhalt des Zertifikats, das in cert kopiert werden soll.
private_key_content - Inhalt des privaten Schlüssels, der in private_key kopiert werden soll.

podman_run_as_user: root
podman_registry_certificates:
  - registry_host: quay.io:5000
    cert_src: client.cert
    private_key_content: !vault |
      $ANSIBLE_VAULT.....
    ca_cert_src: ca.crt

Dies wird das Verzeichnis /etc/containers/certs.d/quay.io:5000/ erstellen, die lokale Datei client.cert, die im gewohnten Ansible-Dateisuchpfad gesucht wird, nach /etc/containers/certs.d/quay.io:5000/client.cert kopieren, den Inhalt des mit Ansible Vault verschlüsselten private_key_content nach /etc/containers/certs.d/quay.io:5000/client.key kopieren und die lokale Datei ca.crt, die im gewohnten Ansible-Dateisuchpfad gesucht wird, nach /etc/containers/certs.d/quay.io:5000/ca.crt kopieren.

podman_validate_certs

Boolean - Standard ist null - verwenden Sie dies, um zu steuern, ob beim Herunterladen von Bildern aus Repositories TLS-Zertifikate validiert werden. Der Standardwert null bedeutet, dass das verwendet wird, was das Modul containers.podman.podman_image standardmäßig verwendet. Sie können dies pro Spezifikation mit validate_certs überschreiben.

podman_prune_images

Boolean - Standard ist false - standardmäßig wird die Rolle keine ungenutzten Bilder entfernen, wenn Quadlets und andere Ressourcen entfernt werden. Setzen Sie dies auf true, um der Rolle zu sagen, ungenutzte Bilder beim Bereinigen zu entfernen.

podman_transactional_update_reboot_ok

Diese Variable gilt nur für transaktionale Updatesysteme. Wenn ein transaktionales Update einen Neustart erfordert, fährt die Rolle mit dem Neustart fort, wenn podman_transactional_update_reboot_ok auf true gesetzt ist. Wenn auf false gesetzt, benachrichtigt die Rolle den Benutzer, dass ein Neustart erforderlich ist, und ermöglicht damit eine benutzerdefinierte Handhabung der Neustartanforderung. Wenn diese Variable nicht gesetzt ist, wird die Rolle sicherstellen, dass die Neustartanforderung nicht übersehen wird. Für nicht transaktionale Updatesysteme wird diese Variable ignoriert.

Vom Rolle exportierte Variablen

podman_version

Dies ist die Versionsnummer der verwendeten Podman-Version. Sie können dies in Ihren Vorlagen verwenden. Zum Beispiel, wenn Sie eine Quadlet-template_src für einen Container angeben möchten und sie Gesundheitsprüfungen und Geheimnisse verwenden möchten, wenn Sie Podman 4.5 oder höher verwenden:

podman_quadlet_specs:
  - template_src: my-app.container.j2
podman_secrets:
  - name: my-app-pwd
    data: .....

my-app.container.j2:

[Container]
{% if podman_version is version("4.5", ">=") %}
Secret=my-app-pwd,type=env,target=MYAPP_PASSWORD
HealthCmd=/usr/bin/test -f /path/to/my-app.file
HealthOnFailure=kill
{% else %}
PodmanArgs=--secret=my-app-pwd,type=env,target=MYAPP_PASSWORD
{% endif %}

podman_subuid_info, podman_subgid_info

Die Rolle muss sicherstellen, dass alle Benutzer und Gruppen in den SubUID- und SubGID-Informationen vorhanden sind. Nachdem sie diese Daten extrahiert hat, sind sie in podman_subuid_info und podman_subgid_info verfügbar. Dies sind dicts. Der Schlüssel ist der Benutzer- oder Gruppenname, und der Wert ist ein dict mit zwei Feldern:

start - der Beginn des ID-Bereichs für diesen Benutzer oder diese Gruppe, als int
range - der ID-Bereich für diesen Benutzer oder diese Gruppe, als int

podman_host_directories:
  "/var/lib/db":
    mode: "0777"
    owner: "{{ 1001 + podman_subuid_info['dbuser']['start'] - 1 }}"
    group: "{{ 1001 + podman_subgid_info['dbgroup']['start'] - 1 }}"

Dabei ist 1001 die UID für den Benutzer dbuser und 1001 die GID für die Gruppe dbgroup.

HINWEIS: Abhängig von dem Namespace, der von Ihren Containern verwendet wird, können Sie möglicherweise die SubUID- und SubGID-Informationen, die von getsubids bereitgestellt werden, wenn verfügbar, oder direkt aus den Dateien /etc/subuid und /etc/subgid auf dem Host stammen, verwenden. Weitere Informationen finden Sie unter Podman-Benutzernamensräume-Modi.

Beispiel-Playbooks

Rootlosen Container mit Volumen-Mount erstellen:

- name: Manage podman containers and services
  hosts: all
  vars:
    podman_create_host_directories: true
    podman_firewall:
      - port: 8080-8081/tcp
        state: enabled
      - port: 12340/tcp
        state: enabled
    podman_selinux_ports:
      - ports: 8080-8081
        setype: http_port_t
    podman_kube_specs:
      - state: started
        run_as_user: dbuser
        run_as_group: dbgroup
        kube_file_content:
          apiVersion: v1
          kind: Pod
          metadata:
            name: db
          spec:
            containers:
              - name: db
                image: quay.io/db/db:stable
                ports:
                  - containerPort: 1234
                    hostPort: 12340
                volumeMounts:
                  - mountPath: /var/lib/db:Z
                    name: db
            volumes:
              - name: db
                hostPath:
                  path: /var/lib/db
      - state: started
        run_as_user: webapp
        run_as_group: webapp
        kube_file_src: /path/to/webapp.yml
  roles:
    - linux-system-roles.podman

Container erstellen, der als Root mit Podman-Volumen ausgeführt wird:

- name: Manage podman root containers and services
  hosts: all
  vars:
    podman_firewall:
      - port: 8080/tcp
        state: enabled
    podman_kube_specs:
      - state: started
        kube_file_content:
          apiVersion: v1
          kind: Pod
          metadata:
            name: ubi8-httpd
          spec:
            containers:
              - name: ubi8-httpd
                image: registry.access.redhat.com/ubi8/httpd-24
                ports:
                  - containerPort: 8080
                    hostPort: 8080
                volumeMounts:
                  - mountPath: /var/www/html:Z
                    name: ubi8-html
            volumes:
              - name: ubi8-html
                persistentVolumeClaim:
                  claimName: ubi8-html-volume
  roles:
    - linux-system-roles.podman

Quadlet-Anwendung mit Geheimnissen erstellen. Der Start der Anwendung wird verschoben, bis alle Einheiten erstellt wurden. Beachten Sie, dass die Reihenfolge der Dateien in podman_quadlet_specs in Abhängigkeitsreihenfolge ist. Die Verwendung von podman_create_host_directories: true erstellt alle gehosteten Verzeichnisse, die in einer Volume=-Direktive in der Containerspezifikation angegeben sind.

podman_create_host_directories: true
podman_activate_systemd_unit: false
podman_quadlet_specs:
  - name: quadlet-demo
    type: network
    file_content: |
      [Network]
      Subnet=192.168.30.0/24
      Gateway=192.168.30.1
      Label=app=wordpress
  - file_src: quadlet-demo-mysql.volume
  - template_src: quadlet-demo-mysql.container.j2
  - file_src: envoy-proxy-configmap.yml
  - file_src: quadlet-demo.yml
  - file_src: quadlet-demo.kube
    activate_systemd_unit: true
podman_firewall:
  - port: 8000/tcp
    state: enabled
  - port: 9000/tcp
    state: enabled
podman_secrets:
  - name: mysql-root-password-container
    state: present
    skip_existing: true
    data: "{{ root_password_from_vault }}"
  - name: mysql-root-password-kube
    state: present
    skip_existing: true
    data: |
      apiVersion: v1
      data:
        password: "{{ root_password_from_vault | b64encode }}"
      kind: Secret
      metadata:
        name: mysql-root-password-kube
  - name: envoy-certificates
    state: present
    skip_existing: true
    data: |
      apiVersion: v1
      data:
        certificate.key: {{ key_from_vault | b64encode }}
        certificate.pem: {{ cert_from_vault | b64encode }}
      kind: Secret
      metadata:
        name: envoy-certificates