Podman

Ta rola zarządza konfiguracją podman, kontenerami oraz usługami systemd, które uruchamiają kontenery podman.

Wymagania

Rola wymaga wersji podman 4.2 lub nowszej. Rola wymaga wersji podman 4.4 lub nowszej dla wsparcia quadlet oraz sekretów. Rola wymaga wersji podman 4.5 lub nowszej dla wsparcia sprawdzania kondycji (obsługiwane tylko przy użyciu typów kontenerów quadlet).

Wymagania dotyczące zbiorów

Rola wymaga następujących zbiorów:

• containers.podman
• fedora.linux_system_roles

Aby zainstalować zbiory, użyj następującego polecenia:

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

Użytkownicy, grupy, subuid, subgid

Użytkownicy i grupy podane w podman_run_as_user, podman_run_as_group, oraz podane w specyfikacji kube jako run_as_user i run_as_group mają następujące ograniczenia:

• Muszą już istnieć w systemie - rola nie utworzy użytkowników ani grup - rola zakończy działanie z błędem, jeśli podany użytkownik lub grupa nie istnieje.
• Muszą już istnieć w /etc/subuid i /etc/subgid lub być zapewnione przez system zarządzania tożsamością - rola zakończy działanie z błędem, jeśli podany użytkownik nie jest obecny w /etc/subuid, lub jeśli podana grupa nie jest w /etc/subgid. Rola używa getsubids, aby sprawdzić użytkownika i grupę, jeśli to możliwe, lub sprawdza pliki bezpośrednio, jeśli getsubids nie jest dostępne.

Zmienne roli

podman_kube_specs

Jest to lista. Każdy element listy to dict opisujący podman pod oraz odpowiadającą jednostkę systemd do zarządzania. Format dict jest głównie podobny do modułu podman_play z wyjątkiem następujących:

• state - domyślnie created. Może przyjmować 3 wartości:
  • started - Tworzy pod i usługi systemd oraz uruchamia je
  • created - Tworzy pod i usługi systemd, ale ich nie uruchamia
  • absent - Usuwa pod i usługi systemd
• run_as_user - Użyj tego do określenia użytkownika dla danego podu. Jeśli tego nie określisz, użyta zostanie globalna wartość domyślna podman_run_as_user. W przeciwnym razie użyty zostanie root. UWAGA: Użytkownik musi istnieć - rola go nie utworzy. Użytkownik musi być obecny w /etc/subuid.
• run_as_group - Użyj tego do określenia grupy dla danego podu. Jeśli tego nie określisz, użyta zostanie globalna wartość domyślna podman_run_as_group. W przeciwnym razie użyty zostanie root. UWAGA: Grupa musi już istnieć - rola jej nie utworzy. Grupa musi być obecna w /etc/subgid.
• systemd_unit_scope - Zakres do użycia dla jednostki systemd. Jeśli tego nie określisz, użyty zostanie globalny domyślny podman_systemd_unit_scope. W przeciwnym razie, dla kontenerów typu root będzie to system, a dla kontenerów użytkownika user.
• activate_systemd_unit - Określa, czy aktywować jednostkę systemd po jej utworzeniu. Jeśli tego nie określisz, użyta zostanie globalna wartość domyślna podman_activate_systemd_unit, która domyślnie wynosi true.
• pull_image - Upewnij się, że obraz jest pobierany przed użyciem. Jeśli tego nie określisz, użyta zostanie globalna wartość domyślna podman_pull_image, która domyślnie wynosi true.
• continue_if_pull_fails - Jeśli pobieranie obrazu zakończyło się niepowodzeniem, nie traktuj tego jako błąd krytyczny i kontynuuj działanie roli. Jeśli tego nie określisz, użyta zostanie globalna wartość domyślna podman_continue_if_pull_fails, która domyślnie wynosi false.
• kube_file_src - To jest nazwa pliku na nodzie kontrolera, który zostanie skopiowany do kube_file na zarządzanym nodzie. Jest to plik w formacie YAML Kubernetes. Nie określaj tego, jeśli określiłeś kube_file_content. kube_file_content ma pierwszeństwo przed kube_file_src.
• kube_file_content - To jest albo ciąg w formacie YAML Kubernetes, albo dict w formacie YAML Kubernetes. Zostanie użyte jako zawartość kube_file na zarządzanym nodzie. Nie określaj tego, jeśli określiłeś kube_file_src. kube_file_content ma pierwszeństwo przed kube_file_src.
• kube_file - To jest nazwa pliku na zarządzanym nodzie, który zawiera specyfikację Kubernetes kontenera/podu. Zwykle nie musisz tego specyfikować, chyba że chcesz w jakiś sposób skopiować ten plik na zarządzany node poza rolą. Jeśli określisz kube_file_src lub kube_file_content, nie musisz tego określać. Zdecydowanie zaleca się pominięcie kube_file i zamiast tego określenie kube_file_src lub kube_file_content i pozwolenie roli na zarządzanie ścieżką i nazwą pliku.
  • Nazwa pliku będzie wartością metadata.name z YAML K8s, z dołączonym sufiksem .yml.
  • Katalog będzie /etc/containers/ansible-kubernetes.d dla usług systemowych.
  • Katalog będzie $HOME/.config/containers/ansible-kubernetes.d dla usług użytkownika.

Na przykład, jeśli masz:

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

To zostanie skopiowane do pliku /etc/containers/ansible-kubernetes.d/myappname.yml na zarządzanym nodzie.

podman_quadlet_specs

Lista specyfikacji Quadlet. Specyfikacja quadlet jest unikalnie identyfikowana przez nazwę i typ, gdzie typ jest jednym z typów jednostek, takich jak kontener, kube, sieć, wolumin itp. Możesz jawnie przekazać name i type, lub name i type będą wyprowadzane z nazwy pliku podanego w file, file_src lub template_src.

Domyślnie pliki będą kopiowane do lub tworzone w /etc/containers/systemd/$name.$type dla kontenerów root i $HOME/.config/containers/systemd/$name.$type dla kontenerów bezrootowych na zarządzanym nodzie. Możesz zapewnić inną lokalizację, używając file, ale wtedy prawdopodobnie będziesz musiał zmienić konfigurację systemd, aby znaleźć plik, co nie jest wspierane przez tę rolę.

Gdy specyfikacja quadlet zależy od innego pliku, np. quadlet.kube zależącego od pliku YAML lub ConfigMap, to ten plik musi być określony w liście podman_quadlet_specs wcześniej niż plik, który go używa. Na przykład, jeśli masz plik my-app.kube:

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

W takim przypadku musisz określić my-app-config.yml i my-app.yml przed my-app.kube:

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

Większość parametrów dla każdej specyfikacji quadlet jest taka sama jak dla podman_kube_spec, z wyjątkiem tego, że parametry *kube* nie są wspierane, a są następujące:

• name - Nazwa jednostki. Jeśli nie jest podana, zostanie wyprowadzona z file, file_src lub template_src. Na przykład, jeśli podasz file_src: /path/to/my-container.container, nazwa będzie my-container.
• type - Typ jednostki (kontener, kube, wolumin itp.). Jeśli nie jest podany, zostanie wyprowadzona z file, file_src lub template_src. Na przykład, jeśli podasz file_src: /path/to/my-container.container, typ będzie kontener. Jeśli wyprowadzony typ nie jest uznawany za ważny typ quadlet, na przykład, jeśli podasz file_src: my-kube.yml, wówczas zostanie po prostu skopiowany i nie będzie przetwarzany jako specyfikacja quadlet.
• file_src - Nazwa pliku na nodzie kontrolera, który ma zostać skopiowany na zarządzany node i użyty jako źródło jednostki quadlet. Jeśli ten plik jest w formacie jednostki quadlet i ma prawidłowy sufiks jednostki quadlet, zostanie użyty jako jednostka quadlet, w przeciwnym razie zostanie po prostu skopiowany.
• file - Nazwa pliku na zarządzanym nodzie, który ma być używany jako źródło jednostki quadlet. Jeśli ten plik jest w formacie jednostki quadlet i ma prawidłowy sufiks jednostki quadlet, zostanie użyty jako jednostka quadlet, w przeciwnym razie będzie traktowany jako zwykły plik.
• file_content - Zawartość pliku, która ma zostać skopiowana na zarządzany node, w formacie string. Jest to przydatne do przekazywania krótkich plików, które można łatwo określić w linii. Należy również określić name i type.
• template_src - Nazwa pliku na nodzie kontrolera, który zostanie przetworzony jako plik szablonu Jinja, a następnie skopiowany na zarządzany node jako źródło jednostki quadlet. Jeśli ten plik jest w formacie jednostki quadlet i ma prawidłowy sufiks jednostki quadlet, zostanie użyty jako jednostka quadlet, w przeciwnym razie zostanie po prostu skopiowany. Jeśli plik ma sufiks .j2, ten sufiks zostanie usunięty, aby określić typ pliku quadlet.

Na przykład, jeśli określisz:

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

Wtedy lokalny plik templates/my-app.container.j2 zostanie przetworzony jako plik szablonu Jinja, a następnie skopiowany do /etc/containers/systemd/my-app.container jako specyfikacja jednostki kontenera quadlet na zarządzanym nodzie.

UWAGA: Podczas usuwania quadletów musisz usunąć sieci na końcu. Nie możesz usunąć sieci, która jest używana przez kontener.

podman_secrets

Jest to lista specyfikacji sekretów, w prawie tym samym formacie, co używany przez podman_secret. Jest dodatkowe pole:

• run_as_user - Użyj tego, aby określić sekret dla konkretnego użytkownika. Jeśli tego nie określisz, użyta zostanie globalna wartość domyślna podman_run_as_user. W przeciwnym razie użyty zostanie root. UWAGA: Użytkownik musi już istnieć - rola go nie utworzy.

Zaleca się korzystanie z Ansible Vault w celu zaszyfrowania wartości pola data.

podman_create_host_directories

Jest to wartość logiczna, wartość domyślna to false. Jeśli true, rola zapewni, że katalogi hosta podane w montażach hosta w specyfikacjach volumes.hostPath w YAML Kubernetes podanym w podman_kube_specs, oraz z konfiguracji Volume w specyfikacji kontenera quadlet, gdzie określona jest ścieżka hosta. UWAGA: Katalogi muszą być określone jako ścieżki bezwzględne (dla kontenerów root) lub ścieżki względne do katalogu domowego (dla kontenerów bezrootowych), aby rola mogła nimi zarządzać. Wszystko inne będzie traktowane jako inny rodzaj woluminu i zostanie zignorowane. Rola zastosuje swoje domyślne własność/prawa do katalogów. Jeśli musisz ustawić własność/prawa, zobacz podman_host_directories.

podman_host_directories

To jest dict. Używając podman_create_host_directories, to mówi roli, jakie uprawnienia/własność należy zastosować do automatycznie tworzonych katalogów hosta. Każdy klucz to bezwzględna ścieżka katalogu hosta do zarządzania. Wartość jest w formacie parametrów dla modułu file. Jeśli nie podasz wartości, rola użyje swoich wbudowanych wartości domyślnych. Jeśli chcesz określić wartość, która ma być stosowana do wszystkich katalogów hosta, użyj specjalnego klucza DEFAULT.

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

Rola użyje dbuser:dbgroup 0600 dla /var/lib/data, a dla wszystkich innych katalogów hosta utworzonych przez rolę użyje root:root 0644.

podman_firewall

To jest lista dict, w tym samym formacie co używany przez rolę fedora.linux_system_roles.firewall. Użyj tego, aby określić porty, którymi chcesz, aby rola zarządzała w zaporze.

podman_firewall:
  - port: 8080/tcp

podman_selinux_ports

To jest lista dict, w tym samym formacie co używany przez rolę fedora.linux_system_roles.selinux. Użyj tego, jeśli chcesz, aby rola zarządzała polityką SELinux dla portów używanych przez rolę.

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

podman_run_as_user

To jest nazwa użytkownika, który ma być używany dla wszystkich kontenerów bezrootowych. Możesz także określić nazwę użytkownika dla konkretnego kontenera za pomocą run_as_user w podman_kube_specs. UWAGA: Użytkownik musi już istnieć - rola go nie utworzy. Użytkownik musi być obecny w /etc/subuid.

podman_run_as_group

To jest nazwa grupy, która ma być używana dla wszystkich kontenerów bezrootowych. Możesz także określić nazwę grupy dla konkretnego kontenera za pomocą run_as_group w podman_kube_specs. UWAGA: Grupa musi już istnieć - rola jej nie utworzy. Grupa musi być obecna w /etc/subgid.

podman_systemd_unit_scope

To jest domyślny zasięg systemd do użycia dla wszystkich jednostek systemd. Możesz także określić zasięg dla konkretnego kontenera za pomocą systemd_unit_scope w podman_kube_specs. Domyślnie kontenery bezrootowe użyją user, a kontenery root użyją system.

podman_activate_systemd_units

Aktywuje każdą jednostkę systemd, gdy zostanie utworzona. Domyślna wartość to true. Możesz także to zrobić w przypadku konkretnej jednostki, używając activate_systemd_units w specyfikacji każdej jednostki. Na przykład, jeśli wdrażasz kilka specyfikacji i chcesz, aby tylko ostatnia z listy została aktywowana, co spowoduje aktywację pozostałych przez zależności, ustaw activate_systemd_unit: false dla każdej z nich, poza ostatnią, która używa activate_systemd_unit: true. UWAGA: jednostki quadlet są automatycznie włączone przy tworzeniu - nie można obecnie używać activate_systemd_unit, aby je wyłączyć - możesz użyć activate_systemd_unit, aby stworzyć jednostki zatrzymane lub uruchomione.

podman_pull_image

Upewnij się, że każdy obraz wymieniony w specyfikacji kube lub quadlet jest obecny, pobierając obraz przed jego użyciem. Domyślna wartość to true. Użyj false, jeśli zarządzany node już ma odpowiednią wersję lub nie jest w stanie pobrać obrazów. Możesz także określić to indywidualnie dla jednostki za pomocą pull_image.

podman_continue_if_pull_fails

Jeśli próba pobrania obrazu zakończy się niepowodzeniem, nie traktuj tego jako błąd krytyczny i kontynuuj działanie roli. Domyślna wartość to false - niepowodzenie próby pobrania to błąd krytyczny. Możesz to ustawić indywidualnie dla jednostki, używając continue_if_pull_fails.

podman_containers_conf

To są ustawienia containers.conf(5), podane jako dict. Te ustawienia zostaną podane w pliku dystrybucji w katalogu containers.conf.d. Jeśli działasz jako root (zobacz podman_run_as_user), zostaną zarządzane ustawienia systemowe, w przeciwnym razie zostaną zarządzane ustawienia użytkownika. Zobacz stronę podręcznika dla lokalizacji katalogów.

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

podman_registries_conf

To są ustawienia containers-registries.conf(5), podane jako dict. Te ustawienia zostaną podane w pliku dystrybucji w katalogu registries.conf.d. Jeśli działasz jako root (zobacz podman_run_as_user), zostaną zarządzane ustawienia systemowe, w przeciwnym razie zostaną zarządzane ustawienia użytkownika. Zobacz stronę podręcznika dla lokalizacji katalogów.

podman_registries_conf:
  aliases:
    myregistry: registry.example.com

podman_storage_conf

To są ustawienia containers-storage.conf(5), podane jako dict. Jeśli działasz jako root (zobacz podman_run_as_user), zostaną zarządzane ustawienia systemowe, w przeciwnym razie zostaną zarządzane ustawienia użytkownika. Zobacz stronę podręcznika dla lokalizacji plików.

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

podman_policy_json

To są ustawienia containers-policy.json(5), podane jako dict. Jeśli działasz jako root (zobacz podman_run_as_user), zostaną zarządzane ustawienia systemowe, w przeciwnym razie zostaną zarządzane ustawienia użytkownika. Zobacz stronę podręcznika dla lokalizacji plików.

podman_policy_json:
  default:
    type: insecureAcceptAnything

podman_use_copr (EKSPERYMENTALNE)

Wartość logiczna - domyślnie nie ustawiona - jeśli chcesz włączyć repozytorium copr, aby używać najnowszej wersji rozwojowej podman, użyj podman_use_copr: true.

podman_fail_if_too_old (EKSPERYMENTALNE)

Wartość logiczna - domyślnie nie ustawiona - domyślnie rola zakończy działanie z błędem, jeśli używasz starszej wersji podman i próbujesz użyć funkcji obsługiwanej tylko w nowszej wersji. Na przykład jeśli spróbujesz zarządzać quadletami lub sekretami za pomocą podman 4.3 lub starszego, rola zakończy działanie z błędem. Jeśli chcesz, aby rola została pominięta, użyj podman_fail_if_too_old: false.

podman_registry_username

Ciąg - domyślna wartość nie ustawiona - nazwa użytkownika do użycia do autoryzacji w rejestrze. Musisz także ustawić podman_registry_password. Możesz to nadpisać na podstawie specyfikacji z registry_username. Użycie container_image_user było nieobsługiwane i jest przestarzałe.

podman_registry_password

Ciąg - domyślna wartość nie ustawiona - hasło do użycia do autoryzacji w rejestrze. Musisz także ustawić podman_registry_username. Możesz to nadpisać na podstawie specyfikacji z registry_password. Użycie container_image_password było nieobsługiwane i jest przestarzałe.

podman_credential_files

To jest lista. Każdy element listy to dict opisujący plik poświadczeń podman używany do autoryzacji w rejestrach. Zobacz man containers-auth.json i man containers-registries.conf:credential-helpers dla więcej informacji na temat formatu tych plików i domyślnej ścieżki wyszukiwania katalogów. UWAGA: Te pliki zawierają poświadczenia autoryzacji. Proszę zachować ostrożność. Zdecydowanie zaleca się korzystanie z Ansible Vault w celu ich zaszyfrowania. Klucze każdego dict są następujące:

• state - domyślnie present. Użyj absent, aby usunąć pliki.
• file_src - To jest nazwa pliku na nodzie kontrolera, który zostanie skopiowany do file na zarządzanym nodzie. Nie określaj tego, jeśli określasz file_content lub template_src, które będą miały pierwszeństwo przed file_src.
• template_src - To jest nazwa pliku na nodzie kontrolera, który zostanie przetworzony za pomocą modułu template i skopiowany do file na zarządzanym nodzie. Nie określaj tego, jeśli określasz file_content lub file_src.
• file_content - To jest ciąg w formacie containers-auth.json. Zostanie użyte jako zawartość file na zarządzanym nodzie. Nie określaj tego, jeśli określasz file_src lub template_src.
• file - To jest nazwa pliku na zarządzanym nodzie, która będzie zawierać zawartość auth.json. Wartość domyślna to $HOME/.config/containers/auth.json. Jeśli określasz ścieżkę względną, będzie ona względna do $HOME/.config/containers. Jeśli określasz coś innego niż domyślne wartości wymienione w man containers-auth.json, będziesz także musiał skonfigurować credential-helpers w containers-registries.conf przy użyciu podman_registries_conf. Każdy brakujący katalog nadrzędny będzie tworzony.
• run_as_user - Użyj tego do określenia właściciela pliku dla konkretnego pliku poświadczeń. Jeśli tego nie określisz, użyta zostanie globalna wartość domyślna podman_run_as_user. W przeciwnym razie użyty zostanie root. UWAGA: Użytkownik musi już istnieć - rola go nie utworzy. Użytkownik musi być obecny w /etc/subuid. UWAGA: To jest używane jako użytkownik dla katalogu $HOME, jeśli file nie jest określony, a także jako właściciel pliku. Jeśli chcesz, aby właściciel pliku był inny niż użytkownik używany dla $HOME, określ file jako ścieżkę bezwzględną.
• run_as_group - Użyj tego do określenia grupy pliku poświadczeń. Jeśli tego nie określisz, użyta zostanie globalna wartość domyślna podman_run_as_group. W przeciwnym razie użyty zostanie root. UWAGA: Grupa musi już istnieć - rola jej nie utworzy. Grupa musi być obecna w /etc/subgid.
• mode - Uprawnienia pliku - domyślnie "0600".

Na przykład, jeśli masz:

    podman_credential_files:
      - file_src: auth.json
        run_as_user: my_user

Lokalny plik auth.json zostanie znaleziony w zwykłych ścieżkach wyszukiwania plików Ansible i zostanie skopiowany do pliku /home/my_user/.config/containers/auth.json na zarządzanym nodzie. Właścicielem pliku będzie my_user, a jego uprawnienia będą "0600". Katalogi /home/my_user/.config i /home/my_user/.config/containers zostaną utworzone, jeśli nie istnieją.

podman_registry_certificates

Ta zmienna jest listą elementów dict, które pozwalają zarządzać certyfikatami TLS i kluczami używanymi do połączeń z rejestrami. Katalogi, formaty i pliki są opisane w man containers-certs.d. Nazwy kluczy używanych do certyfikatów i kluczy TLS podążają za konwencjami nazewnictwa TLS systemów ról. UWAGA: prefiks client_ został pominięty dla cert i private_key, ponieważ w tym kontekście są tylko klienci.

UWAGA: Zdecydowanie zaleca się korzystanie z Ansible Vault w celu zaszyfrowania kluczy prywatnych i wszelkich innych wrażliwych wartości.

Klucze każdego dict są następujące:

• state - domyślnie present. Użyj absent, aby usunąć pliki.
• run_as_user - To jest użytkownik, który będzie właścicielem plików, i jest używany do znajdowania katalogu $HOME dla plików. Jeśli tego nie określisz, użyta zostanie globalna wartość domyślna podman_run_as_user. W przeciwnym razie użyty zostanie root.
• run_as_group - To jest grupa, która będzie właścicielem plików. Jeśli tego nie określisz, użyta zostanie globalna wartość domyślna podman_run_as_group. W przeciwnym razie użyty zostanie root.
• registry_host - Wymagane - nazwa hosta lub hostname:port rejestru. Będzie to używane jako nazwa katalogu w $HOME/.config/containers/certs.d (dla kontenerów bezrootowych) lub /etc/containers/certs.d (dla kontenerów systemowych), który będzie przechowywał certyfikaty i klucze. Jeśli podczas używania state: absent wszystkie pliki zostaną usunięte, katalog zostanie usunięty.
• cert - nazwa pliku w katalogu certs.d, który zawiera certyfikat TLS klienta. Jeśli nie jest określona, użyj nazwy podstawowej cert_src. Jeśli ta nie jest określona, użyj client.cert.
• private_key - nazwa pliku w katalogu certs.d, który zawiera prywatny klucz TLS klienta. Jeśli nie jest określona, użyj nazwy podstawowej private_key_src. Jeśli ta nie jest określona, użyj client.key.
• ca_cert - nazwa pliku w katalogu certs.d, który zawiera certyfikat CA TLS. Jeśli nie jest określona, użyj nazwy podstawowej ca_cert_src. Jeśli ta nie jest określona, użyj ca.crt.
• cert_src - nazwa pliku na nodzie kontrolera, który ma zostać skopiowany do cert.
• private_key_src - nazwa pliku na nodzie kontrolera, który ma zostać skopiowany do private_key.
• ca_cert_src - nazwa pliku na nodzie kontrolera, który ma zostać skopiowany do ca_cert.
• cert_content - zawartość certyfikatu do skopiowania do cert.
• private_key_content - zawartość klucza prywatnego do skopiowania do private_key.

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

To stworzy katalog /etc/containers/certs.d/quay.io:5000/, skopiuje lokalny plik client.cert, znaleziony w zwykłych ścieżkach wyszukiwania plików Ansible, do /etc/containers/certs.d/quay.io:5000/client.cert, skopiuje zawartość zaszyfrowanego private_key_content z Ansible Vault do /etc/containers/certs.d/quay.io:5000/client.key, oraz skopiuje lokalny plik ca.crt, znaleziony w zwykłych ścieżkach wyszukiwania plików Ansible, do /etc/containers/certs.d/quay.io:5000/ca.crt.

podman_validate_certs

Wartość logiczna - domyślnie jest pusta - użyj tego, aby kontrolować, czy podczas pobierania obrazów z rejestrów będzie walidowane certyfikaty TLS. Domyślne null oznacza, że użyje tego, co jest domyślnie używane przez moduł containers.podman.podman_image. Możesz to nadpisać na podstawie specyfikacji, używając validate_certs.

podman_prune_images

Wartość logiczna - domyślna wartość to false - domyślnie rola nie będzie sprzątała nieużywanych obrazów podczas usuwania quadletów i innych zasobów. Ustaw tę wartość na true, aby polecić roli usunięcie nieużywanych obrazów podczas sprzątania.

podman_transactional_update_reboot_ok

Ta zmienna ma zastosowanie tylko w systemach aktualizacji transakcyjnych. Jeśli transakcyjna aktualizacja wymaga ponownego uruchomienia, rola kontynuuje ponowne uruchomienie, jeśli podman_transactional_update_reboot_ok jest ustawione na true. Jeśli ustawione na false, rola powiadomi użytkownika, że wymagane jest ponowne uruchomienie, co umożliwia dostosowane obsłużenie wymogu ponownego uruchamiania. Jeśli ta zmienna nie jest ustawiona, rola zakończy działanie, aby upewnić się, że wymóg ponownego uruchomienia nie zostanie przeoczony. Dla systemów aktualizacji niekonsolidacyjnych ta zmienna jest ignorowana.

Zmienne udostępniane przez rolę

podman_version

To jest ciąg wersji używanej przez podman. Możesz to zazwyczaj wykorzystać w swoich szablonach. Na przykład, jeśli chcesz określić template_src quadlet dla kontenera i mieć możliwość korzystania z monitoringów i sekretów, jeśli używasz podman 4.5 lub nowszego:

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

Rola musi zapewnić, że wszyscy użytkownicy i grupy są obecne w informacji subuid i subgid. Gdy już wyodrębni te dane, będą one dostępne w podman_subuid_info i podman_subgid_info. To są dict. Klucz to nazwa użytkownika lub grupy, a wartość to dict z dwoma polami:

• start - początek zakresu id dla danego użytkownika lub grupy, jako int
• range - zakres id dla danego użytkownika lub grupy, jako 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 }}"

Gdzie 1001 jest uid dla użytkownika dbuser, a 1001 jest gid dla grupy dbgroup.

UWAGA: w zależności od przestrzeni nazw używanej przez twoje kontenery, możesz nie być w stanie używać informacji subuid i subgid, które pochodzą z getsubids, jeśli są dostępne, lub bezpośrednio z plików /etc/subuid i /etc/subgid na hoście. Zobacz tryby przestrzeni nazw użytkownika podman dla dalszych informacji.

Przykładowe playbooki

Utwórz kontener bezrootowy z montażem woluminu:

- name: Zarządzaj kontenerami i usługami podman
  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

Utwórz kontener działający jako root z woluminem Podman:

- name: Zarządzaj kontenerami root i usługami
  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

Utwórz aplikację quadlet z sekretami. Odłóż rozpoczęcie aplikacji, aż wszystkie jednostki zostaną utworzone. Zauważ, że kolejność plików w podman_quadlet_specs jest uporządkowana według zależności. Użycie podman_create_host_directories: true utworzy wszelkie katalogi hosta montowane, określone przez dyrektywę Volume= w specyfikacji kontenera.

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

Licencja

MIT.

Informacje o autorze

Na podstawie podman-container-systemd autorstwa Ilkka Tengvall ilkka.tengvall@iki.fi.

Autorzy: Thom Carlin, Rich Megginson, Adam Miller, Valentin Rothberg