linux-system-roles.podman

Descripción general Versiones Perspectivas

podman

Este rol gestiona la configuración de podman, contenedores y servicios de systemd que ejecutan contenedores de podman.

Requisitos

El rol requiere podman versión 4.2 o posterior.
El rol requiere podman versión 4.4 o posterior para soporte de quadlet y secretos.
El rol requiere podman versión 4.5 o posterior para soporte de healthchecks (solo se admite cuando se utilizan tipos de contenedores quadlet).

Requisitos de colecciones

El rol requiere las siguientes colecciones:

containers.podman
fedora.linux_system_roles

Utilice esto para instalar las colecciones:

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

Usuarios, grupos, subuid, subgid

Los usuarios y grupos especificados en podman_run_as_user, podman_run_as_group, y los especificados en una especificación kube como run_as_user y run_as_group tienen las siguientes restricciones:

Deben estar ya presentes en el sistema - el rol no creará los usuarios o grupos - el rol saldrá con un error si se especifica un usuario o grupo no existente
Deben ya existir en /etc/subuid y /etc/subgid, o ser proporcionados por su sistema de gestión de identidades - el rol saldrá con un error si un usuario especificado no está presente en /etc/subuid, o si un grupo especificado no está en /etc/subgid. El rol utiliza getsubids para verificar el usuario y grupo si está disponible, o verifica los archivos directamente si getsubids no está disponible.

Variables del rol

podman_kube_specs

Esta es una lista. Cada elemento de la lista es un dict que describe un pod de podman y la unidad de systemd correspondiente a gestionar. El formato del dict es muy similar al del módulo podman_play excepto por lo siguiente:

state - por defecto es created. Esto toma 3 valores:
- started - Crea los pods y servicios de systemd, y los inicia
- created - Crea los pods y servicios de systemd, pero no los inicia
- absent - Elimina los pods y servicios de systemd
run_as_user - Utilice esto para especificar un usuario por pod. Si no especifica esto, se utilizará el valor global predeterminado podman_run_as_user. De lo contrario, se usará root. NOTA: El usuario debe existir ya - el rol no creará uno. El usuario debe estar presente en /etc/subuid.
run_as_group - Utilice esto para especificar un grupo por pod. Si no especifica esto, se usará el valor global predeterminado podman_run_as_group. De lo contrario, se usará root. NOTA: El grupo debe existir ya - el rol no creará uno. El grupo debe estar presente en /etc/subgid.
systemd_unit_scope - El alcance a usar para la unidad de systemd. Si no especifica esto, se utilizará el valor global predeterminado podman_systemd_unit_scope. De lo contrario, el alcance será system para contenedores root y user para contenedores de usuario.
activate_systemd_unit - Si activar o no la unidad de systemd cuando se crea. Si no especifica esto, se utilizará el valor global predeterminado podman_activate_systemd_unit, que es true por defecto.
pull_image - Asegura que la imagen se descargue antes de usarla. Si no especifica esto, se utilizará el valor global predeterminado podman_pull_image, que es true por defecto.
continue_if_pull_fails - Si la descarga de la imagen falla, no trate esto como un error fatal y continúe con el rol. Si no especifica esto, se utilizará el valor global predeterminado podman_continue_if_pull_fails, que es false por defecto.
kube_file_src - Este es el nombre de un archivo en el nodo controlador que se copiará a kube_file en el nodo gestionado. Este es un archivo en formato YAML de Kubernetes. No lo especifique si especifica kube_file_content. kube_file_content tiene prioridad sobre kube_file_src.
kube_file_content - Esto es ya sea una cadena en formato YAML de Kubernetes, o un dict en formato YAML de Kubernetes. Se usará como el contenido de kube_file en el nodo gestionado. No lo especifique si especifica kube_file_src. kube_file_content tiene prioridad sobre kube_file_src.
kube_file - Este es el nombre de un archivo en el nodo gestionado que contiene la especificación de Kubernetes del contenedor/pod. Normalmente no tiene que especificar esto a menos que necesite de alguna manera copiar este archivo al nodo gestionado fuera del rol. Si especifica kube_file_src o kube_file_content, no tiene que especificar esto. Se recomienda encarecidamente omitir kube_file y especificar ya sea kube_file_src o kube_file_content y dejar que el rol gestione la ruta y nombre del archivo.
- El nombre del archivo será el valor de metadata.name del YAML de K8s, con un sufijo .yml añadido.
- El directorio será /etc/containers/ansible-kubernetes.d para los servicios de sistema.
- El directorio será $HOME/.config/containers/ansible-kubernetes.d para los servicios de usuario.

Por ejemplo, si tiene

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

Esto se copiará al archivo /etc/containers/ansible-kubernetes.d/myappname.yml en el nodo gestionado.

podman_quadlet_specs

Lista de especificaciones de Quadlet. Una especificación de quadlet está identificada de manera única por un nombre y un tipo, donde el tipo es uno de los tipos de unidades como contenedor, kube, red, volumen, etc. Puede pasar explícitamente name y type, o se derivarán del nombre del archivo dado en file, file_src, o template_src.

Por defecto, los archivos se copiarán o crearán en /etc/containers/systemd/$name.$type para contenedores root, y en $HOME/.config/containers/systemd/$name.$type para contenedores sin privilegios, en el nodo gestionado. Puede proporcionar una ubicación diferente utilizando file, pero entonces probablemente necesitará cambiar la configuración de systemd para encontrar el archivo, lo que no es compatible con este rol.

Cuando una especificación de quadlet depende de otro archivo, por ejemplo, un quadlet.kube que depende del archivo Yaml o un ConfigMap, entonces ese archivo debe especificarse en la lista podman_quadlet_specs antes del archivo que lo utiliza. Por ejemplo, si tiene un archivo my-app.kube:

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

Debe especificar my-app-config.yml y my-app.yml antes de my-app.kube:

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

La mayoría de los parámetros para cada especificación de quadlet son los mismos que para podman_kube_spec arriba excepto que los parámetros *kube* no son compatibles, y los siguientes son:

name - El nombre de la unidad. Si no se da, se derivará de file, file_src, o template_src. Por ejemplo, si especifica file_src: /path/to/my-container.container entonces el name será my-container.
type - El tipo de unidad (contenedor, kube, volumen, etc.). Si no se da, se derivará de file, file_src, o template_src. Por ejemplo, si especifica file_src: /path/to/my-container.container entonces el type será container. Si el tipo derivado no se reconoce como un tipo de quadlet válido, por ejemplo, si especifica file_src: my-kube.yml, entonces simplemente se copiará y no se procesará como una especificación de quadlet.
file_src - El nombre del archivo en el nodo de control que se copiará al nodo gestionado para usar como fuente de la unidad de quadlet. Si este archivo está en el formato de unidad de quadlet y tiene un sufijo de unidad de quadlet válido, se utilizará como una unidad de quadlet, de lo contrario, simplemente se copiará.
file - El nombre del archivo en el nodo gestionado que se utilizará como fuente de la unidad de quadlet. Si este archivo está en el formato de unidad de quadlet y tiene un sufijo de unidad de quadlet válido, se utilizará como una unidad de quadlet, de lo contrario, se tratará como un archivo normal.
file_content - El contenido de un archivo que se copiará al nodo gestionado, en formato de cadena. Esto es útil para pasar archivos cortos que se pueden especificar fácilmente en línea. También debe especificar name y type.
template_src - El nombre del archivo en el nodo de control que se procesará como un archivo template de Jinja y luego se copiará al nodo gestionado para usar como fuente de la unidad de quadlet. Si este archivo está en el formato de unidad de quadlet y tiene un sufijo de unidad de quadlet válido, se utilizará como unidad de quadlet, de lo contrario, simplemente se copiará. Si el archivo tiene un sufijo .j2, ese sufijo se eliminará para determinar el tipo de archivo de quadlet.

Por ejemplo, si especifica:

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

Entonces el archivo local templates/my-app.container.j2 se procesará como un archivo de plantilla de Jinja y luego se copiará a /etc/containers/systemd/my-app.container como una especificación de unidad de contenedor de quadlet en el nodo gestionado.

NOTA: Al eliminar quadlets, debe eliminar las redes último. No puede eliminar una red que esté en uso por un contenedor.

podman_secrets

Esta es una lista de especificaciones de secretos en casi el mismo formato que se utiliza por podman_secret. Hay un campo adicional:

run_as_user - Utilice esto para especificar un secreto para un usuario específico. Si no especifica esto, se usará el valor global predeterminado podman_run_as_user. De lo contrario, se usará root. NOTA: El usuario debe existir ya - el rol no creará uno.

Se le recomienda encarecidamente usar Ansible Vault para cifrar el valor del campo data.

podman_create_host_directories

Esto es un booleano, el valor predeterminado es false. Si es true, el rol asegurará los directorios de host especificados en los montajes de host en las especificaciones de volumes.hostPath en el YAML de Kubernetes dado en podman_kube_specs, y desde la configuración de Volume en la especificación de Contenedor quadlet donde se especifica un camino de host. NOTA: Los directorios deben especificarse como rutas absolutas (para contenedores root), o rutas relativas al directorio de inicio (para contenedores sin privilegios), para que el rol pueda gestionarlos. Cualquier otra cosa se asumirá como un volumen de algún otro tipo y se ignorará. El rol aplicará su propiedad/permisos predeterminados a los directorios. Si necesita establecer la propiedad/permisos, consulte podman_host_directories.

podman_host_directories

Este es un dict. Al usar podman_create_host_directories, esto le dice al rol qué permisos/propiedad aplicar a los directorios de host creados automáticamente. Cada clave es la ruta absoluta del directorio de host a gestionar. El valor está en el formato de los parámetros del módulo de archivo. Si no especifica un valor, el rol utilizará sus valores predeterminados. Si desea especificar un valor que se utilizará para todos los directorios de host, utilice la clave especial DEFAULT.

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

El rol utilizará dbuser:dbgroup 0600 para /var/lib/data, y root:root 0644 para todos los demás directorios de host creados por el rol.

podman_firewall

Esta es una lista de dict en el mismo formato que utiliza el rol fedora.linux_system_roles.firewall. Úselo para especificar los puertos que desea que el rol gestione en el cortafuegos.

podman_firewall:
  - port: 8080/tcp

podman_selinux_ports

Esta es una lista de dict en el mismo formato que utiliza el rol fedora.linux_system_roles.selinux. Úselo si desea que el rol gestione la política de SELinux para los puertos utilizados por el rol.

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

podman_run_as_user

Este es el nombre del usuario a usar para todos los contenedores sin privilegios. También puede especificar un nombre de usuario por contenedor con run_as_user en podman_kube_specs. NOTA: El usuario debe existir ya - el rol no creará uno. El usuario debe estar presente en /etc/subuid.

podman_run_as_group

Este es el nombre del grupo a usar para todos los contenedores sin privilegios. También puede especificar el nombre del grupo por contenedor con run_as_group en podman_kube_specs. NOTA: El grupo debe existir ya - el rol no creará uno. El grupo debe estar presente en /etc/subgid.

podman_systemd_unit_scope

Este es el alcance del systemd que se utilizará por defecto para todas las unidades de systemd. También puede especificar el alcance por contenedor con systemd_unit_scope en podman_kube_specs. Por defecto, los contenedores sin privilegios utilizarán user y los contenedores root utilizarán system.

podman_activate_systemd_units

Activa cada unidad de systemd tan pronto como se crea. El valor predeterminado es true. También puede hacer esto en una base por unidad especificando activate_systemd_units en la especificación de cada unidad. Por ejemplo, si está implementando varias especificaciones, y solo quiere que la última en la lista se active, que activará a las demás a través de dependencias, entonces establezca activate_systemd_unit: false para cada una excepto la última que usa activate_systemd_unit: true. NOTA: las unidades de quadlet se habilitan implícitamente al crearse - actualmente no puede usar activate_systemd_unit para desactivar esas unidades - puede usar activate_systemd_unit para crear unidades detenidas o iniciadas.

podman_pull_image

Asegúrese de que cada imagen mencionada en una especificación kube o quadlet esté presente al descargar la imagen antes de que se use. El valor predeterminado es true. Use false si el nodo gestionado ya tiene la versión correcta, o no puede descargar imágenes. También puede especificar esto en una base por unidad con pull_image.

podman_continue_if_pull_fails

Si la tentativa de descarga de la imagen falla, no trate esto como un error fatal y continúe con la ejecución del rol. El valor predeterminado es false - un fallo en la tentativa de descarga es un error fatal. Puede establecer esto en una base por unidad con continue_if_pull_fails.

podman_containers_conf

Estas son las configuraciones de containers.conf(5), proporcionadas como un dict. Estas configuraciones se proporcionarán en un archivo de sobreescritura en el directorio containers.conf.d. Si se ejecuta como root (ver podman_run_as_user), se gestionarán los ajustes del sistema, de lo contrario, se gestionarán los ajustes del usuario. Vea la página del manual para las ubicaciones de los directorios.

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

podman_registries_conf

Estas son las configuraciones de containers-registries.conf(5), proporcionadas como un dict. Estas configuraciones se proporcionarán en un archivo de sobreescritura en el directorio registries.conf.d. Si se ejecuta como root (ver podman_run_as_user), se gestionarán los ajustes del sistema, de lo contrario, se gestionarán los ajustes del usuario. Vea la página del manual para las ubicaciones de los archivos.

podman_registries_conf:
  aliases:
    myregistry: registry.example.com

podman_storage_conf

Estas son las configuraciones de containers-storage.conf(5), proporcionadas como un dict. Si se ejecuta como root (ver podman_run_as_user), se gestionarán los ajustes del sistema, de lo contrario, se gestionarán los ajustes del usuario. Vea la página del manual para las ubicaciones de los archivos.

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

podman_policy_json

Estas son las configuraciones de containers-policy.json(5), proporcionadas como un dict. Si se ejecuta como root (ver podman_run_as_user), se gestionarán los ajustes del sistema, de lo contrario, se gestionarán los ajustes del usuario. Vea la página del manual para las ubicaciones de los archivos.

podman_policy_json:
  default:
    type: insecureAcceptAnything

podman_use_copr (EXPERIMENTAL)

Booleano - el valor predeterminado es no establecido - si desea habilitar el repositorio copr para usar la última versión de desarrollo de podman, use podman_use_copr: true.

podman_fail_if_too_old (EXPERIMENTAL)

Booleano - el valor predeterminado es no establecido - por defecto, el rol fallará con un error si está utilizando una versión más antigua de podman e intenta usar una función que solo se admite en una versión más nueva. Por ejemplo, si intenta gestionar quadlet o secretos con podman 4.3 o anterior, el rol fallará con un error. Si desea que el rol se omita en su lugar, use podman_fail_if_too_old: false.

podman_registry_username

Cadena - el valor predeterminado es no establecido - nombre de usuario a utilizar para autenticarse en el registro. También debe establecer podman_registry_password. Puede sobrescribir esto en una base por especificación con registry_username. El uso de container_image_user no está respaldado y está en desuso.

podman_registry_password

Cadena - el valor predeterminado es no establecido - contraseña a utilizar para autenticarse en el registro. También debe establecer podman_registry_username. Puede sobrescribir esto en una base por especificación con registry_password. El uso de container_image_password no está respaldado y está en desuso.

podman_credential_files

Esta es una lista. Cada elemento de la lista es un dict que describe un archivo de credencial de podman utilizado para autenticarse en los registros. Vea man containers-auth.json y man containers-registries.conf:credential-helpers para obtener más información sobre el formato de estos archivos y la ruta de búsqueda del directorio predeterminado. NOTA: Estos archivos contienen credenciales de autenticación. Por favor, tenga cuidado con ellos. Se le recomienda encarecidamente usar Ansible Vault para cifrarlos. Las claves de cada dict son las siguientes:

state - el valor predeterminado es present. Use absent para eliminar archivos.
file_src - Este es el nombre de un archivo en el nodo controlador que se copiará a file en el nodo gestionado. No lo especifique si especifica file_content o template_src, que tendrán prioridad sobre file_src.
template_src - Este es el nombre de un archivo en el nodo controlador que se procesará usando el módulo template y se copiará a file en el nodo gestionado. No lo especifique si especifica file_content o file_src.
file_content - Esta es una cadena en formato containers-auth.json. Se utilizará como contenido de file en el nodo gestionado. No lo especifique si especifica file_src o template_src.
file - Este es el nombre de un archivo en el nodo gestionado que contendrá el contenido de auth.json. El valor predeterminado será $HOME/.config/containers/auth.json. Si especifica una ruta relativa, será relativa a $HOME/.config/containers. Si especifica algo distinto de los valores predeterminados mencionados en man containers-auth.json, también necesitará configurar credential-helpers en containers-registries.conf utilizando podman_registries_conf. Se crearán los directorios principales que falten.
run_as_user - Utilice esto para especificar un propietario de archivo por credencial. Si no especifica esto, se utilizará el valor global predeterminado podman_run_as_user. De lo contrario, se utilizará root. NOTA: El usuario debe existir ya - el rol no creará uno. El usuario debe estar presente en /etc/subuid. NOTA: Esto se utiliza como el usuario para el directorio $HOME si no se especifica file, y como el propietario del archivo. Si desea que el propietario del archivo sea diferente al usuario utilizado para $HOME, especifique file como una ruta absoluta.
run_as_group - Utilice esto para especificar un grupo de archivo por credencial. Si no especifica esto, se utilizará el valor global predeterminado podman_run_as_group. De lo contrario, se utilizará root. NOTA: El grupo debe existir ya - el rol no creará uno. El grupo debe estar presente en /etc/subgid.
mode - El modo del archivo - el valor predeterminado es "0600".

Por ejemplo, si tiene

    podman_credential_files:
      - file_src: auth.json
        run_as_user: my_user

El archivo local auth.json se buscará en las rutas de búsqueda de archivos de Ansible habituales y se copiará al archivo /home/my_user/.config/containers/auth.json en el nodo gestionado. El propietario del archivo será my_user y el modo será "0600". Los directorios /home/my_user/.config y /home/my_user/.config/containers se crearán si no existen.

podman_registry_certificates

Esta variable es una lista de elementos dict que le permiten gestionar los certificados y claves TLS utilizados para conectarse a los registros. Los directorios, formatos y archivos se describen en man containers-certs.d. Los nombres de las claves utilizadas para los certificados y claves TLS siguen las convenciones de nomenclatura de TLS de los roles del sistema. NOTA: se ha eliminado el prefijo client_ aquí para cert y private_key porque solo hay clientes en este contexto.

NOTA: Se le recomienda encarecidamente usar Ansible Vault para cifrar claves privadas y cualquier otro valor sensible.

Las claves de cada dict son las siguientes:

state - valor predeterminado es present. Use absent para eliminar archivos.
run_as_user - Este es el usuario que será el propietario de los archivos y se utiliza para encontrar el directorio $HOME para los archivos. Si no especifica esto, se utilizará el valor global predeterminado podman_run_as_user. De lo contrario, se utilizará root.
run_as_group - Este es el grupo que será el propietario de los archivos. Si no especifica esto, se utilizará el valor global predeterminado podman_run_as_group. De lo contrario, se utilizará root.
registry_host - Requerido - el nombre de host o hostname:port del registro. Esto se utilizará como el nombre del directorio bajo $HOME/.config/containers/certs.d (para contenedores sin privilegios) o /etc/containers/certs.d (para contenedores del sistema) que contendrá los certificados y claves. Si se utiliza state: absent y se eliminan todos los archivos, se eliminará el directorio.
cert - nombre del archivo en el directorio certs.d que contiene el certificado TLS del cliente. Si no se especifica, se usará el nombre base de cert_src. Si no se especifica, se usará client.cert.
private_key - nombre del archivo en el directorio certs.d que contiene la clave privada TLS del cliente. Si no se especifica, se usará el nombre base de private_key_src. Si no se especifica, se usará client.key.
ca_cert - nombre del archivo en el directorio certs.d que contiene el certificado CA TLS. Si no se especifica, se usará el nombre base de ca_cert_src. Si no se especifica, se usará ca.crt.
cert_src - nombre del archivo en el nodo de control que se copiará a cert.
private_key_src - nombre del archivo en el nodo de control que se copiará a private_key.
ca_cert_src - nombre del archivo en el nodo de control que se copiará a ca_cert.
cert_content - contenido del certificado que se copiará a cert.
private_key_content - contenido de la clave privada que se copiará a 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

Esto creará el directorio /etc/containers/certs.d/quay.io:5000/, copiará el archivo local client.cert buscado desde la ruta habitual de búsqueda de archivos de Ansible a /etc/containers/certs.d/quay.io:5000/client.cert, copiará el contenido de private_key_content cifrado con Ansible Vault a /etc/containers/certs.d/quay.io:5000/client.key, y copiará el archivo local ca.crt obtenido de la ruta habitual de búsqueda de archivos de Ansible a /etc/containers/certs.d/quay.io:5000/ca.crt.

podman_validate_certs

Booleano - el valor predeterminado es nulo - use esto para controlar si la descarga de imágenes de los registros validará los certificados TLS o no. El valor predeterminado null significa utilizar lo que sea el valor predeterminado utilizado por el módulo containers.podman.podman_image. Puede sobrescribir esto en una base por especificación utilizando validate_certs.

podman_prune_images

Booleano - el valor predeterminado es false - por defecto, el rol no eliminará imágenes no utilizadas al eliminar quadlets y otros recursos. Establezca esto en true para indicarle al rol que elimine imágenes no utilizadas al limpiar.

podman_transactional_update_reboot_ok

Esta variable es aplicable solo para sistemas de actualización transaccional.
Si una actualización transaccional requiere un reinicio, el rol procederá con el reinicio si podman_transactional_update_reboot_ok está establecido en true. Si se establece en false, el rol notificará al usuario que se requiere un reinicio, permitiendo una gestión personalizada del requisito de reinicio. Si esta variable no se establece, el rol fallará para asegurar que el requisito de reinicio no se pase por alto.
Para sistemas de actualización no transaccionales, esta variable se ignora.

Variables exportadas por el rol

podman_version

Esta es la cadena de versión de la versión utilizada por podman. Generalmente puede usar esto en sus plantillas. Por ejemplo, si desea especificar una template_src de quadlet para un contenedor y hacer que use healthchecks y secretos si está utilizando podman 4.5 o más reciente:

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

El rol necesita asegurarse de que cualquier usuario y grupo estén presentes en la información de subuid y subgid. Una vez que extrae estos datos, estarán disponibles en podman_subuid_info y podman_subgid_info. Estos son dicts. La clave es el nombre del usuario o grupo, y el valor es un dict con dos campos:

start - el inicio del rango de id para ese usuario o grupo, como un int
range - el rango de id para ese usuario o grupo, como un 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 }}"

Donde 1001 es el uid para el usuario dbuser, y 1001 es el gid para el grupo dbgroup.

NOTA: dependiendo del espacio de nombres utilizado por sus contenedores, es posible que no pueda usar la información de subuid y subgid, que proviene de getsubids si está disponible, o directamente de los archivos /etc/subuid y /etc/subgid en el host. Vea modos de espacio de usuario de podman para más información.

Ejemplo de Playbooks

Crear un contenedor sin privilegios con montaje de volumen:

- name: Gestionar contenedores y servicios de 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

Crear un contenedor ejecutándose como root con volumen de Podman:

- name: Gestionar contenedores y servicios de podman como root
  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

Crear una aplicación quadlet con secretos. Aplazar el inicio de la aplicación hasta que todas las unidades hayan sido creadas. Tenga en cuenta que el orden de los archivos en podman_quadlet_specs está en orden de dependencia. Usar podman_create_host_directories: true creará cualquier directorio montado en el host especificado por una directiva Volume= en la especificación del contenedor.

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