podman

Ce rôle gère la configuration de podman, les conteneurs et les services systemd qui exécutent les conteneurs podman.

Exigences

Le rôle nécessite podman version 4.2 ou supérieure.
Le rôle nécessite podman version 4.4 ou supérieure pour le support de quadlet et de secret.
Le rôle nécessite podman version 4.5 ou supérieure pour le support des vérifications de santé (uniquement pris en charge lors de l'utilisation de types de conteneurs quadlet).

Exigences de collection

Le rôle nécessite les collections suivantes :

• containers.podman
• fedora.linux_system_roles

Utilisez ceci pour installer les collections :

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

Utilisateurs, groupes, subuid, subgid

Les utilisateurs et groupes spécifiés dans podman_run_as_user, podman_run_as_group, et dans une spécification kube comme run_as_user et run_as_group ont les restrictions suivantes :

• Ils doivent déjà exister sur le système - le rôle ne créera pas les utilisateurs ou groupes - le rôle sortira avec une erreur si un utilisateur ou groupe non existant est spécifié.
• Ils doivent déjà exister dans /etc/subuid et /etc/subgid, ou être fournis par votre système de gestion d'identité - le rôle sortira avec une erreur si un utilisateur spécifié n'est pas présent dans /etc/subuid, ou si un groupe spécifié n'est pas dans /etc/subgid. Le rôle utilise getsubids pour vérifier l'utilisateur et le groupe si disponible, ou vérifie les fichiers directement si getsubids n'est pas disponible.

Variables de rôle

podman_kube_specs

Ceci est une liste. Chaque élément de la liste est un dict décrivant un pod podman et une unité systemd correspondante à gérer. Le format du dict est principalement comme le module podman_play sauf pour les éléments suivants :

• state - la valeur par défaut est created. Cela prend 3 valeurs :
  • started - Créer les pods et les services systemd, et commencer à les exécuter
  • created - Créer les pods et les services systemd, mais ne pas les démarrer
  • absent - Supprimer les pods et les services systemd
• run_as_user - Utilisez ceci pour spécifier un utilisateur par pod. Si vous ne spécifiez pas cela, la valeur par défaut globale podman_run_as_user sera utilisée. Sinon, root sera utilisé. REMARQUE : L'utilisateur doit déjà exister - le rôle ne créera pas un. L'utilisateur doit être présent dans /etc/subuid.
• run_as_group - Utilisez ceci pour spécifier un groupe par pod. Si vous ne spécifiez pas cela, la valeur par défaut globale podman_run_as_group sera utilisée. Sinon, root sera utilisé. REMARQUE : Le groupe doit déjà exister - le rôle ne créera pas un. Le groupe doit être présent dans /etc/subgid.
• systemd_unit_scope - La portée à utiliser pour l'unité systemd. Si vous ne spécifiez pas cela, la portée par défaut globale podman_systemd_unit_scope sera utilisée. Sinon, la portée sera system pour les conteneurs root, et user pour les conteneurs utilisateurs.
• activate_systemd_unit - Que ce soit ou non d'activer l'unité systemd lorsqu'elle est créée. Si vous ne spécifiez pas cela, la valeur par défaut globale podman_activate_systemd_unit sera utilisée, qui est true par défaut.
• pull_image - Assurez-vous que l'image est tirée avant utilisation. Si vous ne spécifiez pas cela, la valeur par défaut globale podman_pull_image sera utilisée, qui est true par défaut.
• continue_if_pull_fails - Si le tirage de l'image échoue, ne pas considérer cela comme une erreur fatale et continuer avec le rôle. Si vous ne spécifiez pas cela, la valeur par défaut globale podman_continue_if_pull_fails sera utilisée, qui est false par défaut.
• kube_file_src - Ceci est le nom d'un fichier sur le nœud contrôleur qui sera copié dans kube_file sur le nœud géré. C'est un fichier au format YAML Kubernetes. Ne spécifiez pas ceci si vous spécifiez kube_file_content. kube_file_content a la priorité sur kube_file_src.
• kube_file_content - Ceci est soit une chaîne au format YAML Kubernetes, soit un dict au format YAML Kubernetes. Il sera utilisé comme contenu de kube_file sur le nœud géré. Ne spécifiez pas ceci si vous spécifiez kube_file_src. kube_file_content a la priorité sur kube_file_src.
• kube_file - Ceci est le nom d'un fichier sur le nœud géré qui contient la spécification Kubernetes du conteneur/pod. Vous n'avez généralement pas à spécifier ceci à moins que vous ayez besoin de copier ce fichier sur le nœud géré en dehors du rôle. Si vous spécifiez soit kube_file_src soit kube_file_content, vous n'avez pas à spécifier cela. Il est fortement recommandé de ne pas inclure kube_file et de plutôt spécifier soit kube_file_src soit kube_file_content et de laisser le rôle gérer le chemin et le nom du fichier.
  • Le nom de fichier sera la valeur metadata.name du YAML K8s, avec un suffixe .yml ajouté.
  • Le répertoire sera /etc/containers/ansible-kubernetes.d pour les services système.
  • Le répertoire sera $HOME/.config/containers/ansible-kubernetes.d pour les services utilisateurs.

Par exemple, si vous avez

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

Cela sera copié dans le fichier /etc/containers/ansible-kubernetes.d/myappname.yml sur le nœud géré.

podman_quadlet_specs

Liste de spécifications Quadlet. Une spécification quadlet est identifiée de manière unique par un nom et un type, où le type est l'un des types d'unités comme conteneur, kube, réseau, volume, etc. Vous pouvez soit passer name et type explicitement, soit le name et le type seront dérivés du nom de fichier donné dans file, file_src, ou template_src.

Par défaut, les fichiers seront copiés ou créés dans /etc/containers/systemd/$name.$type pour les conteneurs root, et $HOME/.config/containers/systemd/$name.$type pour les conteneurs sans privilèges, sur le nœud géré. Vous pouvez fournir un emplacement différent en utilisant file, mais vous devrez probablement modifier la configuration systemd pour trouver le fichier, ce qui n'est pas pris en charge par ce rôle.

Lorsque une spécification quadlet dépend d'un autre fichier par exemple un quadlet.kube qui dépend du fichier Yaml ou d'un ConfigMap, ce fichier doit être spécifié dans la liste podman_quadlet_specs avant le fichier qui l'utilise. Par exemple, si vous avez un fichier my-app.kube :

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

Alors vous devez spécifier my-app-config.yml et my-app.yml avant my-app.kube :

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

La plupart des paramètres pour chaque spécification quadlet sont les mêmes que pour podman_kube_spec ci-dessus, sauf que les paramètres *kube* ne sont pas pris en charge, et voici les suivants :

• name - Le nom de l'unité. Si non donné, il sera dérivé de file, file_src, ou template_src. Par exemple, si vous spécifiez file_src: /path/to/my-container.container, alors le name sera my-container.
• type - Le type d'unité (conteneur, kube, volume, etc.). Si non donné, il sera dérivé de file, file_src, ou template_src. Par exemple, si vous spécifiez file_src: /path/to/my-container.container, alors le type sera container. Si le type dérivé n'est pas reconnu comme un type quadlet valide, par exemple, si vous spécifiez file_src: my-kube.yml, il sera simplement copié et ne sera pas traité comme une spécification quadlet.
• file_src - Le nom du fichier sur le nœud de contrôle à copier sur le nœud géré pour utiliser comme source de l'unité quadlet. Si ce fichier est au format d'unité quadlet et possède un suffixe d'unité quadlet valide, il sera utilisé comme une unité quadlet, sinon, il sera juste copié.
• file - Le nom du fichier sur le nœud géré à utiliser comme source de l'unité quadlet. Si ce fichier est au format d'unité quadlet et possède un suffixe d'unité quadlet valide, il sera utilisé comme une unité quadlet, sinon, il sera traité comme un fichier ordinaire.
• file_content - Le contenu d'un fichier à copier sur le nœud géré, sous forme de chaîne. Cela est utile pour passer des fichiers courts qui peuvent facilement être spécifiés en ligne. Vous devez également spécifier name et type.
• template_src - Le nom du fichier sur le nœud de contrôle qui sera traité comme un fichier template Jinja puis copié sur le nœud géré pour utiliser comme source de l'unité quadlet. Si ce fichier est au format d'unité quadlet et possède un suffixe d'unité quadlet valide, il sera utilisé comme une unité quadlet, sinon, il sera simplement copié. Si le fichier a un suffixe .j2, ce suffixe sera supprimé pour déterminer le type de fichier quadlet.

Par exemple, si vous spécifiez :

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

Alors le fichier local templates/my-app.container.j2 sera traité comme un fichier modèle Jinja, puis copié sur /etc/containers/systemd/my-app.container comme une spécification d'unité de conteneur quadlet sur le nœud géré.

REMARQUE : Lors de la suppression de quadlets, vous devez supprimer les réseaux en dernier. Vous ne pouvez pas supprimer un réseau qui est utilisé par un conteneur.

podman_secrets

C'est une liste de spécifications de secrets dans presque le même format que celui utilisé par podman_secret. Il y a un champ supplémentaire :

• run_as_user - Utilisez ceci pour spécifier un secret pour un utilisateur spécifique. Si vous ne spécifiez pas cela, la valeur par défaut globale podman_run_as_user sera utilisée. Sinon, root sera utilisé. REMARQUE : L'utilisateur doit déjà exister - le rôle ne créera pas un.

Vous êtes fortement encouragé à utiliser Ansible Vault pour chiffrer la valeur du champ data.

podman_create_host_directories

C'est un booléen, la valeur par défaut est false. Si true, le rôle s'assurera que les répertoires hôtes spécifiés dans les montages hôtes dans les spécifications de volumes.hostPath dans le YAML Kubernetes donné dans podman_kube_specs, et des configurations de Volume dans la spécification de conteneur quadlet où un chemin hôte est spécifié. REMARQUE : Les répertoires doivent être spécifiés comme des chemins absolus (pour les conteneurs root), ou des chemins relatifs au répertoire personnel (pour les conteneurs non-root), afin que le rôle puisse les gérer. Tout autre chose sera supposée être une sorte de volume différent et sera ignorée. Le rôle appliquera par défaut ses propriétaires/autorisations aux répertoires. Si vous devez définir des propriétaires/autorisations, consultez podman_host_directories.

podman_host_directories

C'est un dict. Lorsque vous utilisez podman_create_host_directories, cela indique au rôle quels permissions/propriétaires appliquer aux répertoires hôtes créés automatiquement. Chaque clé est le chemin absolu du répertoire hôte à gérer. La valeur est au format des paramètres du module file. Si vous ne spécifiez pas de valeur, le rôle utilisera ses propres valeurs par défaut. Si vous souhaitez spécifier une valeur à utiliser pour tous les répertoires hôtes, utilisez la clé spéciale DEFAULT.

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

Le rôle utilisera dbuser:dbgroup 0600 pour /var/lib/data, et root:root 0644 pour tous les autres répertoires hôtes créés par le rôle.

podman_firewall

C'est une liste de dict au même format que celui utilisé par le rôle fedora.linux_system_roles.firewall. Utilisez ceci pour spécifier les ports que vous souhaitez que le rôle gère dans le pare-feu.

podman_firewall:
  - port: 8080/tcp

podman_selinux_ports

C'est une liste de dict au même format que celui utilisé par le rôle fedora.linux_system_roles.selinux. Utilisez ceci si vous souhaitez que le rôle gère la politique SELinux pour les ports utilisés par le rôle.

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

podman_run_as_user

C'est le nom de l'utilisateur à utiliser pour tous les conteneurs sans privilèges. Vous pouvez également spécifier un nom d'utilisateur par conteneur avec run_as_user dans podman_kube_specs. REMARQUE : L'utilisateur doit déjà exister - le rôle ne créera pas un. L'utilisateur doit être présent dans /etc/subuid.

podman_run_as_group

C'est le nom du groupe à utiliser pour tous les conteneurs sans privilèges. Vous pouvez également spécifier un nom de groupe par conteneur avec run_as_group dans podman_kube_specs. REMARQUE : Le groupe doit déjà exister - le rôle ne créera pas un. Le groupe doit être présent dans /etc/subgid.

podman_systemd_unit_scope

C'est la portée systemd à utiliser par défaut pour toutes les unités systemd. Vous pouvez également spécifier la portée par conteneur avec systemd_unit_scope dans podman_kube_specs. Par défaut, les conteneurs sans privilèges utiliseront user et les conteneurs root utiliseront system.

podman_activate_systemd_units

Active chaque unité systemd dès qu'elle est créée. La valeur par défaut est true. Vous pouvez également le faire au niveau de chaque unité en utilisant activate_systemd_units dans la spécification de chaque unité. Par exemple, si vous déployez plusieurs spécifications, et que vous ne souhaitez activer que la dernière de la liste, ce qui déclenchera les autres via des dépendances, alors définissez activate_systemd_unit: false pour chacune, sauf la dernière qui utilise activate_systemd_unit: true. REMARQUE : les unités quadlet sont implicitement activées lorsqu'elles sont créées - vous ne pouvez pas actuellement utiliser activate_systemd_unit pour désactiver ces unités - vous pouvez utiliser activate_systemd_unit pour créer des unités arrêtées ou démarrées.

podman_pull_image

Assurez-vous que chaque image mentionnée dans une spécification kube ou quadlet est présente en tirant l'image avant de l'utiliser. La valeur par défaut est true. Utilisez false si le nœud géré a déjà la bonne version, ou n'est pas capable de tirer des images. Vous pouvez également spécifier cela au niveau de chaque unité avec pull_image.

podman_continue_if_pull_fails

Si la tentative de tirage de l'image échoue, ne pas considérer cela comme une erreur fatale, et continuer avec l'exécution du rôle. La valeur par défaut est false - une échec de tirage est une erreur fatale. Vous pouvez définir cela au niveau de chaque unité avec continue_if_pull_fails.

podman_containers_conf

Ce sont les paramètres containers.conf(5), fournis sous forme de dict. Ces paramètres seront fournis dans un fichier d'extension dans le répertoire containers.conf.d. Si vous exécutez en tant que root (voir podman_run_as_user), les paramètres système seront gérés, sinon, les paramètres utilisateur seront gérés. Voir la page de manuel pour les emplacements des répertoires.

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

podman_registries_conf

Ce sont les paramètres containers-registries.conf(5), fournis sous forme de dict. Ces paramètres seront fournis dans un fichier d'extension dans le répertoire registries.conf.d. Si vous exécutez en tant que root (voir podman_run_as_user), les paramètres système seront gérés, sinon, les paramètres utilisateur seront gérés. Voir la page de manuel pour les emplacements des fichiers.

podman_registries_conf:
  aliases:
    myregistry: registry.example.com

podman_storage_conf

Ce sont les paramètres containers-storage.conf(5), fournis sous forme de dict. Si vous exécutez en tant que root (voir podman_run_as_user), les paramètres système seront gérés, sinon, les paramètres utilisateur seront gérés. Voir la page de manuel pour les emplacements des fichiers.

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

podman_policy_json

Ce sont les paramètres containers-policy.json(5), fournis sous forme de dict. Si vous exécutez en tant que root (voir podman_run_as_user), les paramètres système seront gérés, sinon, les paramètres utilisateur seront gérés. Voir la page de manuel pour les emplacements des fichiers.

podman_policy_json:
  default:
    type: insecureAcceptAnything

podman_use_copr (EXPÉRIMENTAL)

Booléen - valeur par défaut non définie - si vous souhaitez activer le dépôt copr pour utiliser la dernière version de développement de podman, utilisez podman_use_copr: true.

podman_fail_if_too_old (EXPÉRIMENTAL)

Booléen - valeur par défaut non définie - par défaut, le rôle échouera avec une erreur si vous utilisez une ancienne version de podman et essayez d'utiliser une fonctionnalité uniquement prise en charge par une version plus récente. Par exemple, si vous essayez de gérer quadlet ou secrets avec podman 4.3 ou antérieur, le rôle échouera avec une erreur. Si vous souhaitez que le rôle soit simplement ignoré à la place, utilisez podman_fail_if_too_old: false.

podman_registry_username

Chaîne - valeur par défaut non définie - nom d'utilisateur à utiliser pour s'authentifier au registre. Vous devez également définir podman_registry_password. Vous pouvez remplacer ceci au niveau de chaque spécification avec registry_username. L'utilisation de container_image_user n'était pas prise en charge et est obsolète.

podman_registry_password

Chaîne - valeur par défaut non définie - mot de passe à utiliser pour s'authentifier au registre. Vous devez également définir podman_registry_username. Vous pouvez remplacer ceci au niveau de chaque spécification avec registry_password. L'utilisation de container_image_password n'était pas prise en charge et est obsolète.

podman_credential_files

Ceci est une liste. Chaque élément de la liste est un dict décrivant un fichier d'identification podman utilisé pour s'authentifier aux registres. Voir man containers-auth.json et man containers-registries.conf : credential-helpers pour plus d'informations sur le format de ces fichiers et le chemin de recherche par défaut.
REMARQUE : Ces fichiers contiennent des informations d'identification d'authentification. Veuillez faire attention avec eux. Vous êtes fortement encouragé à utiliser Ansible Vault pour les chiffrer.
Les clés de chaque dict sont comme suit :

• state - la valeur par défaut est present. Utilisez absent pour supprimer des fichiers.
• file_src - Ceci est le nom d'un fichier sur le nœud contrôleur qui sera copié dans file sur le nœud géré. Ne spécifiez pas ceci si vous spécifiez file_content ou template_src, qui prendra la priorité sur file_src.
• template_src - Ceci est le nom d'un fichier sur le nœud contrôleur qui sera modélisé en utilisant le module template et copié dans file sur le nœud géré. Ne spécifiez pas ceci si vous spécifiez file_content ou file_src.
• file_content - Ceci est une chaîne au format containers-auth.json. Elle sera utilisée comme contenu de file sur le nœud géré. Ne spécifiez pas ceci si vous spécifiez file_src ou template_src.
• file - Ceci est le nom d'un fichier sur le nœud géré qui contiendra le contenu de auth.json. La valeur par défaut sera $HOME/.config/containers/auth.json. Si vous spécifiez un chemin relatif, il sera relatif à $HOME/.config/containers. Si vous spécifiez autre chose que les valeurs par défaut mentionnées dans man containers-auth.json, vous devrez également configurer credential-helpers dans containers-registries.conf en utilisant podman_registries_conf. Tous les répertoires parents manquants seront créés.
• run_as_user - Utilisez ceci pour spécifier un propriétaire de fichier par fichier d'identification. Si vous ne spécifiez pas cela, alors la valeur par défaut globale podman_run_as_user sera utilisée. Sinon, root sera utilisé. REMARQUE : L'utilisateur doit déjà exister - le rôle ne créera pas un. L'utilisateur doit être présent dans /etc/subuid. REMARQUE : Ceci est utilisé comme l'utilisateur pour le répertoire $HOME si file n'est pas spécifié, et comme propriétaire du fichier. Si vous voulez que le propriétaire du fichier soit différent de l'utilisateur utilisé pour $HOME, spécifiez file comme chemin absolu.
• run_as_group - Utilisez ceci pour spécifier un groupe de fichiers par fichier d'identification. Si vous ne spécifiez pas cela, alors la valeur par défaut globale podman_run_as_group sera utilisée. Sinon, root sera utilisé. REMARQUE : Le groupe doit déjà exister - le rôle ne créera pas un. Le groupe doit être présent dans /etc/subgid.
• mode - Le mode du fichier - la valeur par défaut est "0600".

Par exemple, si vous avez

    podman_credential_files:
      - file_src: auth.json
        run_as_user: my_user

Le fichier local auth.json sera recherché dans les chemins de recherche de fichiers Ansible habituels et sera copié dans le fichier /home/my_user/.config/containers/auth.json sur le nœud géré. Le propriétaire du fichier sera my_user et le mode sera "0600". Les répertoires /home/my_user/.config et /home/my_user/.config/containers seront créés s'ils n'existent pas.

podman_registry_certificates

Cette variable est une liste d'éléments dict qui vous permet de gérer des certificats et des clés TLS utilisés pour se connecter aux registres. Les répertoires, les formats et les fichiers sont décrits dans man containers-certs.d. Les noms des clés utilisées pour les certificats et les clés TLS suivent les conventions de nommage TLS des rôles systèmes. REMARQUE : le préfixe client_ a été supprimé ici pour cert et private_key car il n'y a que des clients dans ce contexte.

REMARQUE : Vous êtes fortement encouragé à utiliser Ansible Vault pour chiffrer les clés privées et toute autre valeur sensible.

Les clés de chaque dict sont comme suit :

• state - la valeur par défaut est present. Utilisez absent pour supprimer des fichiers.
• run_as_user - C'est l'utilisateur qui sera le propriétaire des fichiers et qui est utilisé pour trouver le répertoire $HOME pour les fichiers. Si vous ne spécifiez pas cela, alors la valeur par défaut globale podman_run_as_user sera utilisée. Sinon, root sera utilisé.
• run_as_group - C'est le groupe qui sera le propriétaire des fichiers. Si vous ne spécifiez pas cela, alors la valeur par défaut globale podman_run_as_group sera utilisée. Sinon, root sera utilisé.
• registry_host - Requis - l'hôte ou hostname:port du registre. Cela sera utilisé comme nom du répertoire sous $HOME/.config/containers/certs.d (pour les conteneurs sans privilèges) ou /etc/containers/certs.d (pour les conteneurs système) qui contiendra les certificats et les clés. Si vous utilisez state: absent et que tous les fichiers sont supprimés, le répertoire sera supprimé.
• cert - nom du fichier dans le répertoire certs.d contenant le certificat client TLS. Si non spécifié, utilisez le nom de base de cert_src. Si cela n'est pas spécifié, utilisez client.cert.
• private_key - nom du fichier dans le répertoire certs.d contenant la clé privée TLS du client. Si non spécifié, utilisez le nom de base de private_key_src. Si cela n'est pas spécifié, utilisez client.key.
• ca_cert - nom du fichier dans le répertoire certs.d contenant le certificat CA TLS. Si non spécifié, utilisez le nom de base de ca_cert_src. Si cela n'est pas spécifié, utilisez ca.crt.
• cert_src - nom du fichier sur le nœud de contrôle à copier dans cert.
• private_key_src - nom du fichier sur le nœud de contrôle à copier dans private_key.
• ca_cert_src - nom du fichier sur le nœud de contrôle à copier dans ca_cert.
• cert_content - le contenu du certificat à copier dans cert.
• private_key_content - le contenu de la clé privée à copier dans 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

Cela va créer le répertoire /etc/containers/certs.d/quay.io:5000/, copier le fichier local client.cert cherché dans le chemin de recherche de fichiers d'Ansible habituel vers /etc/containers/certs.d/quay.io:5000/client.cert, copier le contenu du private_key_content chiffré avec Ansible Vault dans /etc/containers/certs.d/quay.io:5000/client.key, et copier le fichier local ca.crt cherché dans les chemins de recherche de fichiers d'Ansible habituels vers /etc/containers/certs.d/quay.io:5000/ca.crt.

podman_validate_certs

Booléen - la valeur par défaut est nulle - utilisez ceci pour contrôler si le tirage d'images depuis des registres validera les certificats TLS ou non. La valeur par défaut null signifie utiliser celui qui est par défaut utilisé par le module containers.podman.podman_image. Vous pouvez remplacer cela au niveau de chaque spécification à l'aide de validate_certs.

podman_prune_images

Booléen - la valeur par défaut est false - par défaut, le rôle ne se débarrassera pas des images inutilisées lors de la suppression de quadlets et d'autres ressources. Définissez ceci sur true pour indiquer au rôle de supprimer les images inutilisées lors du nettoyage.

podman_transactional_update_reboot_ok

Cette variable n'est valable que pour les systèmes de mise à jour transactionnelle.
Si une mise à jour transactionnelle nécessite un redémarrage, le rôle procédera au redémarrage si podman_transactional_update_reboot_ok est défini sur true. S'il est défini sur false, le rôle informera l'utilisateur qu'un redémarrage est nécessaire, permettant ainsi une gestion personnalisée du besoin de redémarrage. Si cette variable n'est pas définie, le rôle échouera pour s'assurer que le besoin de redémarrer n'est pas négligé.
Pour les systèmes de mise à jour non transactionnelle, cette variable est ignorée.

Variables exportées par le rôle

podman_version

Ceci est la chaîne de version de la version utilisée par podman. Vous pouvez généralement l'utiliser dans vos modèles. Par exemple, si vous voulez spécifier un template_src quadlet pour un conteneur, et lui faire utiliser des vérifications de santé et des secrets si vous utilisez podman 4.5 ou plus :

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

Le rôle doit s'assurer que tous les utilisateurs et groupes sont présents dans les informations subuid et subgid. Une fois qu'il extrait ces données, elles seront disponibles dans podman_subuid_info et podman_subgid_info. Ce sont des dicts. La clé est le nom d'utilisateur ou de groupe, et la valeur est un dict avec deux champs :

• start - le début de la plage d'identifiants pour cet utilisateur ou groupe, en tant qu'int
• range - la plage d'identifiants pour cet utilisateur ou groupe, en tant qu'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 }}"

Où 1001 est le uid pour l'utilisateur dbuser, et 1001 est le gid pour le groupe dbgroup.

REMARQUE : en fonction de l'espace de noms utilisé par vos conteneurs, vous pourriez ne pas être en mesure d'utiliser les informations subuid et subgid, qui proviennent de getsubids si disponible, ou directement des fichiers /etc/subuid et /etc/subgid sur l'hôte. Voir modes d'espace de noms utilisateur podman pour plus d'informations.

Exemples de Playbooks

Créer un conteneur sans privilèges avec un montage de volume :

- name: Gérer les conteneurs et services 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

Créer un conteneur fonctionnant en tant que root avec Podman volume:

- name: Gérer les conteneurs et services root podman
  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

Créer une application quadlet avec des secrets. Déférer le démarrage de l'application jusqu'à ce que toutes les unités aient été créées. Notez que l'ordre des fichiers dans podman_quadlet_specs est dans l'ordre de dépendance. En utilisant podman_create_host_directories: true, cela créera tous les répertoires montés hôtes spécifiés par une directive Volume= dans la spécification du conteneur.

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

Licence

MIT.

Informations sur l'auteur

Basé sur podman-container-systemd par Ilkka Tengvall ilkka.tengvall@iki.fi.

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